> 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/issuing.md).

# Emitindo

Bloom permite que você emita um **ativo do mundo real com permissão** como um contrato Solidity comum em uma chain Rome, e administrá-lo a partir de um console por ativo. O ativo pode ser acessado tanto por carteiras EVM quanto por carteiras Solana, mas **a emissão é somente EVM** — uma carteira Solana mantém ativos; ela não os cria. Este guia aborda o console do emissor, o assistente de criação, a barreira de entrada do console e cada uma das seis abas de administração.

> **Você não entrega documentos nem dados pessoais ao Bloom, e seu investidor também não.** Bloom registra o *resultado* da sua decisão de conformidade; a chain registra um booleano por endereço. Seu processo de KYC/AML — seus fornecedores, seus arquivos, sua retenção — permanece inteiramente no seu próprio sistema. O modelo completo está em [COMPLIANCE.md](/pt-br/apps-na-rome/bloom/compliance.md); este guia aponta para ele em vez de repeti-lo.

***

## O que você pode fazer

Como administrador de um ativo, tudo abaixo é para você fazer pelo console — e cada uma dessas ações é uma transação real na chain, vinculada na [Evidência](/pt-br/apps-na-rome/bloom/evidence.md) página:

* **Emitir um ativo** — o assistente o implanta como três contratos (abaixo).
* **Revisar solicitações** — aprove ou recuse cada uma (uma recusa inclui um motivo devido ao solicitante) e admita um endereço aprovado na allowlist.
* **Gerenciar a allowlist** — adicionar um endereço, adicionar **um lote de endereços em uma única transação** (`batchAddToWhitelist`), ou remover um endereço; o token aplica a lista em toda transferência.
* **Restringir o ativo** — restringir transferências à allowlist (o que torna a oferta final), ou suspender a restrição.
* **Gerenciar a oferta** — ler o total e cunhar ou queimar uma vez que você detenha a função.
* **Operar a venda** — abrir uma venda (unidades e preço), fechá-la, recolher o estoque não vendido e sacar os recursos.
* **Definir e distribuir rendimento** — definir a moeda de pagamento e depois distribuir um pagamento, que percorre os titulares uma transação por vez; os titulares excluídos são ignorados.
* **Gerenciar funções** — conceder uma função a um endereço, revogar uma, ou renunciar à sua própria.

Cada uma é detalhada abaixo, com o que a chain aplica, na aba a que pertence.

***

## O console do emissor

![O console do emissor em /issuer, listando os ativos que esta implantação conhece e o estado de venda deles.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-c94de7c7a94a287a4d9b90a92b2b16022213b702%2Fissuer-console.png?alt=media)

`/issuer` lista os ativos que você emitiu nesta chain e permite iniciar um novo.

* Conecte uma **carteira EVM**. Um visitante desconectado, ou uma carteira Solana, vê um aviso para conectar o tipo certo de carteira em vez de um console vazio — uma carteira Solana não pode emitir, e isso é um limite do produto que a chain aplica como uma segunda proteção independente.
* A tabela lista cada ativo com seu **nome e símbolo**, seu ciclo de vida **fase**, e seu **Venda** estado (um *Abra* selo ou *Fechada*).

Duas colunas — **Titulares** e **Para revisar** — mostram um traço. A contagem de titulares precisa da enumeração da allowlist e a fila de revisão é um armazenamento off-chain no qual você entra por ativo; um traço indica *não solicitado* onde um `0` alegaria um fato que o aplicativo não leu.

Pressione **Emitir um ativo** para abrir o assistente, ou selecione uma linha para abrir o console desse ativo.

***

## Criando um ativo: o assistente

![O assistente de criação em /create: os campos do ativo e, depois, seis cartões que acendem à medida que suas transações são confirmadas.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-94683a3a49ac2418aed8cc66dbf47fad940814f7%2Fcreate-wizard.png?alt=media)

`/create` coleta quatro campos e depois implanta seu ativo.

| Campo              | Regra                             |
| ------------------ | --------------------------------- |
| **Nome**           | Obrigatório.                      |
| **Símbolo**        | Obrigatório.                      |
| **Oferta**         | Um número inteiro maior que zero. |
| **Casas decimais** | Um número inteiro de 0 a 18.      |

