> 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/pt-br/guias-do-desenvolvedor/from-home.md). # Da chain de origem: acesse Rome a partir de outra chain Permita que usuários de outra chain alcancem seu app Rome sem sair de casa — traga ativos para dentro, aja e depois os retire novamente. Seus usuários não precisam ir para Roma. A partir da cadeia de origem deles — uma L2 como Arbitrum ou Monad, ou Solana — eles trazem ativos para dentro, usam seu app da Rome e retiram os ativos de volta. A ponte é on-chain e autorizada pela própria assinatura do usuário; você conecta seu app a ela por meio de uma única API. ## Como funciona * **Entrada (origem → Rome):** na rota do token de gás USDC via CCTP, a `settle_inbound_bridge_v2` instrução do programa Rome credita o usuário, sob um **EIP-712** `SettleAuthorization`, então não há um liquidante privilegiado. As outras rotas de entrada não usam essa instrução ou assinatura. O USDC embrulhado, ETH via Wormhole e SOL chegam diretamente como o token embrulhado na conta do usuário. O USDC da Solana em uma cadeia cujo token de gás é USDC precisa de mais uma transação, assinada pelo usuário, para transformar o embrulhado em gás. A cotação informa quais assinaturas uma rota precisa. * **Saída (Rome → origem):** `RomeBridgeWithdraw` (em [`rome-solidity`](https://github.com/rome-protocol/rome-solidity)) queima o ativo na Rome. O usuário então o reivindica na cadeia de origem com sua própria transação. * **Transporte:** Circle **CCTP** para USDC e a **Wormhole** ponte de tokens para ETH. Cadeias de origem na Solana usam transferências SPL simples na entrada e uma retirada da Rome na saída. Wormhole é a via de entrada apenas para ETH. Existe uma rota genérica via Wormhole apenas para saída, e cada ativo nela precisa ser habilitado pelos operadores da Rome primeiro. * **Orquestração:** o [`rome-bridge-api`](https://github.com/rome-protocol/rome-bridge-api) fora da cadeia cotiza uma rota, verifica a transação da cadeia de origem e subsidia a taxa de liquidação. Ele não mantém fundos nem chaves. Só pode disparar o que o usuário já assinou. ## Construa isso A API é pública na devnet em `https://bridge-api.devnet.romeprotocol.xyz`. `GET /v1/routes` lista todas as rotas ativas (ativo, via, direção, cadeia de origem, cadeia Rome, velocidades). As chamadas abaixo são as mesmas quatro que o SDK encapsula em `@rome-protocol/sdk/bridge` (`requestQuote`, `registerTransfer`, `getTransfer`, `reportStep`). A CLI executa todo o fluxo para você: `rome fund` e `rome bridge` para as transferências e `rome verify --path from-home` para uma ida e volta, conforme descrito na [CLI da Rome](/pt-br/produtos/rome-cli.md) página. ### Traga ativos para dentro 1. **Cotize a rota.** Envie a cadeia de origem do usuário, o ativo, o valor e os endereços. As cadeias entram como IDs CAIP-2, como `eip155:84532`; `romeChainId` é a sua cadeia Rome. Os nomes antigos `ethereum` e `solana` ainda são aceitos, mas estão obsoletos, e a API marca essas respostas com um cabeçalho `Sunset` . As formas completas da requisição e da resposta estão na [referência da 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" }' ``` Os valores são inteiros em unidades base, em strings (`"1000000"` é 1 USDC). Os valores de ETH estão em wei e, na saída, devem ser múltiplos de 10.000.000.000 wei (o embrulho tem 8 casas decimais); a API rejeita qualquer coisa mais precisa. A resposta lista as `etapas`. O usuário assina as transações de cada etapa marcada como `userSigns: true`, na ordem das etapas: transações EVM estão em `unsignedTxs`, instruções Solana em `unsignedTx`. Assine exatamente como retornado. Etapas sem nada para assinar são executadas pelo patrocinador assim que a Circle ou a Wormhole tiver atestado a transferência. A reivindicação de saída é a exceção, descrita abaixo: o usuário a constrói. 2. **Faça o usuário assinar.** Para uma cotação CCTP, isso é a aprovação de USDC e a queima na cadeia de origem. Se a cotação tiver uma entrada em `signatureRequests`, o usuário também assina essa EIP-712 `SettleAuthorization` assim que o hash da queima for conhecido; preencha o hash da queima e passe o resultado como `userSettleSig` na próxima chamada. Apenas a rota CCTP do token de gás tem uma. Rotas ETH via Wormhole, USDC por intenção embrulhada e rotas Solana não têm. 3. **Registre a transferência.** `POST /v1/transfers` com a cotação completa e `step1TxHash`, o hash da última transação na primeira etapa (a queima). A API verifica se a transação na cadeia de origem corresponde à cotação e retorna um `id`. 4. **Faça polling** `GET /v1/transfers/{id}` a cada poucos segundos até `resultado` é `complete`. O usuário então recebe fundos na Rome e pode usar seu app. As cadeias de origem na Solana seguem a mesma estrutura, com etapas diferentes. O usuário envia uma transferência SPL para a conta de token da conta Rome dele. A SOL chega como wSOL após essa única transferência. Em uma cadeia cujo token de gás é USDC, como Hadrian, o USDC precisa de uma segunda etapa: uma transação na Rome que o usuário assina e que transforma o embrulhado recebido em gás nativo. Qualquer outro token SPL passa pela `spl-solana-to-rome` rota, que usa o mint em `splAsset`. ### Retire ativos de volta Bridging para fora não é o fluxo de entrada rodando ao contrário. Ele tem mais de uma assinatura, e o usuário o conclui na cadeia de origem. Cotize-o com `direction` definido como `from-rome`. `sourceChain` nomeia o lado não-Rome e `destinationChainId` escolhe a cadeia na qual o usuário reivindica. Passe ambos: `destinationChainId` é o que decide a cadeia de reivindicação, e uma cotação sem isso usa Ethereum Sepolia por padrão, seja lá o que `sourceChain` diga: ```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" }' ``` Para USDC via CCTP, a cotação retorna duas etapas, e o usuário assina ambas: 1. **Na Rome, duas transações em ordem.** A primeira concede `RomeBridgeWithdraw` direitos de delegado sobre o wUSDC do usuário na Solana (`approve_spl`). A concessão cobre exatamente o valor dessa queima, então a cotação a inclui toda vez e o usuário a assina antes de cada queima. A segunda queima o wUSDC por meio de `RomeBridgeWithdraw`, que inicia a transferência CCTP. Registre a transferência com o hash da queima. A queima gasta wUSDC, o token que a cotação nomeia como `burnToken`, e não o USDC nativo de gás. Os fundos que entraram como gás não são o que é queimado, então, para uma ida e volta, traga USDC para dentro com `intent: "wrapper"`. 2. **Na cadeia de destino, a reivindicação.** Faça polling `GET /v1/transfers/{id}` até a etapa 2 estar `pronta`. Em seguida, ela carrega a `mensagem` e `atestação`. O usuário chama `receiveMessage(message, attestation)` no transmissor de mensagens da Circle na cadeia de destino (a cotação nomeia o transmissor e o domínio CCTP). Nada é patrocinado aqui, então o usuário precisa de gás nessa cadeia. Informe o hash da reivindicação com `POST /v1/transfers/{id}/steps/2`. ETH via Wormhole tem a mesma estrutura. O usuário concede os mesmos direitos de delegado sobre wETH, queima wETH na Rome e espera os guardiões da Wormhole assinarem. Em seguida, o usuário resgata na Ethereum com sua própria transação: `completeTransferAndUnwrapETH` na ponte de tokens que a cotação nomeia (`claimTokenBridge`), usando a mensagem assinada (`vaa`) da etapa 2. Retirar para um endereço Solana não tem etapa de reivindicação. USDC é uma única transação na Rome que faz a retirada para a conta Solana do usuário. SOL é uma etapa na Rome com três transações: a mesma concessão de delegado sobre wSOL, a criação opcional da conta de token wSOL do destinatário na Solana (omitida quando ela já existe) e a retirada por meio de `RomeBridgeWithdraw`. **A primeira transferência de saída precisa de uma conta ativada.** Uma queima CCTP cria uma conta de mensagem na Solana, e a conta do usuário na Rome precisa ter lamports suficientes para pagá-la. Uma carteira nova não tem, então a primeira transferência de saída falha até que o usuário faça a ativação uma vez. A verificação é se a conta tem pelo menos 15.000.000 lamports. Leia-os com `account_lamports(bytes32)` no precompile CPI em `0xff00000000000000000000000000000000000008`, passando a conta de autenticação externa do usuário na Solana (a CLI faz essa leitura para você). A ativação chama `activate()` no `SimpleActivator` contrato listado no [registro](https://github.com/rome-protocol/rome-registry) da sua cadeia, e a chamada inclui um pagamento no token de gás da cadeia. Em Hadrian, isso é 2 USDC. A CLI faz isso com `rome activate `, e `rome bridge --to` interrompe e manda você executá-lo se a conta não estiver pronta. A reserva cobre uma queima, e o aluguel retorna depois que a Circle atesta a queima, o que leva cerca de 30 minutos. Uma segunda queima antes disso, ou uma conta que foi drenada desde que foi ativada, precisa de `topUpUserPda(lamports)` no mesmo contrato, porque `activate()` reverte assim que a conta tiver sido ativada. `rome activate` escolhe a chamada correta. Transferências de entrada não precisam de ativação. A cotação não inclui ativação como uma etapa, então seu app precisa verificar a conta e oferecê-la antes da primeira cotação de saída. ## Leia o código * [appia](https://github.com/rome-protocol/appia) — um app de origem: usuários trazem USDC de sua cadeia de origem e usam DeFi do lado Rome sem sair dela. * [rome-bridge-api](https://github.com/rome-protocol/rome-bridge-api) — o orquestrador (cotação → verificação → patrocínio). ## O que vem a seguir * [Recebendo fundos](/pt-br/recursos/faucets.md) — o mesmo caminho da ponte financia uma carteira dev nova. * [Implante em Solidity](/pt-br/guias-do-desenvolvedor/deploy-solidity.md) — coloque seu app na 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/pt-br/guias-do-desenvolvedor/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.