ERC-3643 (T-REX): реестр идентичностей, правила соответствия и управляемые переводы для security-токенов

Кому и зачем нужен ERC-3643

RWA-выпуски, security-токены, пулы приватного кредита и долевые SPV редко могут жить как «чистые» ERC-20. Правовая реальность требует:

• знать кто владелец (KYC/KYB, страна, бенефициары);
• ограничивать географию и категории инвесторов;
• соблюдать lock-up, лимиты, окна;
• уметь приостанавливать или переоформлять право при форс-мажорах (кража ключей, судебный акт).

ERC-3643 даёт типовой стек для всего этого, чтобы не изобретать собственные whitelist-костыли в каждом проекте и не плодить несовместимые реализации.

Архитектура ERC-3643: три модуля

Типичный поток операций:

• перед выпуском/переводом токен спрашивает Identity Registry, кто такие from и to;
• затем проверяет через Compliance, разрешена ли сделка;
• только после этого выполняет mint/transfer/burn или возвращает ошибку с кодом причины.

Identity Registry: идентичность и статусы

Что хранит Identity Registry:

• привязку «адрес ↔ инвестор»;
• статусы KYC/KYB и срок их действия;
• атрибуты/клеймы: страна, категория инвестора, ограничения, флаги риска.

Идентичность чаще всего ведёт трансфер-агент или отдельный провайдер KYC:

• инвестор один раз проходит проверку,
• получает устойчивый идентификатор,
• привязывает к нему один или несколько адресов (личный кошелёк, кастоди, мультисиг).

Для мультичейна важно, чтобы идентичность была переносимой:

• либо один корневой реестр, к которому обращаются контракты в разных сетях;
• либо синхронизация клеймов в целевой сети при работе с мостами (см. мосты для RWA).

Compliance: правила допуска и оборота

Модуль Compliance реализует политику оборота токена:

• кто может купить/держать токен (страны, категории инвесторов);
• какие лимиты действуют (объём, число держателей);
• какие есть lock-up и «чёрные окна» (вокруг record date, корпоративных действий);
• какие типы переводов вообще разрешены (P2P, внутри биржи, только через ATS и т.п.).

Перед любой передачей токен вызывает что-то вроде:

isTransferValid(from, to, amount, data) → true/false + reasonCode

Это позволяет не просто «фейлить транзакцию», а объяснять причину отказа:

• не прошли KYC,
• истёк срок действия статуса,
• запрещённая юрисдикция,
• актив в lock-up,
• превышен лимит и т.д.

Правила можно менять:

• отдельной ролью Compliance Admin,
• через timelock и ончейн-журналы,
• с публичными анонсами обновлений (для прозрачности регуляторам и инвесторам).

Token: совместимость с ERC-20 и контроль переводов

Контракт Token обычно реализует интерфейс ERC-20, чтобы:

• не ломать кошельки, блок-обозреватели и базовую DeFi-инфру;
• показать привычные balanceOf, transfer, allowance.

Разница в том, что любой transfer/approve/mint/burn идёт через:

• проверку статусов в Identity Registry;
• проверку правил в Compliance.

Особенности для UX:

• пользователь может видеть «достаточно баланса», но перевод не пройдёт из-за комплаенса;
• хороший фронтенд всегда сначала делает «сухую» проверку и показывает код/текст причины отказа;
• OTC-сделки и операции через ATS тоже обязаны проходить через эти проверки, иначе on-chain и оффчейн-реестр поплывут.

Роли и управление: кто за что отвечает

Рекомендации по операциям и ключам — на странице админ-ключи, паузы и апгрейды.

Онбординг инвестора в модели ERC-3643

Типичный сценарий:

• Регистрация и KYC/KYB.

Инвестор (физлицо или компания) проходит проверку, подтверждает владение адресом подписью. Для юрлиц фиксируются бенефициары и лица, уполномоченные подписывать транзакции.

• Привязка адреса.

Агент вносит адрес в Identity Registry, присоединяет к идентичности инвестора и выставляет статусы (страна, категория, срок).

• Проверка допуска.

Портал подписки или ATS вызывает методы Compliance и проверяет, может ли адрес участвовать в конкретном выпуске/классе.

• Подписка/покупка.

При выпуске токен вызывает Identity+Compliance, получая подтверждение, и зачисляет токены на whitelisted-адрес.

