> 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/issuing.md).

# Выпуск

Bloom позволяет вам выпускать **реальный актив с ограниченным доступом** как обычный контракт Solidity в цепочке Rome и управлять им из консоли для каждого актива. Актив доступен как из кошельков EVM, так и из кошельков Solana, но **выпуск доступен только в EVM** — кошелёк Solana может хранить активы; он не создаёт их. Это руководство охватывает консоль эмитента, мастер создания, шлюз входа в консоль и каждую из шести вкладок управления.

> **Вы не передаёте Bloom никаких документов или персональных данных, и ваш инвестор тоже.** Bloom фиксирует *результат* вашего решения по комплаенсу; цепочка записывает одно булево значение для каждого адреса. Ваш процесс KYC/AML — ваши поставщики, ваши файлы, сроки хранения — полностью остаётся в вашей собственной системе. Полная модель описана в [COMPLIANCE.md](/ru/prilozheniya-na-rome/bloom/compliance.md); это руководство ссылается на него, а не пересказывает его.

***

## Что вы можете делать

Как администратор актива, всё перечисленное ниже вы можете делать из консоли — и каждое из этих действий является настоящей транзакцией в цепочке, ссылка на которую есть на [Доказательства](/ru/prilozheniya-na-rome/bloom/evidence.md) странице:

* **Выпустить актив** — мастер разворачивает его в виде трёх контрактов (ниже).
* **Рассмотреть заявки** — одобрить или отклонить каждую из них (отказ сопровождается причиной, которую заявителю следует сообщить), а также добавить одобренный адрес в список разрешённых.
* **Управление списком разрешённых** — добавить один адрес, добавить **пакет адресов одной транзакцией** (`batchAddToWhitelist`), или удалить адрес; токен проверяет этот список при каждом переводе.
* **Ограничить актив** — ограничить переводы списком разрешённых (что делает выпуск окончательным) или снять ограничение.
* **Управление выпуском** — просмотреть общий объём и чеканить или сжигать токены, когда у вас есть соответствующая роль.
* **Провести продажу** — открыть продажу (объём и цена), закрыть её, вернуть непроданные остатки и вывести выручку.
* **Настроить и распределить доходность** — задать валюту выплаты, а затем распределить выплату, которая обходит держателей по одной транзакции за раз; исключённые держатели пропускаются.
* **Управление ролями** — назначить роль адресу, отозвать её или отказаться от собственной.

Каждое действие подробно описано ниже — вместе с тем, что проверяет цепочка, — во вкладке, к которой оно относится.

***

## Консоль эмитента

![Консоль эмитента по адресу /issuer, где перечислены активы, известные этому развёртыванию, и их состояние продажи.](/files/a3e89cd5d64ddaed407a62c242285ad5ed1c38f6)

`/issuer` перечисляет активы, выпущенные вами в этой цепочке, и позволяет начать выпуск нового.

* Подключите **кошелёк EVM**. Посетителю без подключения или владельцу кошелька Solana предлагается подключить нужный тип кошелька вместо пустой консоли — кошелёк Solana не может выпускать активы, и это продуктовая граница, которую цепочка обеспечивает как вторую, независимую проверку.
* Таблица показывает каждый актив вместе с его **названием и символом**, его жизненным **этапом**, а также его **Продажа** состоянием (значок *Открыта* или *Закрыта*).

Два столбца — **Держатели** и **К рассмотрению** — показывают прочерк. Для подсчёта держателей требуется перечисление списка разрешённых, а очередь рассмотрения — это хранилище вне цепочки, в которое вы входите отдельно для каждого актива; прочерк означает *не запрашивалось* там, где `0` было бы заявлено как факт, который приложение не прочитало.

Нажмите **Выпустить актив** чтобы открыть мастер, или выберите строку, чтобы открыть консоль этого актива.

***

## Создание актива: мастер

![Мастер создания по адресу /create: поля актива, а затем шесть карточек, которые загораются по мере подтверждения соответствующих транзакций.](/files/f7f16c15a56803ca01d085f62ed2f3a8eae3344f)

`/create` собирает четыре поля, а затем развёртывает ваш актив.

| Поле                 | Правило                  |
| -------------------- | ------------------------ |
| **Название**         | Обязательно.             |
| **Символ**           | Обязательно.             |
| **Объём**            | Целое число больше нуля. |
| **Десятичные знаки** | Целое число от 0 до 18.  |