Pressione **Iniciar**. Se um campo for inválido, o assistente informa qual e por quê, em vez de ficar atrás de um botão desativado. Quando o rascunho é válido, sua carteira é solicitada a assinar cada etapa em sequência.

### Por que ele é implantado em partes

> **Um token é implantado como três contratos ao longo de várias transações — nunca em uma só.** A implantação em uma única transação do Arc `createToken` precisaria de **77 bloqueios de conta**, e a Rome limita uma única transação a **62 bloqueios**. Então o assistente implanta cada parte em sua própria transação e depois obtém o status de fábrica via `ArcTokenFactoryV2.registerToken`. Esta é uma restrição da Rome tornada visível, não uma otimização opcional — e as proteções preservam exatamente o modelo de segurança upstream do Arc (proxy canônico, implementação na whitelist, o chamador possui a função de administrador do token, o registro é único). Veja [COMPLIANCE.md](/pt-br/apps-na-rome/bloom/compliance.md#what-rome-adds-and-what-registertoken-preserves).

### Os seis cartões

O assistente mostra seis cartões, que acompanham o progresso da implantação. Um cartão muda de **Aguardando** em **Assinando…** em **Concluído** (ou **Falhou**) quando sua transação é confirmada.

| # | Cartão                           | O que faz                                                                                                                              |
| - | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | **Implementação**                | A implementação compartilhada do ativo para esta chain — resolvida, nada a assinar. (Concluído antes de qualquer etapa ser executada.) |
| 2 | **O ativo**                      | Implanta seu ativo e define seu nome, símbolo, oferta e casas decimais em uma única etapa.                                             |
| 3 | **Quem pode detê-lo**            | Implanta o próprio módulo de permissão deste ativo, com você como administrador.                                                       |
| 4 | **Aplique-o nas transferências** | Aponta o ativo para esse módulo, de modo que cada transferência seja verificada pelo próprio ativo.                                    |
| 5 | **Regras de rendimento**         | Implanta e vincula o módulo que decide quem recebe pagamento.                                                                          |
| 6 | **Registro**                     | Registra o ativo — isso é o que abre a venda e permite atualizá-lo depois.                                                             |

Os seis cartões reúnem oito etapas subjacentes de implantação, então uma única **Iniciar** resulta em **oito assinaturas**. Uma nota abaixo do botão diz *"Sua carteira pedirá que você assine cada etapa. Pare a qualquer momento e continue de onde parou — nada se perde."* O registro ser a etapa final é o que torna uma interrupção segura: o ativo é uma implantação real em cada estágio, registrada ao final.

Quando a execução termina, o assistente mostra *"Emitido. Seu ativo está ativo em …"* com um link para o console do ativo em `/token/[address]`.

> **`inicializar` concede a você todas as funções.** O endereço que conduz o assistente — seu endereço EVM — recebe as funções de administrador, emissor/queimador, gerenciador/distribuidor de rendimento e atualizador do token, além da função de administrador do módulo da allowlist. A custódia da sua chave, portanto, faz parte da postura de conformidade do ativo: uma carteira de investidor perdida só pode ser recuperada por meio da sua ação de administrador, e a aba de **Direitos** aba torna visível o detentor de cada poder. (`UPGRADER_ROLE` é *não* concedido automaticamente à fábrica — conceda-o explicitamente se quiser atualizações mediadas pela fábrica.)

***

## O console por ativo e a barreira de entrada de login

![A barreira de login do console: assine uma mensagem com sua carteira — não há senha.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-a9377e3cad8460af1d9bb4eb3cf6f2a6a8f28b22%2Fconsole-signin.png?alt=media)

Ao abrir `/token/[address]` faz **não** mostre o console imediatamente. Ele exibe uma **barreira de login**:

> *"Entre para gerenciar este ativo. Assine uma mensagem com sua carteira — não há senha. Sua autoridade vem do próprio ativo, e ela é verificada novamente em cada ação, então revogá-la entra em vigor imediatamente."*

Pressione **Entrar com sua carteira**. Veja exatamente o que acontece:

1. Sua carteira é solicitada a `personal_sign` uma declaração curta e legível por humanos (encabeçada por *"Bloom — prove que você gerencia este ativo"*) que nomeia a única ação que ele autoriza — ler a fila de solicitações deste ativo — junto com o endereço do ativo, o id da chain e um carimbo de data/hora.
2. O aplicativo envia essa declaração assinada para `GET /api/applications`.
3. Os **servidor** o verifica: ele recupera seu endereço a partir da assinatura, confirma que a declaração é para esta chain e ainda está válida (autoriza por uma janela de dois minutos, não por uma sessão), lê o **módulo de allowlist do próprio token** na chain e verifica se seu endereço possui a função que a escrita na allowlist realmente exige — `MANAGER_ROLE` nesse módulo.
4. Se você a possui, a fila é retornada e o console é renderizado. Se não, o servidor recusa com `403` e um motivo.

![A barreira mostrando uma recusa em aspas: uma carteira que não gerencia este ativo é barrada.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-99040b8d3c752f0f84615b913d6b75fb0d36f81b%2Fconsole-refusal.png?alt=media)

> **O ativo decide quem pode administrá-lo — não este aplicativo.** A função é verificada na allowlist **o módulo**, e não no token, e possuir uma função com o mesmo nome no token não *não* é transferido — são autoridades diferentes. Não há conta nem sessão: cada solicitação subsequente carrega sua própria assinatura recente, que é o que *"verificada novamente em cada ação"* significa. Revogue a função de uma carteira na chain e ela deixa de conseguir entrar imediatamente.

Uma recusa mostra o motivo **entre aspas** — o Bloom nunca escreve uma frase sobre por que uma carteira foi recusada. Se você recusar a assinatura na sua carteira, isso é o seu *"não"*, e não do ativo, e isso não é relatado como uma recusa.

> **A barreira define de quem é o console, não o que é secreto.** Oferta, estado de venda, a lista da allowlist e as funções são leituras públicas da chain que qualquer explorer responderá. O que a assinatura concede é a **fila de solicitações** — as declarações de outras pessoas — e o direito de ver o console em primeiro lugar.

### O cabeçalho do console

Depois de entrar, o cabeçalho nomeia o ativo e mostra sua **fase** — o fato mais consequente que ele tem:

| Fase            | Significado                                                                                                                           |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Rascunho**    | Nenhum módulo de permissão foi vinculado ainda, então nada restringe quem pode deter isto.                                            |
| **Abra**        | As transferências estão abertas e a oferta ainda pode mudar. Restringir o ativo torna sua oferta final, e isso não pode ser desfeito. |
| **Restringido** | Apenas endereços na allowlist podem deter isto, **e sua oferta é final** — não é mais possível cunhar nem queimar, permanentemente.   |

Acima das abas, um resumo mostra quatro números — **Titulares · Para revisar · Vendido · Rendimento pago**. Dois são lidos da chain e do armazenamento (*Para revisar* depois que você entrar; *Vendido* da vitrine); *Titulares* depende da contagem de titulares da prévia de rendimento, e *Rendimento pago* depende do cursor do histórico de pagamentos ainda por vir. Cada célula em espera mostra um traço e explica o que precisa, em vez de um `0` que alegaria um fato que ninguém pediu à chain.

***

## As seis abas

O console tem seis abas, nesta ordem: **Solicitações · Quem pode detê-lo · Oferta · Venda · Rendimento · Direitos.**

Toda gravação nessas abas usa um controle compartilhado que exibe as **pré-condições nomeadas** e suas **consequências** *antes* do botão, e nomeia sua fase enquanto ele é executado (*"Aguardando sua carteira…"*, *"Entrando na chain…"*). Nada deve reverter para ensinar o que poderia ter sido verificado primeiro.

### Solicitações — a fila de revisão

![A aba Solicitações — a fila de revisão, com uma solicitação pendente para aprovar ou recusar, e a interface de conformidade.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-8249de8b76f757101cc945ca4a2687103428839c%2Ftab-applications.png?alt=media)

Esta aba lista quem solicitou deter o ativo. Cada linha mostra o endereço do solicitante, jurisdição, tipo de titular, um **Verificações** coluna (*Aprovado* se seu provedor registrou um resultado, caso contrário *Declarado*), e um **Status** (*Para revisar*, *Aprovado*, *Recusado*). Expanda uma linha para ver seus fatos e dois controles: **Aprovar — pode detê-lo** e **Recusar**. Uma recusa exige um motivo, que se torna a resposta do solicitante.

> **Aprovar são dois atos separados, e a aba os mantém honestos.** Ao pressionar **Aprovar** *registra* sua decisão no armazenamento de solicitações. Colocar o endereço na allowlist do ativo na chain é uma **segunda assinatura** — `batchAddToWhitelist` — e até que ela seja confirmada, a linha informa isso. Quando a decisão registrada e a chain divergem, a aba nomeia a lacuna e oferece a gravação que a fecha: **Admitir** para adicionar um endereço aprovado à allowlist, ou (para um endereço recusado ainda listado) o controle para removê-lo. O endereço não pode deter o ativo até que a gravação na allowlist seja confirmada.

Uma observação fixa nesta aba — a **interface de conformidade** — indica onde o seu próprio processo se encaixa:

> *"Nenhum documento é solicitado ou mantido aqui — as verificações são suas. Conecte seu provedor atrás da `Solicitações` interface, ou importe decisões que você já tomou. O Bloom registra o resultado e a chain registra um sim ou não contra o endereço."*

Essa é a interface que um emissor autogerenciado substitui: troque a implementação do armazenamento de solicitações pela sua própria implementação persistente e nenhum chamador muda. O Bloom não realiza verificações e não retém nenhum documento.

### Quem pode detê-lo — a barreira de transferências

![A aba Quem pode detê-lo — a contagem da allowlist e o controle de restringir transferências, mostrando suas consequências de porta sem retorno.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-d32c410e3b5798d86dc5b914bce2f927eb4b1620%2Ftab-holders.png?alt=media)

Esta aba informa quantos endereços estão na allowlist do ativo e permite alternar se a allowlist está **aplicada**:

* Quando as transferências estão **sem restrição**, ela oferece **restringir transferências à allowlist**. As consequências da gravação indicam que fazer isso torna a oferta final e é uma via sem retorno para não administradores.
* Quando as transferências estão **restritas**, ela oferece **remover uma restrição**. Suas consequências afirmam claramente que isso não é um desfazer.

Em um *sem restrição* (rascunho) ativo sem nenhum módulo de permissão vinculado, a aba diz isso — *"Nenhum módulo de permissão está vinculado, então nada restringe quem pode deter isto"* — e a alternância não é exibida.

> **O token verifica os dois lados de cada transferência.** Enquanto o ativo estiver restrito, uma transferência em que qualquer uma das partes não esteja na allowlist reverte na chain com um erro tipado. A mesma barreira vale para uma transferência de carteira EVM, uma transferência assinada por Solana, uma venda na vitrine e o movimento inicial de liquidez — não há caminho em torno dela, exceto pelos seus próprios poderes de administrador.

### Oferta

![A aba Oferta — unidades totais em existência.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-29eb2d741e5193eef3ea94a214a199f2eb404fe7%2Ftab-supply.png?alt=media)

Esta aba informa a oferta total em existência, em unidades inteiras.

### Venda — abrir, fechar e receber os recursos

![A aba Venda — uma venda aberta, com os controles de fechar a venda, recolher o não vendido e sacar os recursos.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-573a99f9028a984b038162dc885a16b715673293%2Ftab-sale.png?alt=media)

Esta aba executa a venda principal por meio do contrato da vitrine.

* **Quando nenhuma venda está aberta**, ela oferece abrir uma: informe **Unidades para vender** e **Preço por unidade** (em `wUSDC`), então pressione **Abra a venda**. As pré-condições da gravação são mostradas primeiro — o token deve estar registrado, a vitrine deve deter o inventário da venda, e a própria vitrine deve estar na allowlist do token que vende — então uma venda que ainda não pode ser aberta diz exatamente o que precisa.
* **Quando uma venda está aberta**, ela mostra quantas unidades restam da oferta e oferece **Fechar esta venda**.
* **Recolher unidades não vendidas** move o estoque não vendido da vitrine de volta para um destinatário (por padrão, você). Isso é **não** um fechamento — a venda permanece habilitada, e a consequência da gravação diz isso, então uma recolha não pode ser confundida com um desfazimento.
* **Sacar recursos** envia o montante da vitrine para um endereço (por padrão, você). Os recursos acumulam independentemente do estado da venda, então podem ser sacados tanto com a venda aberta quanto fechada.

### Rendimento — pagar titulares, um por transação

![A aba Rendimento — o campo de valor da distribuição, com o lembrete de definir primeiro uma moeda de pagamento.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-cc8150ea6fee72d99bd5a2254073779cbd896c11%2Ftab-yield.png?alt=media)

Esta aba distribui um pagamento de rendimento aos titulares.

> **Uma distribuição é uma caminhada, não um clique.** Na Rome, `distributeYieldWithLimit` paga **um titular por transação** (o limite de conta), então um pagamento é uma sequência de janelas, cada uma com sua própria assinatura. Você informa o valor uma vez, em unidades inteiras da moeda de pagamento, e ele fica travado assim que a caminhada começa. A **primeiro** janela retira de você o pagamento inteiro e paga o primeiro titular; cada janela seguinte move apenas dinheiro já dentro do contrato do token. O Bloom relê o cursor da chain após cada janela — o conjunto de titulares é reordenado conforme os saldos mudam, e enviar um índice desatualizado reiniciaria do zero e retiraria seu dinheiro uma segunda vez.

A aba mostra o progresso — *"Pagando o titular N de M"* — e termina quando o cursor dá a volta. Se o ativo não tiver uma moeda de pagamento definida, a aba informa isso; definir a moeda de pagamento é o único campo de uma distribuição que só você pode escolher.

> **As partes dos titulares restritos permanecem no contrato.** Um endereço excluído pelo módulo de lista negra de rendimento é ignorado, e sua parte proporcional permanece no contrato do token em vez de ser paga.

Pagamentos anteriores ainda não são mostrados — lê-los percorre os eventos de distribuição de volta até o primeiro bloco do ativo, o que precisa de um cursor de histórico ainda por vir. A aba diz isso por si só em vez de mostrar um `0`.

### Direitos — as funções

![A aba Direitos — cada função e se ela é detida, e o controle de conceder / revogar / renunciar.](https://735130481-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-fb54f6c73c2d194dd5b6321bc3cb0af825f6f637%2Ftab-rights.png?alt=media)

Esta aba lista cada função que o token declara e se ela é detida, cada uma lida com uma única `hasRole` chamada ao token. Uma função que está **não** detida aparece como tal em vez de ser omitida — em uma aba de direitos, uma linha ausente e uma *"não"* são fatos diferentes.

Abaixo da lista, um controle altera as funções:

| Ação                        | Aplica-se a                                                                  | Autoridade           |
| --------------------------- | ---------------------------------------------------------------------------- | -------------------- |
| **Conceder a uma conta**    | Um endereço que você informar                                                | `DEFAULT_ADMIN_ROLE` |
| **Revogar de uma conta**    | Um endereço que você informar                                                | `DEFAULT_ADMIN_ROLE` |
| **Renunciar à sua própria** | Você mesmo (o OpenZeppelin exige que a confirmação seja feita pelo chamador) | Você                 |

As opções de funções são as do próprio token, então o controle nunca pode oferecer uma função que o token não tenha. Como em toda gravação, a linha de autoridade e a consequência são exibidas antes do botão, então a porta e seu caráter de mão única são declarados antes de você assinar.

***

## O que nunca toca o Bloom nem a chain

Para não haver ambiguidade sobre onde a conformidade vive:

| Item                               | Onde fica                                                                                             |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Documentos de KYC/AML e PII        | Seu próprio sistema, com seus próprios fornecedores e retenção — **nunca** este aplicativo ou a chain |
| Sua decisão de admitir um endereço | Um registro off-chain; você é dono do armazenamento                                                   |
| O efeito on-chain dessa decisão    | Um booleano — `isWhitelisted(address)` — escrito por `batchAddToWhitelist`                            |
| Aplicação da regra                 | O contrato do ativo, em cada transferência                                                            |
| Quem pode administrar o ativo      | A função detida no módulo de allowlist do ativo, verificada em cada solicitação                       |

Para o modelo de conformidade completo, leia [COMPLIANCE.md](/pt-br/apps-na-rome/bloom/compliance.md); para a mecânica de duas vias (EVM e Solana) que seus titulares usam, leia [LANES.md](/pt-br/apps-na-rome/bloom/lanes.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/issuing.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.