• Поддержание статуса.

KYC/KYB периодически обновляется, статус в Identity Registry синхронизируется. При просрочке или смене юрисдикции адрес может быть временно заморожен до повторной проверки.

Управляемые переводы и спорные случаи

В реальной жизни случаются:

• утрата ключей или взлом кошелька;
• судебные решения, санкции, реструктуризации;
• технические ошибки при миграциях и мостах.

ERC-3643 предусматривает контролируемые операции (аналог ERC-1400/ERC-1644):

• controllerTransfer — принудительный перевод с одного адреса на другой;
• controllerRedeem — принудительное погашение с оформлением оффчейн-выплаты.

Применение таких функций должно быть:

• чётко описано в регламенте выпуска;
• ограничено мультисигом и timelock для роли Controller;
• прозрачно: все события логируются и доступны инвесторам и регулятору.

Процессы и роли — на страницах трансфер-агент и реестр держателей и админ-контроль и ключи.

Документы и анонсы

Стандарт не навязывает конкретного интерфейса документов, но зрелые реализации используют практику из ERC-1400:

• хранить в контракте URI и хэш для ключевых документов:
  • PPM/IM/Terms,
  • отчёты, приложения, корпоративные события;
• логировать обновления документов событиями, чтобы было видно историю.

Это помогает:

• доказать, какая версия регламента действовала на момент транзакции;
• упростить due diligence и работу аудиторских команд (см. due diligence RWA-проекта и как читать отчёты и NAV).

Мультичейн, мосты и перенос идентичности

RWA-проекты постепенно идут в мультичейн, но право остаётся привязано к реестру держателей, а не к конкретному контракту.

Основные правила:

• использовать только официальные мосты выпуска — см. мосты и мультичейн для RWA;
• заранее whitelisting’овать адрес в целевой сети;
• синхронизировать клеймы идентичности в Identity Registry целевой сети;
• вести журналы операций burn/mint и сверять их с оффчейн-реестром.

Если перенести токен «как ERC-20» через неофициальный мост:

• on-chain у вас будет токен,
• но реестр держателей выпуск не признает → вы рискуете потерять право на выплаты и выкуп (см. риски мостов для RWA и правила доступа).

ERC-3643 против ERC-1400: что выбрать

Практика:

• строите с нуля и хотите готовую архитектуру идентичности + комплаенса → ERC-3643;
• у вас уже есть исторический выпуск/свой стек, хотите аккуратно его «озащитничать» → ERC-1400.

В крупных платформах встречается гибрид: ERC-3643 для допуска и реестра идентичностей, ERC-1410 (из семейства 1400) для сложных классов прав.

ERC-3643 и ERC-4626: пуловые модели

Для фондов и пулов (приватный кредит, облигации) логичен тандем:

• ERC-4626 отвечает за экономику сейфа:
  • totalAssets, convertToShares, preview*, комиссии;
• ERC-3643 — за допуск и комплаенс:
  • кто может депонировать/выкупать,
  • какие адреса имеют право держать доли.

Такой стек:

• позволяет строить пуловые RWA-продукты с понятным NAV;
• не ломает регуляторную часть (каждое deposit/mint/withdraw/redeem проверяется через Identity+Compliance);
• хорошо сочетается с отчётностью по NAV и оракулами (NAV-оракулы и отчёты).

Безопасность и операционные практики

Минимальный базис для проекта на ERC-3643:

• Owner/Controller под мультисигом с timelock (24–72 часа);
• разделённые роли Owner, Compliance Admin, Agent, Pauser;
• публичный список адресов модулей и ролей на сайте выпуска;
• логи Paused/Unpaused, RoleGranted/Revoked, обновлений правил и документов;
• понятная политика применения контролируемых операций (когда возможен controllerTransfer и кто может его инициировать).

С точки зрения инвестора это критично для оценки административных рисков (см. админ-ключи и дисциплина и чек-лист due diligence).

Типовые сценарии

• Добавить новый адрес инвестора.

Инвестор подписывает владение адресом → Agent вносит его в Identity Registry → Compliance подтверждает допуск → делается тестовый перевод и основная операция.

• Перевести актив на кастоди.

