Модель соответствия

Bloom использует фреймворк Arc от Plume без изменений. Соблюдение обеспечивается самим контрактом токена — а не каким-либо офчейн-скринингом, фильтром секвенсора или политикой площадки. Именно это свойство делает его переносимым: правила следуют за токеном по любому пути исполнения, в обоих кошельковых каналах.

Архитектура принудительного исполнения

ArcToken._update (каждый transfer/mint/burn)
   └─ RestrictionsRouter (по одному на цепочку, реестр модулей по типам)
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions (для каждого токена)
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions (для каждого токена)
        └─ GLOBAL_SANCTIONS     → (слот существует; глобальный модуль не развернут)

• WhitelistRestrictions — белый список. Пока transfersAllowed имеет значение false (режим с ограничением), перевод, где любая из сторон отсутствует в списке, отклоняется с типизированной ошибкой TransferRestricted() (0xe827105e). Проверка выполняется внутри токена при каждом перемещении баланса — перевод из EVM-кошелька, подписанный перевод Solana, продажа через витрину и первоначальное перемещение ликвидности все проходят через один и тот же шлюз. Обойти это нельзя иначе как через собственные административные полномочия эмитента.

• YieldBlacklistRestrictions — исключает адреса из распределений доходности; их пропорциональная доля остается в контракте токена.

• GLOBAL_SANCTIONS — роутер поддерживает модули, действующие на уровне всей цепочки и применяемые ко всем токенам (например, санкционный список). Сегодня такой модуль не развернут; этот слот — естественное место для модуля, управляемого на уровне цепочки.

Модель доверия, изложенная честно

Флаг белого списка — это внецепочечное решение эмитента. KYC/AML проводится в процессе эмитента (их поставщики, их правила); цепочка фиксирует и применяет результат — isWhitelisted(addr). Онбординг и проверка — это механизм вокруг этого решения: как инвестор подает заявку, как эмитент принимает решение и какой аудитный след оно оставляет, — и он не меняет эту модель: по-прежнему решение принимает эмитент, по-прежнему в блокчейне хранится только булево значение и никаких документов нигде нет. Это собственная модель фреймворка Arc, используемая на Plume. Это сознательно не система идентичности в блокчейне: нет заявлений об идентичности, нет аттестаций в блокчейне, нет криптографического подтверждения того, кому принадлежит адрес. Стандарты, которые обеспечивают проверяемую идентичность в блокчейне (например, ERC-3643), платят за это свойство значительно более тяжелыми переводами; Arc меняет это на более легкие механизмы в обмен на доверие, находящееся у эмитента. Bloom честно показывает это, а не намекает на большее.

Полномочия эмитента (в логике transfer-agent)

ArcToken.initialize предоставляет драйверу мастера все роли:

Роль	Полномочия
ADMIN_ROLE / DEFAULT_ADMIN_ROLE	связывать/заменять модули ограничений, управлять ролями
MINTER_ROLE / BURNER_ROLE	управление объемом выпуска
YIELD_MANAGER_ROLE / YIELD_DISTRIBUTOR_ROLE	задавать токен доходности, проводить распределения
UPGRADER_ROLE	обновлять токен по схеме UUPS (на стороне эмитента; передается фабрике для обновлений, опосредованных фабрикой)
Модуль белого списка WHITELIST_ADMIN_ROLE	добавлять/удалять адреса, переключать режим с ограничением

Последствия, которые стоит знать: утраченный кошелек инвестора можно восстановить только действиями эмитента (добавить заменяющий адрес в белый список и, при необходимости, использовать полномочия mint/burn/upgrade в соответствии с их юридической процедурой — у Arc нет встроенного механизма принудительного перевода). Следовательно, хранение ключей эмитентом является частью модели соблюдения требований; просмотрщик ролей в приложении делает видимыми держателей каждого полномочия.

Что добавляет Rome — и что сохраняет registerToken

Пользователи Solana-кошельков отображаются как синтетические адреса EVM (полученные из их публичного ключа Solana). Для уровня соблюдения требований это обычные адреса: эмитент добавляет их в белый список, шлюз проверяет их, доход поступает им — один белый список охватывает оба мира кошельков. Последствия для хранения указаны в LANES.md.

Поскольку Rome ограничивает число аккаунтов на транзакцию, токены разворачиваются поэтапно и получают статус фабрики через ArcTokenFactoryV2.registerToken вместо однократного createToken. Предохранители в точности сохраняют исходную модель безопасности: токен должен быть каноническим прокси (codehash), его реализация должна быть внесена фабрикой в белый список (codehash), вызывающий должен обладать токеном ADMIN_ROLE, и регистрация выполняется только один раз. Ничто в части соблюдения требований не ослабляется из-за поэтапного пути.