> 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/rukovodstva-dlya-razrabotchikov/from-home.md). # Из дома: доберитесь до Rome из другой цепочки Позвольте пользователям из другой цепочки получать доступ к вашему приложению Rome, не покидая «дом» — вводите активы, выполняйте действия, затем выводите их обратно. Вашим пользователям не нужно переходить в Rome. С их домашней сети — L2 вроде Arbitrum или Monad, либо Solana — они заводят активы, используют ваше приложение Rome и выводят активы обратно. Мост работает on-chain и авторизуется собственной подписью пользователя; вы подключаете к нему ваше приложение через один API. ## Как это работает * **Входящий (home → Rome):** по маршруту USDC с газ-токеном поверх CCTP, `settle_inbound_bridge_v2` инструкция программы Rome кредитует пользователя в рамках подписанного **EIP-712** `SettleAuthorization`, поэтому привилегированного исполнителя нет. Другие входящие маршруты не используют эту инструкцию или подпись. Wrapper USDC, ETH через Wormhole и SOL поступают напрямую как wrapper-токен на счёт пользователя. USDC Solana в сети, где газ-токен — USDC, требует ещё одной транзакции, подписанной пользователем, чтобы преобразовать wrapper в газ. Котировка показывает, какие подписи нужны для каждого маршрута. * **Исходящий (Rome → home):** `RomeBridgeWithdraw` (в [`rome-solidity`](https://github.com/rome-protocol/rome-solidity)) сжигает актив в Rome. Затем пользователь забирает его в домашней сети собственной транзакцией. * **Транспорт:** Circle **CCTP** для USDC и **Wormhole** моста токенов для ETH. Домашние сети Solana используют обычные SPL-переводы на входе и вывод через Rome. Wormhole — это входящий канал только для ETH. Универсальный маршрут Wormhole существует только для исходящего направления, и каждый актив на нём должен быть сначала включён операторами Rome. * **Оркестрация:** внечейн [`rome-bridge-api`](https://github.com/rome-protocol/rome-bridge-api) формирует котировку маршрута, проверяет транзакцию в исходной сети и оплачивает комиссию за settlement. Он не хранит средства и не имеет ключей. Он может только инициировать то, что пользователь уже подписал. ## Соберите это Публичный API доступен в devnet по адресу `https://bridge-api.devnet.romeprotocol.xyz`. `GET /v1/routes` возвращает все активные маршруты (актив, канал, направление, исходная сеть, сеть Rome, скорости). Нижеописанные вызовы — это те же четыре, которые SDK оборачивает в `@rome-protocol/sdk/bridge` (`requestQuote`, `registerTransfer`, `getTransfer`, `reportStep`). CLI выполняет весь поток за вас: `rome fund` и `rome bridge` для переводов и `rome verify --path from-home` для обратного маршрута, как описано в [Rome CLI](/ru/produkty/rome-cli.md) странице. ### Завести активы 1. **Получите котировку маршрута.** Передайте исходную сеть пользователя, актив, сумму и адреса. Сети передаются как идентификаторы CAIP-2, например `eip155:84532`; `romeChainId` — это ваша сеть Rome. Старые названия `ethereum` и `solana` по-прежнему принимаются, но считаются устаревшими, и API помечает такие ответы заголовком `Sunset` Полные формы запроса и ответа приведены в [справочнике API](https://github.com/rome-protocol/rome-bridge-api/blob/main/docs/API.md). ```bash curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \ -H 'Content-Type: application/json' \ -d '{ "asset": "USDC", "direction": "to-rome", "sourceChain": "eip155:84532", "romeChainId": "200010", "amount": "1000000", "sender": { "ethereum": "0xUSER" }, "recipient": "0xUSER" }' ``` Суммы задаются как целые значения в базовых единицах в строках (`"1000000"` — это 1 USDC). Суммы ETH задаются в wei и при выводе должны быть кратны 10 000 000 000 wei (у wrapper 8 знаков после запятой); API отвергает более точные значения. Ответ перечисляет `шаги`. `userSigns: true`, в порядке шагов: EVM-транзакции находятся в `unsignedTxs`, инструкции Solana — в `unsignedTx`. Подписывайте их в точности в том виде, в каком они возвращены. Шаги, для которых нечего подписывать, выполняет спонсор после того, как Circle или Wormhole подтвердит перевод. Исключение — запрос на исходящий claim, описанный ниже: его формирует пользователь. 2. **Пусть пользователь подпишет.** Для котировки CCTP это разрешение на USDC и сжигание в исходной сети. Если в котировке есть запись в `signatureRequests`, пользователь также подписывает эту EIP-712 `SettleAuthorization` после того, как станет известен хэш сжигания; подставьте хэш сжигания и передайте результат как `userSettleSig` в следующем вызове. Только маршрут CCTP с газ-токеном имеет такую подпись. Маршруты Wormhole ETH, USDC с wrapper-intent и Solana её не имеют. 3. **Зарегистрируйте перевод.** `POST /v1/transfers` с полной котировкой и `step1TxHash`, хэш последней транзакции первого шага (сжигания). API проверяет, что транзакция в исходной сети соответствует котировке, и возвращает идентификатор перевода `id`. 4. **Опросите** `GET /v1/transfers/{id}` каждые несколько секунд, пока `результат` является `не будет завершён`. Затем пользователь получает финансирование в Rome и может использовать ваше приложение. Домашние сети Solana следуют той же схеме, но с другими шагами. Пользователь отправляет SPL-перевод на токен-аккаунт своего аккаунта Rome. После этого SOL поступает как wrapped SOL после одной транзакции. В сети, где газ-токен — USDC, например в Hadrian, для USDC нужен второй шаг: транзакция в Rome, которую подписывает пользователь и которая превращает поступивший wrapper в нативный газ. Любой другой SPL-токен проходит через `spl-solana-to-rome` маршрут, который принимает mint в `splAsset`. ### Вывести активы обратно Вывод не является обратным потоком входящего направления. В нём больше одной подписи, и пользователь завершает его в домашней сети. Получите котировку для него с `direction` установленным в `from-rome`. `sourceChain` обозначает не-Rome сторону, а `destinationChainId` выбирает сеть, в которой пользователь будет получать активы. Передайте оба поля: `destinationChainId` — это то, что определяет сеть получения, а котировка без него по умолчанию использует Ethereum Sepolia, что бы ни `sourceChain` сказало: ```bash curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \ -H 'Content-Type: application/json' \ -d '{ "asset": "USDC", "direction": "from-rome", "sourceChain": "eip155:84532", "destinationChainId": 84532, "romeChainId": "200010", "amount": "1000000", "sender": { "rome": "0xUSER" }, "recipient": "0xUSER" }' ``` Для USDC через CCTP котировка возвращает два шага, и пользователь подписывает оба: 1. **В Rome — две транзакции по порядку.** Первая предоставляет `RomeBridgeWithdraw` права делегата на wUSDC пользователя в Solana (`approve_spl`). Эта выдача покрывает ровно сумму этого burn, поэтому котировка включает её каждый раз, и пользователь подписывает её перед каждым burn. Вторая сжигает wUSDC через `RomeBridgeWithdraw`Это запускает перевод CCTP. Зарегистрируйте перевод по хэшу сжигания. Burn расходует wUSDC — токен, который в котировке указан как `burnToken`, а не нативный газовый USDC. Средства, которые пришли как газ, не сжигаются, поэтому для обратного маршрута заведите USDC с `intent: "wrapper"`. 2. **На целевой сети — claim.** Опросите `GET /v1/transfers/{id}` пока шаг 2 не станет `готов`. Затем он переносит `сообщение` и `аттестацию`. Пользователь вызывает `receiveMessage(message, attestation)` в message transmitter Circle на целевой сети (в котировке указаны transmitter и домен CCTP). Здесь ничего не спонсируется, поэтому пользователю нужен газ в этой сети. Передайте хэш получения через `POST /v1/transfers/{id}/steps/2`. ETH через Wormhole имеет ту же схему. Пользователь предоставляет те же права делегата на wETH, сжигает wETH в Rome и ждёт, пока guardians Wormhole подпишут сообщение. Затем пользователь погашает его в Ethereum собственной транзакцией: `completeTransferAndUnwrapETH` на token bridge, который указан в котировке (`claimTokenBridge`), используя подписанное сообщение (`vaa`) из шага 2. Вывод на адрес Solana не имеет шага claim. USDC — это одна транзакция в Rome, которая выводит средства на токен-аккаунт пользователя в Solana. SOL — это один шаг в Rome с тремя транзакциями: тот же grant делегата на wSOL, необязательное создание токен-аккаунта wSOL получателя в Solana (пропускается, если он уже существует), и вывод через `RomeBridgeWithdraw`. **Для первого исходящего перевода нужен активированный аккаунт.** Burn CCTP создаёт message account в Solana, и аккаунт пользователя в Rome должен хранить достаточно lamports, чтобы оплатить его. Новый кошелёк этого не делает, поэтому первый исходящий перевод завершится ошибкой, пока пользователь не выполнит активацию один раз. Проверка состоит в том, что на аккаунте есть минимум 15 000 000 lamports. Прочитайте их с помощью `account_lamports(bytes32)` в CPI precompile по адресу `0xff00000000000000000000000000000000000008`, передавая внешний auth-аккаунт пользователя в Solana (CLI выполняет это чтение за вас). Активация вызывает `activate()` на `SimpleActivator` контракте, указанном в [реестре](https://github.com/rome-protocol/rome-registry) для вашей сети, и вызов сопровождается оплатой в газ-токене сети. Для Hadrian это 2 USDC. CLI делает это с помощью `rome activate `, и `rome bridge --to` останавливается и сообщает вам запустить это, если аккаунт не готов. Резерв покрывает одно сжигание, а аренда возвращается после того, как Circle подтвердит burn, что занимает около 30 минут. Для второго burn до этого момента, или если после активации аккаунт был опустошён, требуется `topUpUserPda(lamports)` на том же контракте, потому что `activate()` возвращает ошибку после того, как аккаунт уже активирован. `rome activate` выбирает правильный вызов. Входящие переводы не требуют активации. Котировка не включает активацию как шаг, поэтому ваше приложение должно проверить аккаунт и предложить это до первой исходящей котировки. ## Прочитайте код * [appia](https://github.com/rome-protocol/appia) — приложение from-home: пользователи заводят USDC из своей домашней сети и используют DeFi на стороне Rome, не покидая её. * [rome-bridge-api](https://github.com/rome-protocol/rome-bridge-api) — оркестратор (quote → verify → sponsor). ## Что дальше * [Получение финансирования](/ru/resursy/faucets.md) — тот же путь моста пополняет новый dev-кошелёк. * [Разверните Solidity](/ru/rukovodstva-dlya-razrabotchikov/deploy-solidity.md) — разместите ваше приложение в Rome. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rome.builders/ru/rukovodstva-dlya-razrabotchikov/from-home.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.