Нажмите **Начать**. Если поле некорректно, мастер сообщает, какое именно и почему, вместо того чтобы оставаться за неактивной кнопкой. Когда черновик корректен, ваш кошелёк по очереди запрашивается для подписания каждого шага.

### Почему развёртывание выполняется поэтапно

> **Токен развёртывается как три контракта в ходе нескольких транзакций — никогда не одной.** Однотранзакционное `createToken` потребовало бы **77 блокировок аккаунтов**, а Rome ограничивает одну транзакцию **62 блокировками**. Поэтому мастер развёртывает каждый элемент отдельной транзакцией, а затем получает статус фабрики через `ArcTokenFactoryV2.registerToken`. Это ограничение Rome, сделанное явным, а не необязательная оптимизация — и проверки точно сохраняют исходную модель безопасности Arc (канонический прокси, разрешённая реализация, вызывающий владеет ролью администратора токена, регистрация возможна только один раз). См. [COMPLIANCE.md](/ru/prilozheniya-na-rome/bloom/compliance.md#what-rome-adds--and-what-registertoken-preserves).

### Шесть карточек

Мастер показывает шесть карточек, которые отражают ход развёртывания. Карточка меняет состояние с **Ожидание** на **Подписание…** на **Готово** (или **Сбой**) по мере подтверждения транзакции.

| # | Карточка                                  | Что она делает                                                                                                       |
| - | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| 1 | **Реализация**                            | Общая реализация актива для этой цепочки — уже определена, подписывать нечего. (Выполняется до запуска любого шага.) |
| 2 | **Актив**                                 | Разворачивает ваш актив и за один шаг задаёт его название, символ, объём и десятичные знаки.                         |
| 3 | **Кто может его держать**                 | Разворачивает собственный модуль разрешений этого актива, где вы являетесь администратором.                          |
| 4 | **Принудительно применять при переводах** | Указывает активу на этот модуль, чтобы каждый перевод проверялся самим активом.                                      |
| 5 | **Правила доходности**                    | Разворачивает и подключает модуль, который определяет, кому производятся выплаты.                                    |
| 6 | **Регистрация**                           | Регистрирует актив — именно это открывает продажу и позволяет затем обновлять его.                                   |

Шесть карточек объединяют восемь базовых шагов развёртывания, поэтому один **Начать** приводит к **восьми подписям**. Под кнопкой указано *"Ваш кошелёк попросит подписать каждый шаг. Вы можете остановиться в любой момент и продолжить с того же места — ничего не потеряется."* То, что регистрация является финальным шагом, и делает остановку безопасной: на каждом этапе актив является реальным развёртыванием, а регистрируется только в конце.

Когда процесс завершён, мастер выводит *"Выпущено. Ваш актив доступен по адресу …"* со ссылкой на консоль актива по адресу `/token/[address]`.

> **`инициализировать` назначает вам все роли.** Запускающий мастер — ваш адрес EVM — получает роли администратора, чеканки/сжигания, управления/распределения доходности и обновления, а также роль администратора модуля списка разрешённых. Таким образом, хранение ключей является частью комплаенс-профиля актива: потерянный кошелёк инвестора можно восстановить только через ваше административное действие, а вкладка консоли **Права** делает видимым, кто владеет каждым правом. (`UPGRADER_ROLE` не *не* назначается фабрике автоматически — назначьте его явно, если хотите обновления через фабрику.)

***

## Консоль для каждого актива и шлюз входа

![Шлюз входа в консоль: подпишите сообщение своим кошельком — пароля нет.](/files/e99c2aae1a7669ea9f5629c93f8deb7536dfe4c9)

Открытие `/token/[address]` не **не** сразу показывает консоль. Вместо этого отображается **шлюз входа**:

> *"Войдите, чтобы управлять этим активом. Подпишите сообщение своим кошельком — пароля нет. Ваше право управления исходит от самого актива и проверяется заново при каждом действии, поэтому его отзыв вступает в силу немедленно."*

Нажмите **Войдите с помощью кошелька**. Вот что именно происходит:

1. Ваш кошелёк запрашивают на `personal_sign` подпись короткого, понятного человеку заявления (с заголовком *"Bloom — подтвердите, что вы управляете этим активом"*) в котором указано единственное действие, которое оно разрешает, — чтение очереди заявок этого актива, — а также адрес актива, идентификатор сети и временная метка.
2. Приложение отправляет это подписанное заявление в `GET /api/applications`.
3. Этот **сервер** проверяет его: восстанавливает ваш адрес из подписи, подтверждает, что заявление относится к этой цепочке и всё ещё актуально (оно выдаёт разрешение на двухминутный интервал, а не на сессию), считывает **собственный модуль списка разрешённых токена** из цепочки и проверяет, что ваш адрес обладает ролью, которая фактически требуется для записи в список разрешённых — `MANAGER_ROLE` в этом модуле.
4. Если она у вас есть, очередь возвращается и консоль отображается. Если нет, сервер отказывает с `403` и указанием причины.

![Шлюз показывает отказ в кавычках: кошелёк, который не управляет этим активом, не допускается.](/files/d4c6ebbfffc88cfe4d189586c82e9ef747401556)

> **Решение о том, кто может администрировать актив, принимает сам актив — не это приложение.** Роль проверяется в модуле списка разрешённых **модуле**, а не в токене, и наличие одноимённой роли в токене не *не* переносится автоматически — это разные полномочия. Нет ни аккаунта, ни сессии: каждый последующий запрос несёт свою свежую подпись, именно это и *"проверяется заново при каждом действии"* означает. Отзовите роль кошелька в цепочке — и он немедленно перестанет входить.

Отказ показывает причину **в кавычках** — Bloom никогда не пишет отдельное предложение о том, почему кошельку отказали. Если вы отклоняете подпись в своём кошельке, это ваше *"нет"*, а не актива, и это не считается отказом.

> **Шлюз определяет, чья это консоль, а не то, что скрыто.** Объём выпуска, состояние продажи, список разрешённых и роли — это публичные данные цепочки, которые покажет любой обозреватель. Подпись даёт доступ к **очереди заявок** — заявлениям других людей — и вообще право видеть консоль.

### Заголовок консоли

После входа заголовок называет актив и показывает его **этапом** — самый важный из имеющихся фактов:

| Состояние      | Значение                                                                                                                                          |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Черновик**   | Модуль разрешений ещё не подключён, поэтому ничто не ограничивает, кто может это держать.                                                         |
| **Открыта**    | Переводы открыты, и объём выпуска ещё может меняться. Ограничение актива делает его выпуск окончательным, и это нельзя отменить.                  |
| **Ограничено** | Только адреса из списка разрешённых могут это держать, **и его объём выпуска окончателен** — больше нельзя чеканить или сжигать токены, навсегда. |

Над вкладками сводка показывает четыре показателя — **Держатели · К рассмотрению · Продано · Выплаченная доходность**. Два считываются из цепочки и хранилища (*К рассмотрению* после входа; *Продано* из витрины); *Держатели* зависит от количества держателей в предварительном просмотре доходности, а *Выплаченная доходность* зависит от курсора истории выплат, который ещё не реализован. Каждая ожидающая ячейка показывает прочерк и объясняет, что ей нужно, вместо `0` того чтобы утверждать факт, который никто не запрашивал у цепочки.

***

## Шесть вкладок

В консоли есть шесть вкладок в следующем порядке: **Заявки · Кто может это держать · Объём · Продажа · Доходность · Права.**

Каждая запись на этих вкладках использует один общий элемент управления, который отображает **названные предварительные условия** и её **последствия** *до* кнопки, а также показывает её состояние во время выполнения (*"Ожидание вашего кошелька…"*, *"Отправка в цепочку…"*). Ничто не должно откатываться ради того, чтобы показать, что можно было проверить заранее.

### Заявки — очередь рассмотрения

![Вкладка Applications — очередь рассмотрения, с ожидающей заявкой на одобрение или отказ и с точкой интеграции комплаенса.](/files/aebb7bf80ee109c87d432ceb2066f1a168fd4829)

На этой вкладке перечислены те, кто подал заявку на владение активом. Каждая строка показывает адрес заявителя, юрисдикцию, тип держателя, столбец **Проверки** (*Пройдено* если ваш провайдер записал результат, иначе *Заявлено*), а также **Статус** (*К рассмотрению*, *Одобрено*, *Отказано*). Разверните строку, чтобы увидеть её сведения и два элемента управления: **Одобрить — может держать** и **Отказать**. Отказ требует указания причины, которая становится ответом заявителю.

> **Одобрение — это два отдельных действия, и вкладка не даёт их смешать.** Нажатие **Одобрить** *записывает* ваше решение в хранилище заявок. Добавление адреса в список разрешённых актива в цепочке — это **вторая подпись** — `batchAddToWhitelist` — и до её подтверждения строка сообщает об этом. Когда записанное решение и данные в цепочке расходятся, вкладка указывает на расхождение и предлагает запись, которая его устраняет: **Допустить** чтобы добавить одобренный адрес в список разрешённых, или (для отклонённого адреса, который всё ещё указан) элемент управления для его удаления. Адрес не сможет держать актив, пока запись в список разрешённых не будет подтверждена.

Постоянная примечание на этой вкладке — **точка интеграции комплаенса** — указывает, где подключается ваш собственный процесс:

> *"Здесь не запрашиваются и не хранятся никакие документы — проверки выполняете вы сами. Подключите своего провайдера за `Applications` интерфейсом или импортируйте уже принятые решения. Bloom фиксирует результат, а цепочка записывает одно да или нет для этого адреса."*

Именно этот интерфейс заменяет эмитент с самостоятельным хостингом: замените реализацию хранилища заявок на свою собственную надёжную реализацию, и для вызывающих ничего не изменится. Bloom не выполняет проверок и не хранит документы.

### Кто может это держать — шлюз переводов

![Вкладка «Кто может это держать» — счётчик списка разрешённых и управление ограничением переводов, показывающее последствия решения без возврата.](/files/4ec646f185494953f4c89d5234b33a404dc7820f)

Эта вкладка показывает, сколько адресов добавлено в список разрешённых для этого актива, и позволяет переключить, применяется ли список **принудительно**:

* Когда переводы **неограничены**, она предлагает **ограничить переводы списком разрешённых**. Последствия записи указывают, что это делает выпуск окончательным и является необратимым шагом для неадминистраторов.
* Когда переводы **ограничены**, она предлагает **снять ограничение**. Его последствия прямо говорят, что это не отмена.

На *без ограничений* (черновом) активе без подключённого модуля разрешений вкладка прямо сообщает об этом — *"Модуль разрешений не подключён, поэтому ничто не ограничивает, кто может это держать"* — и переключатель не отображается.

> **Токен проверяет обе стороны каждого перевода.** Пока актив ограничен, перевод, в котором любая из сторон отсутствует в списке разрешённых, откатывается в цепочке с типизированной ошибкой. То же ограничение применяется при переводе из кошелька EVM, при переводе, подписанном Solana, при продаже через витрину и при первоначальном перемещении ликвидности — обойти его нельзя, кроме как с помощью ваших административных полномочий.

### Объём

![Вкладка «Объём» — общее количество существующих единиц.](/files/05db5a561f0ca36e93c10183e97a8b1cc9a9efc5)

Эта вкладка показывает общий объём выпуска в целых единицах.

### Продажа — открыть, закрыть и получить выручку

![Вкладка «Продажа» — открытая продажа с элементами управления закрытием продажи, возвратом непроданных остатков и выводом выручки.](/files/c8b33d1db9699cddb2008e07ab2d5098406cc8ff)

Эта вкладка проводит основную продажу через контракт витрины.

* **Когда продажа не открыта**, она предлагает открыть её: введите **Единиц к продаже** и **Цена за единицу** (в `wUSDC`), затем нажмите **Открыть продажу**. Сначала отображаются предварительные условия записи — токен должен быть зарегистрирован, витрина должна хранить товар для продажи, а сама витрина должна быть включена в список разрешённых для токена, который она продаёт, — поэтому продажа, которую пока нельзя открыть, точно сообщает, что ей требуется.
* **Когда продажа открыта**, она показывает, сколько единиц ещё осталось в предложении, и предлагает **Закрыть эту продажу**.
* **Вернуть непроданные единицы** возвращает непроданные остатки с витрины обратно получателю (по умолчанию вам). Это **не** не закрытие — продажа остаётся активной, и последствие записи прямо это указывает, поэтому возврат нельзя принять за сворачивание.
* **Вывести выручку** отправляет выручку витрины на адрес (по умолчанию вам). Выручка накапливается независимо от состояния продажи, поэтому её можно вывести как при открытой, так и при закрытой продаже.

### Доходность — выплата держателям, по одному за транзакцию

![Вкладка «Доходность» — поле суммы распределения, с напоминанием сначала задать валюту выплаты.](/files/62d2152683c926e131614d961b95d4cdc0dd0354)

Эта вкладка распределяет выплату доходности между держателями.

> **Распределение — это проход, а не нажатие.** В Rome, `distributeYieldWithLimit` выплачивает **одному держателю за транзакцию** (лимит аккаунтов), поэтому выплата — это последовательность окон, каждое со своей подписью. Вы один раз вводите сумму в целых единицах валюты выплаты, и она фиксируется, как только начинается проход.  **первое** окно забирает всю сумму выплаты у вас и платит первому держателю; каждое последующее окно перемещает только деньги, уже находящиеся в контракте токена. Bloom перечитывает курсор из цепочки после каждого окна — список держателей перестраивается по мере изменения балансов, и отправка устаревшего индекса привела бы к началу с нуля и повторному списанию ваших средств.

Вкладка показывает прогресс — *"Выплата держателю N из M"* — и завершается, когда курсор совершает полный цикл. Если для актива не задана валюта выплаты, вкладка сообщает об этом; выбор валюты выплаты — это единственное поле распределения, которое можете задать только вы.

> **Доли исключённых держателей остаются в контракте.** Адрес, исключённый модулем чёрного списка доходности, пропускается, а его пропорциональная доля остаётся в контракте токена, а не выплачивается.

Прошлые выплаты пока не отображаются — их чтение требует пройти по событиям распределения назад до первого блока актива, для чего ещё нужен курсор истории. Вкладка сообщает об этом внутри себя вместо того, чтобы показывать `0`.

### Права — роли

![Вкладка «Права» — каждая роль и указание, удерживается ли она, а также управление назначением / отзывом / отказом.](/files/18da30d41ff03276c3bbcf275ee12c7ba54fdc5d)

Эта вкладка перечисляет все роли, объявленные токеном, и указывает, удерживаются ли они; каждая из них считывается одной `hasRole` вызов в отношении токена. Роль, которая **не** имеется, отображается именно так, а не опускается — на вкладке прав отсутствующая строка и *"нет"* — это разные факты.

Под списком элемент управления изменяет роли:

| Действие                        | Действует на                                                                    | Полномочия           |
| ------------------------------- | ------------------------------------------------------------------------------- | -------------------- |
| **Предоставить учетной записи** | Адрес, который вы вводите                                                       | `DEFAULT_ADMIN_ROLE` |
| **Отозвать у учетной записи**   | Адрес, который вы вводите                                                       | `DEFAULT_ADMIN_ROLE` |
| **Отказаться от собственной**   | Самому себе (OpenZeppelin требует, чтобы подтверждение исходило от вызывающего) | Вы                   |

Варианты ролей — собственные для токена, поэтому элемент управления никогда не предложит роль, которой у токена нет. Как и при любой записи, строка полномочий и последствия отображаются перед кнопкой, так что дверь и её односторонний характер обозначаются до того, как вы подпишете.

***

## Что никогда не попадает ни в Bloom, ни в блокчейн

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

| Объект                                        | Где это хранится                                                                                                             |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Документы KYC/AML и персональные данные (PII) | В вашей собственной системе, с вашими собственными поставщиками и сроками хранения — **никогда** это приложение или блокчейн |
| Ваше решение допустить адрес                  | Внецепочечная запись; хранилище принадлежит вам                                                                              |
| Эффект этого решения в цепочке                | Одно булево значение — `isWhitelisted(address)` — записывается `batchAddToWhitelist`                                         |
| Обеспечение соблюдения правила                | Контракт актива, при каждом переводе                                                                                         |
| Кто может управлять активом                   | Роль, закрепленная в модуле allowlist актива, проверяемая при каждом запросе                                                 |

Для полного описания модели комплаенса см. [COMPLIANCE.md](/ru/prilozheniya-na-rome/bloom/compliance.md); а для механики двух контуров (EVM и Solana), которую используют ваши держатели, читайте [LANES.md](/ru/prilozheniya-na-rome/bloom/lanes.md).


---

# 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/issuing.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.