> 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/evidence-investor.md). # Evidência — um investidor Os [Investindo](/pt-br/apps-na-rome/bloom/investing.md) capturas de tela mostram um comprador real, duas vezes — **uma vez de uma carteira EVM e uma vez de uma carteira Solana, comprando o mesmo ativo em Solidity** (Mineral Vault I, `ARCV`) no Hadrian (chain `200010`). Cada ação é uma transação que você pode abrir. O link é a reivindicação. Estes são **execuções históricas**: elas aconteceram na faixa como ela era então, e os links das transações permanecem como estavam. Onde a faixa Solana mudou desde então, a seção sobre ela diz o que a execução foi e aponta para [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md) como a faixa funciona agora. * **Ativo:** [`0x2b13ba16a429bf630f94882e477fe775d34b7c74`](https://via-hadrian.testnet.romeprotocol.xyz/address/0x2b13ba16a429bf630f94882e477fe775d34b7c74) * **Vitrine:** [`0x9326a00dd1cd4f3f1800fc849c3c58715fc5061a`](https://via-hadrian.testnet.romeprotocol.xyz/address/0x9326a00dd1cd4f3f1800fc849c3c58715fc5061a) * **Pago em:** wUSDC [`0xd4cc34b67c805d472b5a709a22a1037f6b16ef28`](https://via-hadrian.testnet.romeprotocol.xyz/address/0xd4cc34b67c805d472b5a709a22a1037f6b16ef28) — o wUSDC que essas execuções usaram. O wUSDC atual da rede é `0xbce339ba4c3a8de3bb8af1c5539e6ac11da3112d`, conforme listado no registro público. ## A faixa EVM — uma carteira compra em seu próprio endereço Uma carteira EVM mantém o ativo em seu próprio endereço, e uma compra é o processo comum de duas etapas aprovar-e-comprar. A verificação de elegibilidade é feita primeiro no token — o comprador está na allowlist, então compra. Comprador: [`0x5667b3700b4a021Cc475157cbf3dE2d756Fae597`](https://via-hadrian.testnet.romeprotocol.xyz/address/0x5667b3700b4a021Cc475157cbf3dE2d756Fae597) | # | O que ele fez | Transação | | - | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Coloque o comprador na allowlist (o substituto de testes para a aprovação do emissor) | [`0xf8180aef…5c29c86d`](https://via-hadrian.testnet.romeprotocol.xyz/tx/0xf8180aef8ba3203750a4ae63eea215c9e5891cd147f7272a359f512c5c29c86d) | | 2 | Aprovar wUSDC para a vitrine | [`0x0f7229ea…7c2669e5`](https://via-hadrian.testnet.romeprotocol.xyz/tx/0x0f7229eab17d8d28907a3bc9239f62367abed528fde09bd7cc0ad10f7c2669e5) | | 3 | Comprar o ativo | [`0xe099d892…3792f6de`](https://via-hadrian.testnet.romeprotocol.xyz/tx/0xe099d8921225563cf0fbf0e4fd1e97037f50bcbebf41f2acea21696f3792f6de) | Depois da compra, o cartão de elegibilidade mostra **Permitido** e a posição aparece em Posições — as `permitido para investir` e `posições` as capturas de tela no guia são este comprador, depois dessas transações. ## A faixa Solana — uma carteira compra em seu endereço derivado Esta é a que sustenta toda a tese: **uma carteira Solana compra o mesmo ativo em Solidity, sem ponte e sem segundo token.** Não há nenhuma chave EVM em lugar nenhum — o comprador assina com sua chave Solana, e o ativo fica mantido no endereço EVM *derivado* a partir dela. * **Assinante Solana:** `55R41dbRU13QhLpAgha1841wR5M6sAcZhXd4S1LGupBn` * **Endereço derivado de custódia:** [`0xd868eec27e47376e739d0a3555f81b7657faa322`](https://via-hadrian.testnet.romeprotocol.xyz/address/0xd868eec27e47376e739d0a3555f81b7657faa322) — `keccak256(pubkey)[12..32]` Nesta execução, cada etapa foi uma transação EVM executada dentro de **uma transação Solana**, autorizada pela assinatura Solana, e o cliente montou essa transação por conta própria. A compra é os mesmos dois passos, cada um sua própria transação Solana: | # | O que ele fez | transação Solana | Cálculo | | - | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | | 1 | Aprovar wUSDC para a vitrine (a partir do endereço derivado) | [`3ohASbQc…3ad5p`](https://explorer.solana.com/tx/3ohASbQcv3L7qPbJfccoZQeN1KX1yPBy4nycdSU6PVWD8DxrpfGgHVymbHHfkLWC5727xE3XJTzf1Fyf5ct3ad5p?cluster=devnet) | \~191K CU | | 2 | Comprar o ativo | [`5CdSWWh3…3UkJ`](https://explorer.solana.com/tx/5CdSWWh3A72jy2M843F3udYjiHr2UUM82FrfxjcNJja8RZrj6AQH7mHCMmZafgMFBUGBCMriXQiS7jM36rQZ3UkJ?cluster=devnet) | \~737K CU | O comprador pagou a taxa da transação em **lamports da própria carteira Solana**; o endereço derivado nunca manteve SOL. Essa parte não mudou. Os `posições-solana` captura de tela no guia — *"Mantido para sua chave Solana"*, a cadeia de custódia e a posição em ARCV — é este assinante, depois dessas transações. > **Como a faixa funciona agora.** Essas duas transações foram montadas pelo cliente e assinadas uma vez cada. Hoje o proxy da rede compõe uma transação Solana v1 para cada chamada, e a carteira assina duas vezes por chamada: uma *Autorização Rome* mensagem, depois a transação. Uma carteira nova também pode ver uma etapa de entrada de fundos e uma etapa única *Permitir transferências de wUSDC* antes da aprovação, e uma chamada grande demais para uma transação é retransmitida. Os links acima são as transações da faixa anterior, não da atual. Veja [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md). > **O mesmo ativo, a mesma allowlist, em qualquer mundo de carteira.** O comprador EVM e o comprador Solana compraram o token Solidity idêntico, restrito pela mesma allowlist on-chain, precificado no mesmo wUSDC. A única diferença é qual chave assinou e qual endereço o mantém — que é justamente o ponto central das duas faixas, comprovado aqui em vez de apenas afirmado. A mecânica está em [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md); o modelo de conformidade está em [COMPLIANCE.md](/pt-br/apps-na-rome/bloom/compliance.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/apps-na-rome/bloom/evidence-investor.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.