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

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

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

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

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

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

Как это работает в связке. Перед выпуском/переводом токен вызывает Identity Registry → «кто такие стороны?» → Compliance → «разрешена ли сделка?» → только потом выполняет mint/transfer/burn. В спорных случаях — операции контроллера (см. ниже).

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

Что хранит:

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

Откуда берётся идентичность. Чаще — от трансфер-агента/эмитента, который присваивает инвестору устойчивый идентификатор и выдаёт адресам «клеймы» (подтверждённые атрибуты). Хорошая практика — использовать независимый идентификационный смарт-контракт (например, совместимый с ончейн-идентичностями), чтобы разные выпуски читали одну и ту же запись.

Зачем это инвестору. Вы подтверждаете себя один раз, затем подключаете адреса кошельков (self-custody/кастоди), и все выпускные/вторичные операции «узнают» ваш статус автоматически.

Полезно знать. В мультичейне идентичность должна быть переносимой: либо общий корень на нескольких сетях, либо клеймы повторно публикуются в целевой сети. Иначе при переносе через мосты (см. Мосты и мультичейн для RWA: официальные маршруты, модели перевыпуска, реестр прав и риски) адрес в новой сети окажется «без статуса».

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

Примеры правил:

• «Только инвесторы из стран X/Y, кроме Z»;
• «Только квалифицированные/аккредитованные»;
• «Лимит объёма/количества адресов»;
• «Lock-up до даты T»;
• «Нельзя переводить между определёнными классами»;
• «Запрет в чёрные окна вокруг record date».

Как это реализовано. Контракт Compliance содержит таблицы/модули проверок и публичные методы управления правилами. Перед transfer токен спрашивает: isTransferValid(from, to, amount, data) → true/false + код причины. Это делает отказы объяснимыми: фронт-энд может подсказать «не прошли KYC», «локап не снят», «гео запрещено».

Зачем эмитенту. Правила централизованы: меняете «политику» в одном месте, токен сразу исполняет её при любых операциях — подписке, вторичке, OTC, мостах.

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

Совместим с ERC-20. Функции balanceOf, transfer, approve доступны — интеграции не ломаются. Разница — в pre-transfer-проверках: любая передача идёт через Identity+Compliance.

Дополнительные возможности:

• выпуск/погашение с проверкой допуска;
• адреса операторов (агентов) для сервисных операций;
• расширенные события и коды причин отказа.

UX-нюанс. Кошелёк может показать «достаточно баланса», но перевод не пройдёт из-за правил. Нормальный интерфейс поверх ERC-3643 заранее вызывает «сухую» проверку и объясняет причину отказа.

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

Хорошая практика. Разнести полномочия и публиковать адреса ролей на сайте выпуска; держать Owner/Controller под мультисигом и timelock. Все критические действия — с анонсами и логами.

Онбординг инвестора: как это выглядит в 3643

1) Регистрация. Инвестор оформляет KYC/KYB, подтверждает владение адресом (подписью). Для юрлиц — указываются бенефициары/подписанты, настраивается кастоди-адрес/мультисиг (см. Self-custody vs биржа — сравнение хранения активов).

2) Привязка адреса. Agent в Identity Registry связывает адрес с идентичностью и выставляет статусы (страна, категория инвестора, срок действия).

3) Проверка допуска. Compliance определяет, к каким выпускам и классам инвестор допущен. Портал подписки/ATS/DEX делают «сухой» вызов проверки.

4) Подписка/покупка. Токен вызывает Identity+Compliance → ok → зачисляет токены.

5) Поддержание статуса. Реверификация раз в 12–24 месяца или по событию. При изменении страны/категории — обновление клеймов; при просрочке — *freeze* до продления.

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

В реальности бывают кражи, утерянные ключи, судебные запреты. ERC-3643 предусматривает контролируемые операции (аналог ERC-1644):

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

Когда применяют:

• установка суда/регулятора;
• восстановление права добросовестного держателя (*wipe & reissue* в терминах TA);
• исправление технического сбоя/моста.

Требуйте: публичную политику и журналы — кто инициировал, на каком основании, какие документы приложены. Это защищает и эмитента, и инвестора (см. Трансфер-агент и реестр держателей RWA: как устроены корпоративные действия, выкуп и синхронизация с блокчейном, Админ-ключи и апгрейды в RWA: pause/freeze/wipe, прокси-контракты, timelock и мультисиг — полный гид).

Документы и анонсы: где хранить «правила игры»

Хотя ERC-3643 не навязывает конкретный интерфейс документов, в зрелых реализациях используют подход из ERC-1400: стандарт security-токенов. Партиции, контроль переводов, документы и роль трансфер-агента (ERC-1643-подобная логика):

• прикрепляют URI + хэш PPM/IM/Terms;
• публикуют историю изменений;
• вешают события «обновлён документ».

Зачем это вам. Можно доказать, какая версия регламента действовала на момент подписки/перевода. Для due diligence — бесценно (см. Due Diligence RWA: большой чек-лист проверки эмитента, актива и смарт-контрактов, Как читать отчёты по RWA: NAV, резервы, аудиты и корпоративные действия — полный гид для инвестора).

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

Правила:

• используйте только официальные мосты выпуска — Мосты и мультичейн для RWA: официальные маршруты, модели перевыпуска, реестр прав и риски;
• заранее внесите целевой адрес в whitelist/Identity Registry;
• убедитесь, что клеймы идентичности доступны в целевой сети;
• храните TXID «burn/mint» и подтверждения агента.

Почему так строго. Если перенести токен «обёрткой» через неофициальный мост, реестр держателей может не признать право — вы потеряете шанс на выплаты и выкуп (см. Bridge Risks, Доступ и оборот RWA: whitelist, категории инвесторов, гео-ограничения и вторичный рынок (ATS/DEX/OTC)).

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