Заключаете договор с кастоди → его адрес добавляют в Identity Registry с нужными ролями → TA обновляет реестр держателей → актив юридически «переезжает» на кастоди-счёт.

• OTC-сделка.

Покупатель проходит KYC → его адрес whitelisted → в on-chain Token и оффчейн-реестре проводится перевод, соответствующий договору.

• Потеря ключей.

Адрес замораживается → TA проверяет бенефициара → Controller выполняет controllerTransfer или controllerRedeem → токены/права переоформляются на новый адрес.

• Миграция в другую сеть.

Открывается официальный мост → адрес в целевой сети вносится в Identity Registry → старая позиция гасится, новая выпускается с сохранением записи в реестре держателей по инвестору.

Частые ошибки и как их избежать

• Адрес не занесён в Identity Registry.

Токен просто не признаётся выпуском. Решение: привязывайте адреса заранее, делайте тестовый перевод.

• Гео/категория не совпадают с правилами.

Compliance блокирует сделки. Следите за актуальностью статусов KYC и атрибутов.

• Нет timelock/мультисигов на критических ролях.

Риск «тихих» смен правил или мостов. Проверяйте конфигурацию ролей.

• Неофициальные мосты.

Реестр держателей не признаёт токены из неавторизованного моста; вы теряете право на выкуп. Используйте только официальные маршруты.

• Смешивание RWA и DeFi на одном адресе.

Может вызвать вопросы у комплаенса. Лучше держать «чистые» адреса под отдельные продукты (см. хранение и операционные риски).

• Отсутствие ончейн-журналов документов.

В спорах трудно доказать, какая версия PPM/IM действовала. Решение — вешать URI+хэши и события обновлений.

Чек-листы

Для инвестора

• Контракты Token/Identity/Compliance верифицированы, адреса опубликованы у эмитента?
• Есть ли мультисиг и timelock на Owner/Controller/Compliance Admin?
• Мой адрес (или адрес кастоди) внесён в Identity Registry, статусы актуальны?
• Официальные каналы оборота (ATS, OTC, whitelisted-DEX) перечислены в регламенте?
• Описаны условия выкупа (редемпшн) и используемые сети/мосты (официальные мосты)?

Для эмитента/агента

• Описана архитектура модулей, версий и адресов; есть страница с «официальными сетями/мостами».
• Регламентирован онбординг (формы, SLA, статусы, привязка адресов).
• Есть политика для pause/freeze/controller-операций и журналирование всех действий.
• Документы выпуска привязаны ончейн (URI+хэш), анонсы обновлений публичны.
• Тест-планы для чёрных окон, локапов, мультичейна и OTC-сделок отработаны заранее.

FAQ

Чем ERC-3643 отличается от простого whitelist в контракте? Whitelist — это просто список адресов. В ERC-3643 есть реестр идентичностей и модуль правил, которые можно переносить между выпусками и сетями, не теряя связку «инвестор ↔ адреса ↔ статус».

Нужно ли менять кошелёк, чтобы участвовать в выпуске на 3643? Нет. Достаточно привязать ваш адрес (или адрес кастоди/мультисиг) в Identity Registry. Но в ряде юрисдикций для компаний кастоди-решения предпочтительнее.

Почему у меня достаточно баланса, но перевод не проходит? Скорее всего, срабатывает правило Compliance: lock-up, запрет по гео, лимит или чёрное окно. Интерфейс должен показывать код/причину отказа.

Можно ли сделать «товарный» RWA (например, золото) на 3643? Да. Стандарт отвечает за допуск и оборот прав; физическая поставка и логистика описываются в регламенте выпуска и администрируются трансфер-агентом (см. товарные RWA и редемпшн).

Конкурируют ли ERC-3643 и ERC-1400? Скорее дополняют друг друга. ERC-3643 даёт цельный стек «идентичность+комплаенс», ERC-1400 — модульный подход с сильными партициями и документооборотом. В сложных платформах часто используют оба стандарта в разных слоях.

См. также

• ERC-1400: партиции, документы, управляемые переводы
• ERC-4626: сейфы и доли фонда
• Доступ и оборот RWA
• Трансфер-агент и реестр держателей
• Редемпшн (выкуп долей)
• Мосты и мультичейн для RWA
• Риски мостов для RWA
• Как читать NAV, резервы и отчёты
• Due diligence: чек-лист по RWA-проекту