> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ru/prilozheniya-na-rome/bloom/compliance.md).

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

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)`. [Онбординг и проверка](/ru/prilozheniya-na-rome/bloom.md) — это механизм вокруг этого решения: как инвестор подает заявку, как эмитент принимает решение и какой аудитный след оно оставляет, — и он не меняет эту модель: по-прежнему решение принимает эмитент, по-прежнему в блокчейне хранится только булево значение и никаких документов нигде нет. Это собственная модель фреймворка 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](/ru/prilozheniya-na-rome/bloom/lanes.md).

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/ru/prilozheniya-na-rome/bloom/compliance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.