> 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/apps-na-rome/bloom/lanes.md).

# As duas vias

Uma implantação de um token, dois mundos de carteira. Ambos os caminhos executam o **mesmo contrato** com o **mesmo portal de compliance** — eles diferem apenas em quem assina e em como a transação chega à chain.

## Caminho EVM

Ferramentas padrão da Ethereum, inalteradas: a carteira assina uma transação EVM, o endpoint JSON-RPC da chain a aceita, o contrato do token aplica a lista de permissões. Nada específico do Bloom para integrar.

O gas do Rome é denominado em USDC, e uma escrita custa mais do que seu equivalente na Ethereum sempre que precisa criar contas Solana (um detentor de primeira vez, uma nova conta de token). Use `eth_estimateGas`, como fazem as ferramentas padrão, e nunca fixe 21.000; a estimativa inclui a criação da conta, e o Rome cobra o gas realmente usado. Uma transferência com gate também paga pela verificação da lista de permissões, então custa mais do que uma transferência simples do mesmo tamanho.

## rota Solana

Uma carteira Solana conduz os mesmos contratos EVM **nativamente — não existe nenhuma chave EVM em lugar algum**. Cada chamada é uma transação Solana v1 que o proxy da chain compõe para a carteira assinar. Não há tabelas de consulta de endereços nem instruções de orçamento de computação para montar: o proxy define o orçamento de compute e heap por conta própria.

1. **Identidade.** O endereço do lado EVM do usuário é *sintética*: derivado deterministicamente como `keccak256(solana_pubkey)[12..32]`. O programa EVM do Rome o deriva on-chain a partir do signatário real da transação — ele não pode ser falsificado, e não existe uma chave privada secp256k1 para ele, então **a assinatura Solana é a única coisa que pode acionar esse endereço**.
2. **Autorize.** O app monta a chamada como um payload EIP-1559 não assinado, usando o nonce, o preço do gas e a estimativa de gas que lê da chain. A carteira assina uma mensagem legível — ela aparece como *Autorização Rome* seguida por um hash da chamada — o que prova que a chave Solana autoriza exatamente este payload EVM. Este é o primeiro prompt, e o proxy não comporá a chamada sem ele.
3. **Compor.** O app envia o payload e essa assinatura ao proxy. O proxy verifica a assinatura, emula a chamada para descobrir quais contas Solana ela toca e quais são graváveis, e retorna uma única transação Solana v1. O app verifica a mensagem retornada antes de pedir que a carteira a assine.
4. **Assinar e enviar.** A carteira assina a própria transação: o segundo prompt, uma assinatura diferente sobre uma string de bytes diferente. O app envia a transação assinada diretamente para um RPC da Solana; o usuário paga a taxa da Solana em SOL a partir da própria carteira.
5. **Confirmar.** A transação é confirmada na Solana; a visão EVM acompanha um instante depois, então o app espera o nonce do endereço sintético avançar antes de enviar a próxima chamada.

**A carteira precisa assinar transações Solana v1.** O caminho falha de forma fechada sem isso: uma carteira que não consegue assinar uma transação v1 interrompe a chamada com um erro, e o app nunca recua para um formato de transação mais antigo. A Solflare assina v1 na devnet hoje; a Phantom ainda não.

### Antes da chamada: dinheiro e a concessão única

Duas coisas podem vir antes de uma chamada no caminho Solana, e cada uma aparece como sua própria etapa com seus próprios prompts:

* **Transferir dinheiro para dentro.** Uma chamada que gasta wUSDC o retira do endereço sintético, que não mantém nada parado. Se o sintético tiver menos do que a chamada precisa, o app primeiro transfere a diferença da própria conta de token USDC da carteira para a do sintético. Esta é uma transação Solana com uma única solicitação, não uma chamada EVM: uma criação idempotente da conta de token do sintético, seguida da instrução activate-token-account do programa Rome, que move os tokens sem executar a EVM. Ela é ignorada quando o sintético já tem o suficiente.
* **A concessão única do wrapper.** wUSDC é o wrapper de um token SPL, e um wrapper move os tokens de um usuário como o delegado SPL desse usuário. Na primeira vez que o endereço sintético de uma carteira gasta wUSDC, a concessão ainda não está em vigor, e o app coloca um **Permitir transferências de wUSDC** passo antes do restante. É uma chamada como qualquer outra (dois prompts), uma vez por carteira. Veja [Concessão única por carteira](/pt-br/conceitos-principais/token-interop.md#one-time-grant-per-wallet).

Uma compra a partir de uma carteira Solana nova é, portanto, uma sequência curta: transferir dinheiro para dentro, permitir transferências de wUSDC, aprovar a vitrine, comprar.

### Chamadas grandes demais para uma única transação

Uma transação atômica Solana tem limites fixos: cerca de 1,4M de unidades de compute, 64 contas e 4 KB no fio (veja [Restrições](/pt-br/conceitos-principais/constraints.md)). O Bloom sempre tenta primeiro a transação direta, assinada pela carteira. Só quando o proxy recusa a chamada porque ela não cabe em uma transação o app a entrega ao proxy para **encaminhar**, e nunca antes:

* **Uma solicitação para essa chamada.** O relay reutiliza a mensagem de autorização que a carteira já assinou para a tentativa recusada, então não há uma segunda solicitação idêntica nem uma transação para assinar. O proxy compõe a chamada, a envia para a Solana (em quantas transações forem necessárias) e paga as taxas da Solana por conta própria.
* **O gas do Rome sai do saldo do sintético.** Uma chamada encaminhada é paga no gas nativo da chain, em wei, a partir do endereço sintético. Se esse saldo for menor do que o custo da chamada, o app primeiro o completa a partir da carteira, em unidades inteiras de 10^12 wei: mais uma solicitação, normalmente uma vez por carteira, como a concessão.
* **O hash é um hash de transação do Rome.** O resultado de uma chamada encaminhada é o hash de transação EVM do proxy, não uma assinatura Solana, então ele não abrirá em um explorer Solana; procure-o no explorer próprio da chain.

O relay se aplica a qualquer chamada que o proxy reporte como grande demais para uma única transação, o que no Credit pode incluir ações de mercado maiores. A maioria das chamadas, incluindo uma transferência simples e uma aprovação, cabe em uma transação e nunca passa por esse caminho. A mecânica das chamadas encaminhadas e seus limites está em [Chamadas retransmitidas e chamadas longas](/pt-br/guias-do-desenvolvedor/call-evm-from-solana.md#relayed-calls-and-long-calls).

### Prompts por etapa

| Etapa                                                                | Prompts da carteira                                               |
| -------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Transferir dinheiro para dentro (somente se estiver em falta)        | 1                                                                 |
| Permitir transferências de wUSDC (uma vez por carteira)              | 2                                                                 |
| Uma chamada que cabe em uma transação (aprovar, comprar, transferir) | 2: a mensagem de autorização, depois a transação                  |
| Uma chamada que precisa ser encaminhada                              | 1, mais 1 para a recarga de gas única se o saldo estiver em falta |

Na página do ativo Invest, uma carteira Solana passa pela entrada de dinheiro, pela concessão, pela aprovação e pela compra em uma única execução após pressionar Comprar, e o botão informa "duas solicitações da carteira" enquanto cada etapa assina. As etapas nomeadas ("Transferindo seu dinheiro") e as contagens de solicitações iniciais são mostradas em Trade e Credit. Uma carteira EVM também recebe uma etapa única *Permitir transferências de wUSDC* no painel de compra.

### Compute medido, do caminho anterior

Antes da mudança para transações v1, o caminho montava sua própria transação e mediu esses números na Rome devnet, intervalos observados em duas chains. Eles não foram medidos novamente na transação v1 que o proxy compõe agora, então leia-os como ordem de grandeza, não como orçamento:

| Fluxo do caminho Solana                                                    | CU            |
| -------------------------------------------------------------------------- | ------------- |
| Transferência de RWA com gate                                              | \~339–381 mil |
| Aprovação de wUSDC                                                         | \~189–191 mil |
| Compra na vitrine (aprovar + comprar, duas transações)                     | \~730–796 mil |
| Varredura da perna de caixa para a própria conta de token da carteira      | \~42–54 mil   |
| Transferência simples de valor                                             | \~47 mil      |
| `TestApprover.approve` — admissão na allowlist, **assinada pela carteira** | 220,794       |

O limite de compute por transação da Solana é 1,4M CU. Meça sua própria chamada a partir de `meta.computeUnitsConsumed` (`getTransaction` em um RPC da Solana; o recibo EVM da chain não tem esse campo) em vez de presumir um destes.

## Custódia: por que o RWA permanece no sintético

A pergunta de design que todo ativo com permissão precisa responder: *o token pode vazar para fora do perímetro de compliance?* No caminho Solana a resposta é estrutural, não de política:

* **O RWA reside no estado da EVM.** Seus saldos são armazenamento dentro das contas do programa EVM do Rome. Não há **nenhum mint SPL** dele, nenhuma representação em conta de token, nada nativo da Solana para mover. (Isso é deliberado — uma versão embrulhada/espelhada seria a escotilha de fuga.)
* **A infraestrutura do lado da Solana não consegue tocá-lo.** As pernas de movimentação de ativos do caminho (`create_ata`, transferências SPL, varreduras) operam em contas de token SPL; os saldos de armazenamento EVM não têm tal conta. Não há instrução que mova um saldo EVM para uma conta de token Solana.
* **Apenas a assinatura Solana do proprietário conduz o sintético**, e cada movimento que ela pode expressar é uma chamada ao contrato do token — que executa o gate da lista de permissões — então uma transferência para um endereço não listado reverte de forma idêntica, seja assinada por uma chave EVM ou por uma chave Solana.
* **A perna de caixa é a exceção deliberada.** wUSDC (rendimento, produto de venda) é lastreado em SPL e *deve* fazer ida e volta: a perna de saída (`transfer_spl`) o move do sintético para a conta de token associada própria da carteira, verificada de ponta a ponta. O ativo permanece no perímetro; o caixa flui livremente.

Duas consequências práticas, ditas claramente: a interface de uma carteira Solana não exibirá a participação em RWA (não há token SPL a listar) — o app Bloom é a superfície de posições; e uma chave Solana perdida é recuperada pelo processo do emissor ([COMPLIANCE.md](/pt-br/apps-na-rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), não movendo o ativo por fora do sistema — que é exatamente a propriedade que um ativo com permissão quer.


---

# 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/apps-na-rome/bloom/lanes.md?ask=<question>&goal=<user_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.