ERC-1400: стандарт security-токенов. Партиции, контроль переводов, документы и роль трансфер-агента

Зачем RWA нужен именно ERC-1400

RWA-токен — это не просто «жетон», а цифровая запись права. Отсюда требования:

• Нужна идентификация держателя (KYC/KYB), гео-ограничения, категории инвесторов — см. доступ и оборот RWA.
• Нужны управляемые трансферы в особых случаях: фрод, судебный запрет, утрата доступа к кошельку — см. админ-контроль.
• Важно различать классы прав одного выпуска (A/B, регионы, lock-up) — это делают партиции (ERC-1410).
• Регламенты и раскрытие должны быть доступны и проверяемы — используются документы (ERC-1643).

ERC-1400 решает всё это модульно и при этом может оставаться совместимым с ERC-20 для базовых операций и интеграций.

Карта семейства ERC-1400

На практике конкретная реализация может включать не все подстандарты, но ядро 1594 и партиции 1410 — самые частые.

Как выглядят процессы на ERC-1400

1. Подписка (выпуск)

• Инвестор проходит KYC/KYB; его адрес попадает в whitelist.
• Эмитент или трансфер-агент вызывают issue/issueByPartition.
• Токены появляются у инвестора в нужной партиции, например PARTITION_US_QUALIFIED.

2. Перевод (вторичка / P2P)

Перед transfer или transferByPartition вызывается логика проверки:

• canTransfer(from, to, amount, data) → «OK» или код причины отказа.
• Проверяются whitelist, гео-ограничения, категория инвестора, lock-up, лимиты.

3. Корпоративные действия

• Купоны, дивиденды, амортизация, конверсии учитываются по партициям и спискам держателей на *record date*.
• Документы и анонсы крепятся через ERC-1643.
• Детали процессов — на страницах трансфер-агент и как читать отчёты и NAV.

4. Погашение / выкуп

• redeem/redeemByPartition списывают токены.
• Денежный расчёт и поставка базового актива происходят по офчейн-регламенту выпуска.
• Общая логика описана в редемпшн (выкуп).

5. Инциденты

• При фроде/суде/санкциях токены могут быть заморожены (freeze).
• После процедур проверки TA использует controllerTransfer или controllerRedeem (ERC-1644).
• Политики и роли описываются в админ-контроле.

Партиции (ERC-1410): зачем и как их проектировать

Партиция — это отдельный «карман» внутри одного токена. Баланс держателя хранится не одним числом, а как сумма по нескольким партициям.

Типовые схемы:

• Юрисдикции: EU_PRO, US_QIB, ROW_RETAIL_LIMITED.
• Категории инвесторов: QUALIFIED, ACCREDITED, RETAIL_LOCKED.
• Статусы/окна: LOCKUP_6M, FREELY_TRANSFERABLE.
• Сети/каналы при мультичейне и мостах — подробнее в обзоре мостов для RWA.

Что нужно решить заранее:

• Правила конверсии между партициями (сняли lock-up → перенос баланса).
• Разделение прав на выплаты по классам (A/B-акции и т.п.).
• Согласование партиций с офчейн-реестром держателей у трансфер-агента.

Плюс: высокая гибкость комплаенса без выпуска десятков отдельных токенов. Минус: усложнение UX и отчётности; фронтенд и бэкенд должны правильно работать с balanceOfByPartition.

Проверки перед переводом: canTransfer и reason codes

ERC-1594 вводит предварительную проверку, чтобы заранее понять, пройдёт ли перевод. Вместо «тихого» фейла посреди транзакции контракт возвращает код причины отказа:

• 0x50 — *Transfer Verified* (OK).
• 0x51 — *Insufficient Balance* (не хватает токенов или неверная партиция).
• 0x52 — *Insufficient Allowance* (оператору не выдано право).
• 0x53 — *Transfer Blocked* (нарушены правила: нет в whitelist, запрещённая гео/категория, lock-up).
• 0x54 — *Identity Restriction* (идентичность/статус не подходит).
• 0x55 — *Partition Restriction* (нельзя так перевести между партициями).

Конкретный набор кодов зависит от реализации, но идея одна: объяснить отказ, чтобы инвестор, фронты и интеграторы понимали, что исправлять (KYC, партиция, окно и т.д.).

Документы выпуска на контракте (ERC-1643)

Чтобы не спорить, «какая версия условий действовала», стандарт позволяет «прикрепить» регламент выпуска к контракту:

• setDocument(name, uri, documentHash) — добавить или обновить документ (например, PPM_v1.2 с URI на хостинг/IPFS и хэшем).
• getDocument(name) — вернуть актуальную версию.
• События DocumentUpdated дают прозрачный чейнджлог для наблюдателей и аудиторов.

Зачем это ончейн:

• Прозрачность: любой может проверить, какая версия документа актуальна.
• Снижение споров: у реестра держателей и контракта одна и та же ссылка на условия.
• Удобство Due Diligence — см. проверка RWA-проекта.

Управляемые трансферы (ERC-1644): границы и безопасность

controllerTransfer и controllerRedeem дают контролёру (эмитенту или трансфер-агенту) возможность принудительного перевода или погашения, когда этого требует закон или защита прав инвесторов:

• восстановление прав при краже/утрате доступа к кошельку (после freeze и проверки документов);
• исполнение судебного акта или санкционного предписания;
• техническая коррекция при сбое мостов или миграции токена.

