Две полосы

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

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), а не путём вывода актива вне установленного канала — именно это и нужно разрешённому активу.