> 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/investing.md). # Investindo Bloom é um marketplace para **ativos do mundo real permissionados**. Cada ativo é um contrato Solidity comum implantado uma vez em uma chain Rome, e a regra de quem pode mantê-lo vive dentro desse contrato. Este guia leva um comprador da página inicial pela navegação de um ativo, verificação de elegibilidade, solicitação para a allowlist, compra e posse — e então cobre a única coisa que é genuinamente diferente para um detentor que assina com uma carteira Solana. > **A regra viaja com o ativo.** Quem pode manter um ativo é imposto pelo próprio contrato do ativo, em toda transferência — não por este site. Nada em nenhuma tela aqui pode substituí-lo, e não há caminho para contorná-lo. Bloom é uma janela para a chain; a chain é quem decide. *** ## O que "com permissão" significa para um comprador Um ativo com permissão tem uma **allowlist**: um conjunto de endereços que o emissor decidiu que pode mantê-lo. A allowlist não é um recurso da Bloom — ela fica em um módulo conectado ao contrato do ativo, e o ativo a consulta em toda mintagem, queima e transferência. > **A chain guarda um fato sobre você: um único sim ou não para o seu endereço.** Nenhum documento, nenhuma informação pessoal e nenhuma declaração de identidade são armazenados na chain ou neste app. Quando um emissor aceita você, tudo o que chega à chain é `isWhitelisted(seuEndereco) = true`. O modelo completo de conformidade está em [COMPLIANCE.md](/pt-br/apps-na-rome/bloom/compliance.md). Duas consequências decorrem disso, e ambas são visíveis no produto: * Antes de você poder comprar, o ativo é perguntado se **seu endereço** pode mantê-lo. Uma recusa é um fato sobre a regra do ativo, não um problema com sua carteira. * Uma transferência para um endereço que o emissor não aprovou **reverte na chain**. O ativo a recusa; nenhuma tela precisa fazê-lo. *** ## Os dois mundos de carteira Um único ativo da Bloom pode ser acessado por **ambos** uma carteira EVM (como MetaMask) e uma carteira Solana (como Solflare). Você conecta uma carteira por vez. Uma carteira Solana precisa conseguir assinar transações Solana versão 1: Solflare faz isso no devnet hoje, e a Phantom ainda não. | Carteira | Onde ele mantém o ativo | O que assina | | ----------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Carteira EVM** | Seu próprio endereço EVM, como em qualquer chain EVM | Uma transação EVM | | **wallet Solana** | Um endereço EVM **derivado da sua chave pública Solana** | Sua assinatura Solana, solicitada duas vezes por etapa (veja [Pagando e as solicitações extras de assinatura](#paying-and-the-extra-signature-prompts)) | Para uma carteira EVM, não há nada novo a aprender. Para uma carteira Solana, o ativo fica em um *derivado* endereço — calculado como `keccak256(solana_pubkey)[12..32]` — e somente sua assinatura Solana pode operá-lo. Não há **nenhuma ponte, nenhum segundo token e nenhuma conta EVM** envolvidos. Isso é explicado em detalhes em [a seção do detentor Solana](#for-a-solana-holder) abaixo e em [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md). *** ## A página inicial ![A página inicial da Bloom: o título, as duas linhas de mundos de carteira e as portas de Investidor e Emissor.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-d24cbcc96b6ec85d6a62caa993ccd38d3aff82fc%2Flanding.png?alt=media) A página inicial (`/`) diz o que é a Bloom — *ativos Solidity, abertos tanto para Solana quanto para EVM* — e oferece duas portas: **Investidor** (que leva você aos ativos abertos em `/invest`e **Emissor**. Como comprador, escolha **Investidor**. Duas linhas, **carteiras Solana** e **carteiras EVM**, listam as carteiras que o seu navegador realmente anunciou pelos protocolos de descoberta EIP-6963 e Wallet Standard. Nada é mostrado se você não tiver instalado; o nome e o ícone de cada carteira são próprios. No rodapé, uma **Contratos** seção lista os endereços com os quais esta implantação conversa — a factory de tokens, a implementação compartilhada, o roteador de permissões, a loja de venda primária e o token de caixa — cada um com link para o explorador de blocos, de modo que o app nunca afirma um endereço com a própria voz. ### "Como isso é possível com Solana?" ![A explicação da custódia: uma assinatura entra à esquerda e o ativo a aceita à direita, sem ponte entre as duas.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-18d251b822b78890123e6049df399d603523af5d%2Fcustody.png?alt=media) A página inicial traz uma explicação que responde como uma carteira Solana pode manter um ativo Solidity. Ela deixa três pontos claros: * **Uma implantação.** O ativo é um contrato Solidity comum, implantado uma vez. Não há uma cópia ponte dele em lugar nenhum — uma segunda cópia é exatamente o que permitiria que ele escapasse das regras. * **Dois mundos de carteira.** Uma carteira EVM alcança o contrato do mesmo modo que alcança qualquer chain. Uma carteira Solana alcança o *mesma* contrato porque uma chain Rome roda dentro da Solana: o ativo é mantido em um endereço EVM derivado da sua chave Solana, e sua assinatura é a única coisa que pode operá-lo. * **O ativo guarda a regra.** Quem pode mantê-lo é imposto pelo contrato em toda transferência — não por este site e não por uma ponte. Um endereço que o emissor não aprovou simplesmente não pode recebê-lo. *** ## Navegando pelos ativos abertos ![A lista de ativos abertos em /invest, com preço e estoque lidos ao vivo da chain.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-18422483cf862d7243349361c7dcbd4d9c6b436b%2Finvest-list.png?alt=media) `/invest` lista todos os ativos com uma venda aberta no momento. Em cada linha, você vê: | Coluna | Significado | | ----------- | ------------------------------------------------------------------- | | **Ativo** | O nome e o símbolo do ativo, lidos diretamente do próprio token | | **Preço** | O preço de uma unidade, em `wUSDC` | | **Vendido** | Unidades vendidas de unidades ofertadas, com uma barra de progresso | O resumo acima da tabela conta **Abertos agora** (quantas vendas estão ativas), **Emitidos aqui** (quantos ativos esta chain emitiu) e **Pagos em** (`wUSDC`, o token de caixa de cada venda nesta implantação). > **Nada nesta página é fixo.** Preço, estoque e status são lidos ao vivo da chain a cada visita. Se a chain não responder, a página informa isso — *"A chain não respondeu…"* — em vez de mostrar um número desatualizado ou afirmar que não há nada. *"Nada está à venda no momento"* é uma afirmação sobre a chain, e só aparece quando a chain realmente retorna uma lista vazia. Você pode ler preços e estoque sem conectar. Para comprar, você precisará de uma carteira: a página mostra um **Conectar carteira** solicitação, oferecendo suas carteiras EVM e Solana sob dois títulos. Selecionar uma linha abre a página de detalhes desse ativo. *** ## Um ativo ![Uma página de detalhes do ativo: os fatos à esquerda, o cartão de elegibilidade e o painel de compra à direita.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-341ebd012e46da597a5832fe6ba39af8704be545%2Fasset-detail.png?alt=media) Uma página do ativo (`/invest/[address]`) tem duas metades: os fatos e regras do ativo à esquerda e sua elegibilidade e o painel de compra à direita. ### Os fatos | Fato | Significado | | ---------------------- | ---------------------------------------------------------- | | **Preço** | Preço de uma unidade, em `wUSDC` | | **Disponível** | Unidades ainda disponíveis na venda aberta | | **Rendimento pago em** | A moeda em que qualquer rendimento é distribuído (`wUSDC`) | ### Quem pode mantê-lo A página declara três regras que o ativo impõe: | Regra | O que diz | | ------------------------- | ------------------------------------------------------------------------------- | | **Detentores permitidos** | Endereços aprovados pelo emissor. Verificados pelo ativo em toda transferência. | | **Mínimo** | 1 unidade. Sem lock-up. | | **Transferências** | Somente para outro endereço permitido, de qualquer dos mundos de carteira. | > **O próprio ativo verifica isso em toda transferência. Nada nesta página pode substituí-lo.** As regras são apresentadas como fatos sobre o token, e não como política deste app, porque é isso que elas são. *** ## Elegibilidade — verificada no token, antes de qualquer compra ![O cartão de elegibilidade sendo resolvido na página do ativo: conectar, depois verificando, depois permitido ou não permitido.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-2280eee77f97ef3f1334451fb95811391fedf519%2Feligibility.png?alt=media) Antes de oferecer uma compra, a página do ativo pergunta ao próprio módulo de allowlist do ativo se **seu endereço** pode mantê-lo. O cartão de elegibilidade mostra um destes estados: | Estado | Significado | | ----------------------------- | ------------------------------------------------------------------------------- | | **Conecte-se para verificar** | Nenhuma carteira está conectada ainda. Conecte uma para executar a verificação. | | **Verificando…** | Conectado; a verificação on-chain ainda não foi resolvida. | | **Permitido** | Seu endereço pode manter este ativo. | | **Não permitido** | A regra do ativo recusa seu endereço. Um link oferece solicitar a allowlist. | | **Indisponível** | A verificação não pôde ser lida no momento (não é uma recusa). | > **A verificação é bilateral.** Uma compra move unidades *da loja para você*, então ambas as partes dessa transferência precisam estar na allowlist. Bloom faz a pergunta dessa forma — uma verificação unilateral diria que você é elegível e então veria a compra reverter porque a loja não está listada nesse token. Assim que seu endereço estiver na allowlist, o mesmo cartão mostra **Permitido**, e a compra fica disponível para você: ![O cartão de elegibilidade mostra Permitido — o comprador está na allowlist, e o painel de compra está ativo.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-46bb4f6d6d75bd6d0674c3fdbece1d8acd70f5b5%2Finvest-permitted.png?alt=media) Quando você é recusado, o motivo exibido é **do próprio token**, citado literalmente. Bloom nunca escreve uma frase sobre por que você foi recusado. Se o ativo ainda não tiver um módulo de allowlist vinculado (um rascunho), ele fica *sem restrição* — nada está restringindo ninguém, e você tem permissão. Se você for recusado, o cartão linka para **Solicitar inclusão na allowlist**. *** ## Solicitando inclusão na allowlist ![O formulário de solicitação: um endereço, uma jurisdição, um tipo de titular e duas declarações — sem documentos.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-cd846bf05c44424259e0308af395f1cb3acd16ae%2Fapply.png?alt=media) `/apply` é onde você pede a um emissor que admita seu endereço. A introdução diz tudo: **Sem documentos. Apenas declarações.** > **O formulário não contém nada que valha vazar e não escreve nada em nenhuma chain.** Uma solicitação é um registro off-chain sobre o qual o emissor decide. O emissor executa suas próprias verificações em seu próprio sistema; a gravação na allowlist acontece do lado dele, e tudo o que chega à chain é o resultado de sim ou não para o seu endereço. Você fornece quatro coisas e nenhuma quinta: | Campo | Observações | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **O endereço que o manterá** | Preenchido automaticamente pela sua carteira conectada. Para uma carteira Solana, este é o seu **derivado** endereço — o endereço onde o ativo fica, não a chave que assina por ele. | | **Jurisdição** | Uma de uma lista fixa (Singapura, Emirados Árabes Unidos, Suíça, Reino Unido). | | **Você é** | Pessoa física, Pessoa física qualificada, ou Instituição. | | **Duas declarações** | Ambas devem ser aceitas: que você age por conta própria e controla o endereço, e que aceita que o emissor decide quem pode manter o ativo e pode revogá-lo. | Os `?` ao lado da introdução explica por que nenhum documento é solicitado: o emissor precisa apenas do que vai usar, nada que você pudesse enviar poderia ser armazenado aqui, e na chain o registro é um único sim ou não. **Para solicitar:** 1. Confirme o endereço, escolha sua jurisdição e tipo de titular e aceite ambas as declarações. 2. Pressione **Enviar solicitação**. O formulário valida localmente e o store reavalia tudo no servidor, já que um formulário pode ser contornado com uma única requisição. 3. Você recebe um **link privado** do tipo `.../apply/status?ref=AP-XXXX-XXXX-XXXX`. > **Salve o link — ele é a única forma de voltar à sua solicitação.** A referência é gerada a partir de 60 bits de aleatoriedade criptográfica e *é* a autorização: nada mais fica à frente das suas declarações, e não há conta nem senha para recuperá-las. Na demonstração, um **Ligação de teste** aponta você para `/approve`, onde você pode aprovar sua própria solicitação para completar o ciclo. Um emissor real faz essa etapa em seu próprio sistema — [veja abaixo](#approve-the-test-wiring-stand-in). *** ## O status da sua solicitação e como apagar as declarações ![A página de status — a referência, os fatos declarados, a linha do tempo e o controle de apagar.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-7dd1d7befa9f2e2450d783835f3d6c172bab4650%2Fapply-status.png?alt=media) `/apply/status` lê uma solicitação a partir da sua referência (do `?ref=` link, ou do último que este navegador lembra). Não há sessão; a referência é a chave. A página mostra em que ponto você está — **Com o emissor**, **Você pode manter este ativo**, ou **Recusado** — junto com uma tabela de detalhes (referência, data da solicitação, o endereço, o ativo, jurisdição e uma **Verificações** linha) e uma breve linha do tempo do que aconteceu. Se você tiver sido aprovado, um **Comprar o ativo** link aparece. Uma recusa mostra o motivo do próprio emissor, citado. Os **Verificações** linha reflete o próprio registro KYC do emissor. Nesta demonstração não há provedor integrado, então ela mostra *"Apenas declarações — nenhum documento foi solicitado"* em vez de sugerir uma verificação que não aconteceu. ### Apagando o que você declarou Você pode apagar suas declarações a qualquer momento, nesta página. > **Apagar destrói as declarações e mantém a decisão.** O que você disse sobre si mesmo é apagado e não pode ser recuperado. A decisão do emissor permanece, porque já foi executada publicamente, em uma chain — e desfazer isso é uma assinatura que o emissor precisa fazer, não um delete que você possa fazer. (O próprio registro KYC do emissor, se houver, também sobrevive, porque é a evidência do emissor para admitir um endereço que agora está em uma chain pública; apagá-lo aqui também não apagaria nada no provedor deles.) *** ## `/approve` — o substituto da ligação de teste ![A página de aprovação — o banner "ligação de teste, não o emissor", o endereço, a ação de aprovar e seus requisitos on-chain logo abaixo.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-148d3d28590c1cf33f8ca7f3be7a980d739de48f%2Fapprove.png?alt=media) `/approve` existe para que toda a jornada possa ser percorrida do início ao fim na demonstração. Ela traz um banner com o texto **"Ligação de teste — não o emissor"**, e esse banner é o motivo de ser honesto tê-la: em produção o emissor aprova solicitações dentro do próprio fluxo de trabalho, não aqui. **O que é real nela:** a aprovação é uma gravação genuína na allowlist on-chain. A página chama um `TestApprover` contrato que está *armado no ativo de demonstração* (Mineral Vault I, `ARCV`, em `0x2b13ba16a429bf630f94882e477fe775d34b7c74`). Esse contrato precisa de **nenhum papel** de quem o chama — qualquer pessoa pode aprovar qualquer endereço por meio dele — que é justamente o motivo de ele existir: ele permite fechar o ciclo da demonstração para qualquer carteira, de qualquer dos lados. **Para aprovar seu próprio endereço:** 1. Conecte a carteira com a qual você solicitou (EVM ou Solana). Seu endereço é preenchido automaticamente. 2. Pressione **Aprovar este endereço**. As precondições e consequências da gravação aparecem abaixo do botão — abra *"O que isso faz"* para ver exatamente o que acontecerá antes de assinar. 3. Em caso de sucesso, a página mostra *"Aprovado. O solicitante agora pode manter o ativo."* Se você entrou com uma carteira Solana, uma nota diz *"Isso aprovará o endereço derivado da sua chave Solana"* — o endereço que a execução assina **por** é o derivado; a chave que ela assina **com** é a sua chave Solana. > **Em produção, essa é a decisão do emissor, tomada no sistema do emissor.** Da demonstração `TestApprover` é aberto por construção para que o ciclo seja percorrível; uma gravação real na allowlist é restrita por um papel que o emissor possui. Nada no modelo de conformidade muda — continua sendo decisão do emissor, continua sendo um único booleano on-chain e continua sem documentos em lugar nenhum. Depois de aprovado, volte à página do ativo; sua elegibilidade agora mostra **Permitido**. *** ## Comprando O painel de compra fica abaixo do cartão de elegibilidade na página do ativo. > **Precisa de wUSDC primeiro?** Toda venda é precificada em wUSDC, e uma carteira nova não tem nenhum. [Levando fundos para a Rome](/pt-br/apps-na-rome/bloom/funding.md) mostra a entrada de caixa: faça a ponte de USDC ou ETH a partir da Sepolia e depois embrulhe o gás ponteado em wUSDC — tudo na `/bridge` tela. ![O painel de compra após a conclusão de uma compra — "Comprado. Ele aparecerá em Posições."](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-e2ffc015b988fb56be5cf364aa05ac431a0cb5a2%2Fbuy-done.png?alt=media) 1. Digite o número de **Unidades** que você quer. O painel mostra o preço unitário e o total que você pagará, em `wUSDC`. (O caixa que a compra realmente retira é calculado com base no preço em unidades base, então o valor aprovado sempre corresponde ao valor cotado.) 2. Pressione o controle de compra. Uma compra é uma sequência curta, não um único clique: se a venda ainda não tiver permissão para retirar seu `wUSDC`, uma **aprovação** aparece primeiro (*"Permitir que a venda retire seu dinheiro"*), depois a **Comprar** propriamente dita. 3. Cada etapa vem com seu botão e recolhe suas **precondições** e **consequências** abaixo dele — a um clique de distância antes de você assinar — e nomeia sua fase enquanto roda — *"Aguardando sua carteira…"*, depois *"Chegando à chain…"*. A sequência verifica as condições novamente entre as etapas, então uma venda que se encerra depois da sua aprovação interrompe a compra em vez de revertê-la. 4. Em caso de sucesso, o painel mostra *"Comprado. Ele aparecerá em Posições."* A partir de uma **wallet Solana** a sequência pode ser mais longa na primeira vez. Se o seu endereço do lado Rome tiver menos wUSDC do que a compra precisa, uma etapa para trazer caixa da sua carteira vem primeiro, e se a concessão de transferência de wUSDC ainda não estiver em vigor, uma **Permitir transferências de wUSDC** etapa vem antes da aprovação. Depois que você pressiona Comprar, a carteira Solana executa a entrada de caixa, a concessão, a aprovação e a compra de uma vez, e o botão indica "dois prompts de carteira" enquanto cada etapa assina. Os nomes das etapas e a contagem de prompts na frente são mostrados em Trade e Credit, não aqui. Uma carteira EVM também recebe a etapa única **Permitir transferências de wUSDC** neste painel. As etapas e a contagem de prompts estão em [Pagando e as solicitações extras de assinatura](#paying-and-the-extra-signature-prompts). Se sua carteira estiver na rede errada, o painel avisa isso e oferece trocar para a chain do ativo em vez de deixar um botão não fazer nada. > **A compra passa pela mesma verificação de allowlist que qualquer transferência.** A loja só move unidades para você se tanto ela quanto o seu endereço estiverem permitidos. Não há verificação do lado da Bloom que possa substituir a do próprio ativo. *** ## Suas posições `/portfolio` mostra o que você possui. Conecte a carteira que mantém o ativo e você obtém: ![A página de posições — a posse, seu valor e o resumo.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-adabd845843de879d366f0d21b03dfb87fc0573d%2Fpositions.png?alt=media) * um resumo — **Valor total** (em `wUSDC`), **Ativos** (quantos ativos distintos você possui), e **Rendimento recebido**; * um **Posições** tabela listando cada ativo, suas unidades e seu valor. Tudo é lido ao vivo da chain. Quando você ainda não possui nada, a página informa isso e leva você às vendas abertas. **Rendimento recebido** no momento mostra um traço: ler seu histórico de pagamentos significa percorrer os eventos de distribuição de volta até o primeiro bloco do ativo, o que ainda é trabalho futuro — um traço é honesto onde um `0.00` seria uma afirmação. > **Posições são uma visão, não um mercado.** A Bloom expõe a compra de um ativo da sua venda primária e a manutenção dele. O próprio ativo permite transferências para *outros endereços permitidos* de qualquer dos mundos de carteira (essa é uma de suas regras declaradas), mas a Bloom não expõe atualmente uma transferência secundária nem um controle de venda. *** ## Para um detentor Solana Tudo acima se aplica a você sem mudanças. Esta seção cobre a única surpresa que é genuinamente sua: **o ativo é mantido em um endereço que sua carteira Solana nunca listará**, e por que isso é seguro. ### A cadeia de custódia ![As posições do detentor Solana — "Mantido para sua chave Solana", o endereço de custódia derivado, a cadeia de custódia e a posição ARCV comprada pela via Solana.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-b4f6ea043299e63183ceb7393e25b83948975218%2Fpositions-solana.png?alt=media) Quando você conecta uma carteira Solana, `/portfolio` mostra uma **Mantido em** linha com o endereço EVM onde seu ativo fica, e um **Como isso é mantido?** botão alternador que abre um painel de custódia explicando a derivação em três etapas: 1. **Sua chave Solana** — a chave que já está na sua carteira. Ela assina; nunca sai. 2. **Resulta em — o endereço que mantém o ativo** — o endereço EVM derivado. Ele é *aritmética, não uma conta*: ele deriva da sua chave, e não existe chave privada para ele. 3. **O que pode movê-lo** — somente uma assinatura da sua chave pode mover o que estiver nesse endereço. > **Por que isso é seguro.** O ativo é residente no estado da EVM: seu saldo fica armazenado nas contas do programa Rome. Existe **nenhuma emissão SPL dele**, nenhuma conta de token e nada nativo da Solana para mover — então a infraestrutura do lado da Solana não tem nenhuma instrução que possa removê-lo. Somente sua assinatura Solana pode acionar o endereço derivado, e todo movimento que ela pode expressar é uma chamada ao contrato do ativo, que aplica a barreira da lista de permissões. Uma transferência para um endereço não permitido reverte da mesma forma, quer seja assinada por uma chave EVM, quer por uma chave Solana. Essa é exatamente a propriedade que um ativo com permissão quer — veja [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md#custody-why-the-rwa-stays-at-the-synthetic). Como não há um token SPL para listar, **sua carteira Solana não exibirá a participação em RWA** — o app Bloom é sua interface de posições. Uma chave Solana perdida é recuperada pelo processo do emissor, não movendo o ativo por fora do sistema. ### Pagando e as solicitações extras de assinatura * **Você paga a taxa da Solana em SOL da sua própria carteira.** O endereço EVM derivado nunca precisa de SOL. Seu gas só é consumido no único caso descrito abaixo, uma chamada grande demais para uma única transação. * **Toda chamada é uma transação da versão 1 da Solana, e toda chamada exige duas confirmações.** Uma aprovação, uma compra ou uma transferência é composta para sua carteira pelo proxy da cadeia. Sua carteira primeiro assina uma mensagem legível que começa *Autorização Rome*, o que prova que sua chave Solana autoriza esta chamada exata. Em seguida, ela assina a própria transação. Aprovar e depois comprar exige, portanto, quatro confirmações. * **Uma carteira que não consegue assinar transações da versão 1 para por aí.** Bloom falha de forma fechada em vez de enviar um formato mais antigo. Use Solflare na devnet por enquanto; a Phantom ainda não assina transações da versão 1. * **Trazer fundos para dentro é uma confirmação, só quando necessário.** Uma compra gasta wUSDC do seu endereço derivado, que não mantém saldo parado. Se ele tiver menos do que a compra custa, Bloom primeiro transfere a diferença da sua própria conta de token USDC da carteira. No Trade e no Credit, essa etapa se chama *Transferindo seu dinheiro*; na compra do Invest, ela ocorre como parte da compra depois que você pressiona Comprar. * **A concessão única é uma etapa própria, uma vez por carteira.** Na primeira vez que seu endereço derivado gasta wUSDC, Bloom coloca **Permitir transferências de wUSDC** antes da aprovação. É uma chamada como qualquer outra (duas confirmações), e não é solicitada novamente depois que está em vigor. O motivo de existir está em [Concessão única por carteira](/pt-br/conceitos-principais/token-interop.md#one-time-grant-per-wallet). * **Uma chamada grande demais para uma única transação da Solana é retransmitida, com menos confirmações.** Bloom sempre tenta primeiro a transação direta, assinada pela carteira. Se a cadeia a recusar porque ela não cabe, a mesma assinatura de autorização é passada ao proxy, que a submete por você: uma confirmação para essa chamada. Como o proxy a submete, a chamada é paga em gas Rome a partir do seu endereço derivado; então, se esse saldo estiver baixo, Bloom primeiro o completa a partir da sua carteira, o que é mais uma confirmação, normalmente uma vez por carteira. Veja [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md#calls-too-large-for-one-transaction). Uma primeira compra a partir de uma carteira Solana nova é, portanto: trazer fundos para dentro (1 confirmação), permitir transferências de wUSDC (2), aprovar a venda (2), comprar (2). > **Ações maiores são retransmitidas, não recusadas.** Uma compra cabe em uma transação da Solana, e uma "jornada em várias etapas" (aprovar, depois comprar) são várias transações completas, cada uma atômica por si só. Apenas uma chamada que o proxy informa como grande demais para uma transação, o que no Credit pode incluir as ações de mercado maiores, segue a rota de retransmissão descrita acima. *** ## Onde a conformidade realmente está Para resumir o que é aplicado em cada lugar, para que nada aqui seja confundido com uma política da Bloom: | Preocupação | Aplicado por | Não por | | ----------------------------------------------- | --------------------------------------------------------------- | ------------------------------------ | | Quem pode manter o ativo | O módulo de lista de permissões do ativo, em toda transferência | Este site | | Uma transferência para um endereço não aprovado | Revertida on-chain pelo ativo | Qualquer filtro fora da cadeia | | O que é armazenado sobre você | Um booleano (`isWhitelisted`) por endereço | Documentos ou PII, em qualquer lugar | | Quem pode admitir você | A decisão fora da cadeia do emissor | Bloom | Para o modelo completo, leia [COMPLIANCE.md](/pt-br/apps-na-rome/bloom/compliance.md); para a mecânica de duas vias, [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md). > **Isto não é um mockup.** Um comprador real comprou este ativo de uma carteira EVM, e uma carteira Solana real o comprou na faixa Solana — o mesmo token, a mesma lista de permissões, o mesmo wUSDC. Cada transação está vinculada na [Evidência](/pt-br/apps-na-rome/bloom/evidence-investor.md) página. O cartão Permitted, as posições e a cadeia de custódia Solana neste guia são desses compradores, depois dessas transações. --- # 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/investing.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.