Хорошая практика:

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

Совместимость с ERC-20 и влияние на UX

Большинство реализаций ERC-1400 также реализуют интерфейс ERC-20, чтобы:

• не ломать кошельки, обменники и блок-обозреватели;
• дать базовую совместимость с DeFi-инфраструктурой.

Но есть нюансы:

• Баланс в кошельке может не учитывать партиции: фронтенд должен получать список партиций (partitionsOf(holder)) и суммировать balanceOfByPartition.
• transfer может не проходить из-за правил комплаенса даже при «достаточном» балансе. UX должен уметь показать причину (reason code).
• Для whitelisted-DEX/ATS добавляются офчейн-проверки адресов и статусов инвесторов.

ERC-1400 vs ERC-3643: что выбрать под проект

ERC-3643 (T-REX) — более «современный» стандарт, который делает акцент на реестр идентичностей и модуль соответствия (Identity Registry, Compliance). В нём многие практики, «размазанные» по семейству 1400, сведены в цельную архитектуру.

Практичный подход:

• если у вас исторический выпуск или кастомный стек, удобнее расширить ERC-20 до ERC-1400 (минимум 1594+1410);
• если строите с нуля и хотите «из коробки» реестр идентичностей и комплаенса, смотрите в сторону ERC-3643.

Оба варианта подходят для RWA; важнее качество процессов у трансфер-агента и комплаенс-команды.

ERC-1400 и ERC-4626: когда комбинировать

Для пулов и фондов часто используют ERC-4626, который описывает сейф (dоли ↔ активы, totalAssets, convertToShares). Сочетание:

• ERC-4626 отвечает за экономику долей (NAV, вход/выход, комиссии),
• ERC-1400 — за доступ, партиции и правоприменение.

Такой гибрид удобен для приватного кредита и портфельных RWA-продуктов:

• deposit/mint сопровождаются проверкой адреса и партиции;
• выплаты купонов, амортизация и конверсии учитывают классы инвесторов и локапы;
• редемпшн реализуется через redeemByPartition и процедуры выкупа.

Мультичейн и мосты: как не потерять право

Партиции удобно использовать для маркировки «сетевых» классов, но право в конечном итоге определяется реестром держателей у трансфер-агента.

При мультичейне:

• используйте только официальные мосты и маршруты — см. мосты и мультичейн для RWA;
• адрес в целевой сети должен быть в whitelist;
• логи burn/mint и конверсии партиций должны сходиться с офчейн-реестром;
• на *record date* TA агрегирует держателей по сетям и партициям.

Подробный разбор рисков мостов — на странице риски RWA-мостов.

Роли, паузы и апгрейды: операционная дисциплина

Сам стандарт не навязывает схему ролей, но для RWA-выпуска обычно требуется:

• разделить роли: owner/upgrader, pauser, freezer, controller, documentAdmin;
• повесить timelock на апгрейды и критические изменения конфигурации;
• держать ключи на мультисиге (M-of-N), желательно с кастоди или MPC-хранением;
• вести публичные логи Upgraded, RoleGranted, Paused и т.п. — см. админ-контроль и ключи.

Паттерны интеграции (для разработчиков)

• Шлюз подписки.

Фронт узнаёт партицию инвестора по профилю (регион, категория) и вызывает issueByPartition. Перед транзакцией делает «сухую» проверку через canTransfer.

• Whitelisted DEX/ATS.

Пулы проверяют статус адреса на вход/выход; для разных партиций можно держать отдельные рынки или делать конверсию партиции перед свопом.

• OTC-сделки.

Сделка согласуется у брокера/TA, после чего вызывается controllerTransfer/transferByPartition и обновляется реестр.

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

Новый отчёт или обновлённый регламент → setDocument с URI и хэшем → событие DocumentUpdated → лента анонсов на сайте и в блок-обозревателе.

Частые ошибки внедрения

• Сумбур с партициями: не определили правила конверсий — инвесторы «залипают» в LOCKUP_*.
• Нет reason codes: пользователи видят просто «ошибка», а не причину отказа.
• Документы только на сайте: споры, какая версия PPM действовала.
• Один ключ управляет всем: высокий риск злоупотребления или взлома.
• Неофициальный мост: ончейн-токен перекинулся, а реестр держателей этого не признаёт.
• Игнор трансфер-агента: контракт пропускает перевод, а TA блокирует в реестре.

Все эти проблемы решаются дизайном партиций, корректной реализацией canTransfer, использованием setDocument, мультисигом и чёткими процессами у трансфер-агента.

FAQ

Можно ли обойтись без партиций и только whitelist/blacklist? Можно, но вы потеряете гибкость. Юрисдикции, категории инвесторов, lock-up и классы прав гораздо удобнее размечать партициями, чем плодить десятки отдельных токенов.

Зачем хранить документы на контракте, если есть сайт? Ончейн-ссылка и хэш — способ доказать, какая версия документа действовала в момент операции. Сайт можно тихо обновить, ончейн-событие изменить нельзя.

ERC-1644 — это «централизация»? Это инструмент для правоприменения в security-подобных RWA. Риском он становится, если нет прозрачной политики, мультисига и timelock. Требуйте этих ограничений у эмитента.

Конфликтует ли ERC-1400 с ERC-20? Нет. Реализация обычно включает ERC-20 API. Но UX и интеграторы должны учитывать партиции и возможные отказы по правилам комплаенса.

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

См. также

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