Практика. Если строите с нуля и хотите «готовую» архитектуру идентичности+правил — выбирайте ERC-3643. Если уже есть исторический выпуск/кастомный стек — проще довести до ERC-1400: стандарт security-токенов. Партиции, контроль переводов, документы и роль трансфер-агента. В больших системах встречается гибрид: 3643 для допусков и 1410 для партиций классов.

Совместимость с ERC-4626 и пуловыми моделями

В фондах/портах (приватный кредит, облигации) полезна пара ERC-3643 + Erc 4626:

• 4626 отвечает за экономику долей (totalAssets, convertToShares);
• 3643 — за допуск и соблюдение правил при deposit/mint/withdraw/redeem.

Что учесть:

• шлюзы подписки должны проверять статус адреса и сеть;
• «чёрные окна» вокруг record date/оценок NAV — в правила Compliance;
• адреса кастодианов/мультисигов — в Identity Registry с ролями оператора.

Подробнее: Приватный кредит (RWA): on-chain займы и факторинг — устройство, доходность, риски и редемпшн, Как читать отчёты по RWA: NAV, резервы, аудиты и корпоративные действия — полный гид для инвестора, Оракулы и NAV в RWA: источники данных, точность, обновления и отказоустойчивость.

Безопасность и операции: ключи, пауза, журналы

Минимальные требования:

• Owner/Controller под мультисигом и timelock ≥ 24–72 ч.;
• разнесённые роли: Compliance Admin ≠ Owner ≠ Agent;
• публичные адреса модулей и страницы «официальные сети/мосты»;
• логи Paused/Unpaused, RoleGranted/Revoked, события обновления правил/документов.

Зачем вам это знать. Так вы оцениваете административные риски выпуска ещё до покупки (см. Админ-ключи и апгрейды в RWA: pause/freeze/wipe, прокси-контракты, timelock и мультисиг — полный гид, Due Diligence RWA: большой чек-лист проверки эмитента, актива и смарт-контрактов).

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

1) Добавить новый адрес. Подпишите владение → Agent вносит адрес в Identity Registry → проверка Compliance → тестовый перевод «пенни» → основная операция.

2) Сменить хранение на кастоди. Оформляете договор, кастоди-адрес получают статус в Registry → *reassignment* у TA → статус «оператор» для кастоди (чтобы подписывать операции).

3) Продать OTC. Покупатель проходит KYC → его адрес добавляют → OTC-сделка через TA → transfer проходит Compliance → обновление реестра.

4) Потеряли ключи. Freeze → проверка бенефициара → controllerTransfer/controllerRedeem → *wipe & reissue* на новый whitelisted-адрес. Журналы и события публичны.

5) Миграция в другую сеть. Whitelisting адреса в целевой сети → официальный мост → проверка клеймов идентичности там же → сверка с TA по спискам держателей на record date.

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

• Адрес не в Identity Registry. Перевод «мимо» права. Решение: привязывайте адреса заранее, делайте тестовую сумму.
• Гео/категория не совпали. Compliance отклоняет сделки. Решение: обновляйте клеймы после смены резидентства/статуса.
• Нет timelock/мультисигов. Риск «тихих» изменений правил. Решение: проверяйте Админ-ключи и апгрейды в RWA: pause/freeze/wipe, прокси-контракты, timelock и мультисиг — полный гид.
• Неофициальные мосты. Реестр не признаёт право — нет выкупа. Решение: Мосты и мультичейн для RWA: официальные маршруты, модели перевыпуска, реестр прав и риски, Bridge Risks.
• Смешивание DeFi и RWA на одном адресе. Флаги комплаенса. Решение: «чистые» адреса на продукт (см. Self-custody vs биржа — сравнение хранения активов).
• Нет журналов документов. Споры по версиям PPM/IM. Решение: хранить URI+хэши и публиковать события обновления.

Чек-листы

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

1. Контракты Token/Identity/Compliance задокументированы и верифицированы?
2. Кто Owner/Controller/Compliance Admin? Есть timelock и мультисиг?
3. Мой адрес/кастоди внесён в Identity Registry? Статусы актуальны (KYC, страна, категория)?
4. Каналы оборота (ATS/whitelisted-DEX/OTC) перечислены в регламенте?
5. Поддерживаются ли нужные сети/мосты? Где выкуп? См. Редемпшн RWA: как вывести деньги или получить актив — пошаговый гид, комиссии, сроки и риски.

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

1. Описана архитектура: модули, версии, адреса, страницы «официальные сети/мосты».
2. Регламентирован онбординг: формы, SLA, статусы, привязка адресов.
3. Политики: *pause/freeze/controller operations*, ведение журналов.
4. Документы: публичные URI+хэши, страница анонсов.
5. Тест-планы на чёрные окна, локапы, мультичейн, OTC.

FAQ

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

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

Почему у меня «достаточно токенов», но перевод не проходит? Так работает Compliance: перевод запрещён по правилам (гео, локап, категория, окно). Интерфейс должен подсказать причину.

Можно ли сделать физическую поставку по товарному RWA в 3643? Это определяется регламентом выпуска и TA. 3643 отвечает за допуск и контроль; поставка — оффчейн-процедура (см. Товарные RWA (commodities): золото, серебро и другие активы — устройство, обеспечение, комиссии и риски, Редемпшн RWA: как вывести деньги или получить актив — пошаговый гид, комиссии, сроки и риски).

3643 и 1400 — конкуренты? Скорее, альтернативы. 3643 — цельный стек «идентичность+правила», 1400 — модульный набор с упором на партиции и документы. Часто их комбинируют.

См. также

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