> 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/open-to-solana-users.md). # Abra seu contrato para usuários da Solana Implante um contrato Solidity na Rome (testnet Hadrian, mainnet Rubicon) e abra-o para carteiras Solana — o que o contrato precisa, como um usuário de carteira Solana o chama, endereços por rede e um lançame ch Uma implantação, dois tipos de usuários. Um contrato em Rome é acessado por usuários do MetaMask com sua chave EVM e por usuários de carteira Solana (Solflare, por exemplo) com sua chave Solana — mesmo endereço, mesmo estado. Esta página é o caminho ponta a ponta: implantar, deixar o contrato pronto para Solana, conectar o canal Solana no seu app e colocar em produção na mainnet. ## 1. Implemente na rede que você quiser As chains Rome são alvos EVM padrão: Hardhat, Foundry, viem e ethers funcionam sem alterações (passo a passo completo em [Deploy de Contratos Solidity](/pt-br/guias-do-desenvolvedor/deploy-solidity.md)). | Rede | ID da cadeia | RPC | Explorador | Token de gas | Como obter gas | | ------------------------------------------------ | ------------ | ------------------------------------------- | ------------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [**Rubicon**](/pt-br/redes/rubicon.md) (mainnet) | `7531` | `https://rubicon.mainnet.romeprotocol.xyz/` | [via-rubicon.mainnet.romeprotocol.xyz](https://via-rubicon.mainnet.romeprotocol.xyz/) | USDC | Faça bridge de USDC do Ethereum (CCTP) ou da Solana com o [Rome Bridge](https://bridge-api.mainnet.romeprotocol.xyz/); ele entra como gas | | **Hadrian** (testnet) | `200010` | `https://hadrian.testnet.romeprotocol.xyz/` | [via-hadrian.testnet.romeprotocol.xyz](https://via-hadrian.testnet.romeprotocol.xyz/) | test USDC | Faça bridge de USDC de teste a partir de uma testnet ([Torneiras](/pt-br/recursos/faucets.md)) ou faça wrap a partir de uma carteira da devnet Solana no [Rome App](https://app.devnet.romeprotocol.xyz) | Gas é USDC com 18 casas decimais no lado EVM; não há faucet de Rome em nenhuma rede. Escrever custa mais gas do que a intuição sobre Ethereum sugere, porque a maior parte do custo é criar contas Solana: um destinatário nunca usado, uma nova conta de token, um contrato implantado. Use `eth_estimateGas`o que a instrumentação padrão faz, e nunca codifique 21.000. Medido no Hadrian, implantar um contrato de 10 bytes estimou e usou 1.147.921 gas, e uma transferência nativa para um endereço nunca usado, 1.086.961, contra 21.000 para uma transferência para um endereço existente. Rome cobra o gas realmente usado, que nessas medições nunca foi maior do que a estimativa. Financie com alguns USDC antes do primeiro deploy. Verifique a fonte no explorador depois ([Verificar contratos](/pt-br/guias-do-desenvolvedor/verify-contracts.md); o verificador da mainnet é `https://verify.mainnet.romeprotocol.xyz`). Desenvolva no Hadrian e depois reimplante os mesmos artefatos no Rubicon com o chain id e os endereços do wrapper da mainnet trocados; nada no contrato muda entre as redes. Rubicon ainda não está no registro público, `create-rome-app` ou `rome-cli` então ferramentas que leem os valores da chain a partir dele não conseguem mirá-lo; preencha os valores manualmente a partir de [Rubicon](/pt-br/redes/rubicon.md). O gas no Rubicon é USDC real, cerca de dez vezes o preço de gas do Hadrian, então um deploy lá custa dinheiro de verdade. ## 2. O que torna um contrato pronto para Solana A identidade EVM de um usuário Solana é sua **endereço sintético**, `keccak256(solana_pubkey)[12:]`: uma `msg.sender`comum, com um nonce comum. A maioria dos contratos não precisa de nenhuma alteração. As três coisas que importam: * **Receba valor como ERC-20, não `msg.value`.** Os fundos de um usuário Solana são tokens SPL na carteira dele, vistos no lado EVM como o wrapper do token (`wUSDC`, `wETH`, `wSOL`). O sintético não mantém nada em repouso e os ativos do usuário chegam como o wrapper, então faça pull com `transferFrom` depois de um `approve` e retorne com `transfer`. Cada usuário concede uma vez ao wrapper o direito de delegado SPL antes do primeiro pull ([Uma única vez: conceda ao wrapper](/pt-br/guias-do-desenvolvedor/dual-lane-app.md#one-time-grant-the-wrapper)). Um `pagável` ponto de entrada só funciona depois que o sintético recebeu gas nativo ( `rome_composeExternalDepositV1`do caminho relay), o que o modelo de financiar e varrer não faz. Um vault ERC-20, AMM ou mercado de empréstimo já existente tem o formato certo. * **Use os wrappers canônicos.** Cada chain tem um wrapper por mint; os endereços estão em [referência de Endereços de Contrato](/pt-br/referencia/contract-addresses.md) (o do Hadrian também está no [registro](https://github.com/rome-protocol/rome-registry)público). Aponte os construtores para esses endereços; não implante o seu próprio. * **Ajuste ao orçamento atômico onde uma carteira assina.** Uma carteira Solana assina uma transação Solana, então uma chamada no canal Solana precisa caber nisso: cerca de 1,4 milhão de compute units, 64 contas, 4 KB ([Restrições](/pt-br/conceitos-principais/constraints.md)). Medido no Hadrian: uma transferência, um approve e um supply na Aave cabem; um swap na Uniswap V3 cabe com pouca folga (cerca de 1,24M CU); um borrow na Aave não cabe e segue pelo caminho relay na próxima seção. Meça com o `computeUnitsConsumed`recibo da Solana, solicitando a transação com `maxSupportedTransactionVersion: 1` (as pernas Rome são transações v1; sem isso o campo aparece como 0). O que você não precisa: um programa Solana, uma bridge, uma segunda implantação ou qualquer Solidity específico de Rome. Se o contrato também chamar programas Solana por meio dos precompiles, veja [Chamar Solana a partir da EVM](/pt-br/guias-do-desenvolvedor/call-solana-from-evm.md). ## 3. Permita que uma carteira Solana o chame O caminho EVM do seu app não muda (MetaMask + `submitRomeTx`, ou viem/ethers puro). Para o caminho Solana há dois formatos. **O canal do SDK — uma transação Solana v1 por chamada.** [`@rome-protocol/sdk`](https://github.com/rome-protocol/rome-sdk-ts) (`submitRomeTxV1`) faz o proxy compor uma transação Solana v1 para a sua chamada EVM (até 64 contas e 4 KB, sem address lookup table; não há instrução ComputeBudget, carteira de tesouro ou descoberta de contas no seu código). A carteira assina duas vezes com a mesma chave: primeiro uma mensagem de autorização legível (`Autorização Rome` em uma linha, `0x` e o hash da transação EVM na linha seguinte), que a chain verifica por meio do programa Ed25519, e depois a transação. O app envia a transação assinada para o RPC da Solana; a chamada retorna o hash da transação EVM e seu recibo. Antes de a carteira assinar a transação, o SDK a verifica: o pagador é o único assinante, apenas o programa Rome e o verificador Ed25519 executam, a instrução Rome carrega exatamente a chamada que o usuário autorizou e não há taxa de prioridade. Qualquer outra coisa é recusada. Se uma chamada não couber em uma transação, o composer a recusa e o SDK a entrega ao proxy para relay, com a mesma assinatura de autorização, para que o usuário ainda veja um único prompt de autorização. O resultado então tem `route: "relay"`. As regras para chamadas relay e chamadas longas estão em [Chamadas retransmitidas e chamadas longas](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md#relayed-calls-and-long-calls)Uma chamada relay é paga no gas nativo da chain, então o sintético precisa de um saldo de gas: `fundSyntheticGas(deps, amountWei)` move o token de gas da chain (USDC no Hadrian e no Rubicon) da conta de token da carteira para ele, em uma única transação v1 assinada pela carteira. A perna de funding (`buildFundLeg`) e a criação da conta de token da carteira antes de um sweep são instruções Solana comuns; `submitSolanaInstructionsV1` também as envia como transações v1, assinadas pelo mesmo signer da carteira, sem envolver proxy. A própria chamada do sweep (`buildSweepLeg`, `HelperProgram.transfer_spl`) passa por `submitRomeTxV1` como qualquer outra, e o proxy localiza as contas de token. `submitRomeTxV1` não cria por conta própria a conta de um novo sintético: antes da primeira chamada que mova valor, verifique `isSyntheticProvisioned(...)` e, se for falso, envie `buildCreatePdaCall(synthetic)` por meio de `submitRomeTxV1` uma vez. Um passo a passo completo de depósito e retirada com código está em [Construir um app de duas lanes](/pt-br/guias-do-desenvolvedor/dual-lane-app.md); a mecânica está em [Chamar EVM a partir da Solana](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md). O anterior `submitRomeTxSolanaLane`que monta uma transação Solana legada no cliente, ainda está no SDK como o caminho mais antigo. **De onde vem cada `deps` valor.** O `deps` objeto do SDK tem cinco campos obrigatórios (os demais, como `fetchImpl` e os timeouts, são opcionais). Quatro vêm da chain e um vem da carteira: | `deps` campo | De onde vem | getter do Registry (`@rome-protocol/registry` v0.2.0) | | ------------ | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | `proxyUrl` | a URL RPC da chain | `getChain(chainId).rpcUrl` | | `chainId` | o chain ID | `getChain(chainId).chainId` | | `programId` | o ID do programa Rome em que a chain é executada | `getChain(chainId).romeEvmProgramId` | | `connection` | um RPC Solana para o cluster da chain, onde a transação assinada é enviada (devnet para Hadrian, mainnet para Rubicon) | `getChain(chainId).solana.rpc` (uma URL pública de devnet para Hadrian); para mainnet use um RPC próprio | | `signer` | o `LaneSigner`, ou um `Keypair` em scripts | nenhum | Os construtores de pernas usam valores que não estão em `deps`. O `mint` (chamado de `usdcMint` no passo a passo) é o mint Solana do token de gas, obtido de `getTokens(chainId)` (a entrada com `kind: "gas"`, campo `mintId`). O endereço do wrapper wUSDC não é uma entrada do construtor de pernas; você o usa para as chamadas ERC-20, e ele é a entrada com `kind: "spl_wrapper"` e símbolo `wUSDC` (campo `address`). O registry cobre Hadrian. Para Rubicon, preencha manualmente: `proxyUrl` `https://rubicon.mainnet.romeprotocol.xyz/`, `chainId` `7531`, `programId` `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX`, `mint` `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`, o wrapper da tabela na próxima seção, e um RPC mainnet Solana para `connection`. [Rubicon](/pt-br/redes/rubicon.md) tem a lista completa. **Os endpoints externos-V1 do proxy — o mesmo canal sem o SDK.** O SDK envolve a composição atômica, o relay e o depósito de gas (`fundSyntheticGas`). As chamadas RPC brutas continuam para clientes que não usam o SDK, e incluem a composição iterativa, que o SDK não encapsula. A carteira assina uma mensagem Ed25519 sobre a chamada (o formato legível `Autorização Rome\n0x` ou o hash bruto), e o proxy ou compõe a(s) transação(ões) Solana para a carteira assinar (`rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1` + `rome_submitSignedV1Plan`) ou executa tudo por conta própria com uma assinatura de carteira (`rome_relayUnsignedV1`, após um `rome_composeExternalDepositV1` (o `fundSyntheticGas`do SDK) que financia o saldo de gas do sintético; chamadas relay gastam a partir dele, então recarregue quando estiver baixo). Formas dos métodos em [Suporte a JSON-RPC](/pt-br/referencia/json-rpc.md); as regras de autorização em [Chamar EVM a partir da Solana](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md#the-external-v1-endpoints). Use o relay para qualquer coisa iterativa e o canal do SDK para tudo que couber. De qualquer forma, o contrato vê uma transação normal vinda do endereço sintético e o usuário nunca detém uma chave EVM. ## 4. Endereços de wrapper por rede | Rede | `wUSDC` wrapper | Outros wrappers | | ---------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Rubicon (7531) | `0x0952d233b0c254cd375f3bfb3e5869c1a906f9b3` | `wETH` `0x01e8b3573da1d4b7b4b1ce0932cf07c8af0c92e9`, `wSOL` `0xc4e29e0f726a906e93277cbbc37bf27a9848a113` | | Hadrian (200010) | `0xbce339ba4c3a8de3bb8af1c5539e6ac11da3112d` | `wETH` `0x02aeace038269f9961c93d04dcacd6fb3adfa55f`, `wSOL` `0x39f36444fcb79b3e691544aee2a832ebef54ca9f` | O token nativo de gas aparece como `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` nas listas de tokens; ele não é um contrato ERC-20. Os wrappers carregam as casas decimais do mint SPL, não 18: wUSDC 6, wETH 8, wSOL 9. ## 5. Checklist de lançamento 1. Implantado no Hadrian; o caminho EVM funciona no MetaMask. 2. Todo ponto de entrada que move valor é baseado em ERC-20 e aponta para o wrapper canônico da chain. 3. Uma carteira Solana que assina transações v1 (Solflare faz isso na devnet hoje; Phantom ainda não) completa a ida e volta total no Hadrian: provisionar o sintético (`create_pda`uma vez) → perna de funding → conceder → aprovar → chamar → perna de sweep, usando o canal do SDK; ou o caminho relay se a chamada for iterativa. 4. O `computeUnitsConsumed` de cada chamada do canal Solana 5. é lido do recibo Solana e fica dentro do orçamento atômico, ou a chamada é roteada pelo relay. `isEnabled(user)` A concessão do wrapper está no fluxo de primeiro depósito do seu app para ambos os canais: `approve_spl` é verificado e[Uma única vez: conceda ao wrapper](/pt-br/guias-do-desenvolvedor/dual-lane-app.md#one-time-grant-the-wrapper)). 6. é enviado uma vez quando ele é falso ( 7. Fonte verificada no explorador. `deps` valores são preenchidos manualmente a partir de [Rubicon](/pt-br/redes/rubicon.md). A mesma ida e volta é executada uma vez com fundos reais, usando uma carteira que você já verificou que assina transações v1 na mainnet. ## O que vem a seguir * [Construir um app de duas lanes](/pt-br/guias-do-desenvolvedor/dual-lane-app.md) — o exemplo de vault, passo a passo, ambas as carteiras * [Chamar EVM a partir da Solana](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md) — endereços sintéticos, descoberta de contas, os endpoints externos-V1 * [Deploy de Contratos Solidity](/pt-br/guias-do-desenvolvedor/deploy-solidity.md) · [Verificar contratos](/pt-br/guias-do-desenvolvedor/verify-contracts.md) · [referência de Endereços de Contrato](/pt-br/referencia/contract-addresses.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 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/open-to-solana-users.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.