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

# Две полосы

Одно развертывание токена, два мира кошельков. Оба маршрута выполняют **одни и те же контракты** с **одним и тем же комплаенс-фильтром** — они различаются только тем, кто подписывает и как транзакция попадает в цепочку.

## EVM-канал

Стандартный набор инструментов Ethereum без изменений: кошелёк подписывает транзакцию EVM, конечная точка JSON-RPC цепочки её принимает, токен-контракт применяет allowlist. Для интеграции ничего специфичного для Bloom не требуется — измеренная стоимость gated-перевода составляет \~3.1M gas (газ в Rome номинирован в USDC; обычный нативный перевод — \~1.48M для масштаба).

## Solana-канал

Кошелёк Solana управляет теми же контрактами EVM **нативно — нигде не существует ключа EVM**:

1. **Идентичность.** Адрес пользователя на стороне EVM *синтетический*: детерминированно выводится как `keccak256(solana_pubkey)[12..32]`. Программа Rome EVM выводит его в цепочке на основе фактического подписанта транзакции — подделать его нельзя, и приватного ключа secp256k1 для него не существует, поэтому **только подпись Solana когда-либо может инициировать действия для этого адреса**.
2. **Обнаружение.** Клиент запрашивает у RPC цепочки (`rome_emulateCallAccounts`) какие аккаунты Solana затронет вызов EVM; эмуляция также определяет, какие из них будут writable (вызов должен включать `value` — от этого зависит, будет ли writable аккаунт баланса получателя).
3. **Отправка.** Клиент формирует инструкцию `DoTxUnsigned` — *неподписанный* payload EIP-1559, авторизованный подписью Solana, — а также инструкции compute budget (heap 250 KB, 1.35M CU) и исключённое в обнаружении fee-pool account. Кошелёк подписывает одну транзакцию Solana; готово.

   **Размер, измеренный на этом развертывании 2026-07-30:** покупка через витрину приводит к **22 аккаунтам** и сериализуется в **1,061 байт** при лимите legacy 1232 байта — запас 171 байт, примерно ещё пять аккаунтов. Следовательно, сегодня lookup table не требуется. Сценарий, затрагивающий больше — например, ещё не созданный associated token account, первый держатель — всё ещё может превысить лимит, и после 1232 байт клиент откатывается к v0-транзакции через address lookup table, которую создаёт для этой цели.

   **Такой fallback дорог для кошелька:** каждый chunk расширения ALT и повторная отправка v0 — это отдельный `signTransaction`, поэтому одна покупка превращается в три или четыре запроса на подтверждение. У Hadrian уже есть постоянная таблица dApp, в которой хранятся аккаунты этих контрактов — ссылка на неё и есть решение, чего клиент канала пока не умеет.
4. **Подтверждение.** Транзакция подтверждается в Solana; представление EVM догоняет чуть позже (инструменты опрашивают nonce перед отправкой следующего вызова).

### ТОЛЬКО АТОМАРНО — жёсткая граница канала

`DoTxUnsigned` — это **одна транзакция EVM, выполненная внутри одной транзакции Solana** атомарной VM Rome. Итеративная VM — та, которая распределяет одно выполнение EVM на несколько транзакций Solana, — через этот канал пока недоступна, поэтому **вызов, который не помещается атомарно, вообще не может использовать этот канал.** Обходного пути нет и добавлять его не следует; решение для вызова, который не помещается, — сделать вызов меньше.

Два механизма часто принимают за него, но ни один из них им не является:

* **Fallback v0 + lookup table** — это более крупная *оболочка*, а не иное исполнение: та же самая одиночная инструкция, упакованная в формат транзакции с местом для гораздо большего числа ключей аккаунтов. По сегодняшним измерениям покупка через витрину в этом не нуждается (1,061 байт из 1232), и даже если бы нуждалась, вызов всё равно оставался бы атомарным.
* **Многошаговый путь — это не многоэтапное исполнение.** Run в Bloom `называет` свои шаги *legs* — approve, затем buy — и каждый из них является **полноценной транзакцией, подписываемой отдельно и атомарной сама по себе**. Rome также называет legs фрагменты ОДНОГО разделённого исполнения. Это приложение использует первый смысл и никогда не должно запрашивать второй. Слово совпадает; механизмы — нет.

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

Измерено в Rome devnet, по одной подписи на сценарий — диапазоны, наблюдавшиеся на двух цепочках:

| Поток в Solana-канале                                                     | CU         |
| ------------------------------------------------------------------------- | ---------- |
| Перевод RWA с проверкой доступа                                           | \~339–381K |
| Разрешение wUSDC                                                          | \~189–191K |
| Покупка в витрине (approve + buy = всего 2 подписи)                       | \~730–796K |
| Слив денежной части на собственный токен-аккаунт кошелька                 | \~42–54K   |
| Обычный перевод средств                                                   | \~47K      |
| `TestApprover.approve` — допуск по allowlist, **подписывается кошельком** | 220,794    |

Для сравнения, лимит вычислений Solana на транзакцию составляет 1.4M CU — самый тяжёлый поток Bloom использует лишь чуть больше половины этого значения.

## Кастодиальность: почему RWA остаётся на синтетическом

Вопрос проектирования, на который должен ответить каждый разрешённый актив: *может ли токен утечь за пределы контура комплаенса?* В Solana-канале ответ структурный, а не политический:

* **RWA находится в состоянии EVM.** Его балансы хранятся как данные внутри аккаунтов программы Rome EVM. У него **нет SPL mint** , нет представления в виде token account, нет ничего нативного для Solana, что можно было бы переместить. (Это сделано намеренно — обёрнутая/зеркальная версия была бы лазейкой.)
* **Инфраструктура на стороне Solana не может его затронуть.** Этапы перемещения актива в этом канале (`create_ata`, SPL-переводы, sweeps) работают с SPL token account; балансы в хранилище EVM не имеют такого аккаунта. Не существует инструкции, которая перемещает баланс EVM на token account Solana.
* **Только подпись Solana владельца управляет синтетическим**, и каждое движение, которое она может выразить, — это вызов токен-контракта, который проходит через allowlist, поэтому перевод на адрес вне белого списка откатывается одинаково, независимо от того, подписан он ключом EVM или ключом Solana.
* **Денежный этап — намеренное исключение.** wUSDC (доход, поступления от продажи) обеспечен SPL и *должен* проходить полный цикл: выходной этап (`transfer_spl`) перемещает его из синтетического в собственный associated token account кошелька, с end-to-end верификацией. Актив остаётся внутри контура; деньги свободно движутся.

Два практических следствия, если говорить прямо: интерфейс кошелька Solana не покажет удержание RWA (для отображения просто нет SPL-токена) — поверхностью для позиций является приложение Bloom; а утраченный ключ Solana восстанавливается через процесс эмитента ([COMPLIANCE.md](/ru/prilozheniya-na-rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), а не путём вывода актива вне установленного канала — именно это и нужно разрешённому активу.


---

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