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

# Modelo de conformidade

A Bloom executa a estrutura Arc da Plume sem modificações. A conformidade é **imposta pelo próprio contrato do token** — e não por qualquer triagem fora da cadeia, filtro do sequenciador ou política da plataforma. Essa é a propriedade que o torna portável: as regras viajam com o token para qualquer caminho de execução, em ambas as vias da carteira.

## Arquitetura de aplicação das regras

```
ArcToken._update (cada transferência/mint/burn)
   └─ RestrictionsRouter (um por cadeia, registro de tipos de módulo)
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions (por token)
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions (por token)
        └─ GLOBAL_SANCTIONS     → (o slot existe; nenhum módulo global foi implantado)
```

* **WhitelistRestrictions** — a lista de permissões. Enquanto `transfersAllowed` é falso (modo restrito), uma transferência em que qualquer uma das partes não esteja na lista reverte com o erro tipado `TransferRestricted()` (`0xe827105e`). A verificação é executada dentro do token em cada movimentação de saldo — uma transferência de carteira EVM, uma transferência assinada por Solana, uma venda na vitrine e a movimentação inicial de liquidez passam todas pelo mesmo bloqueio. Não há como contorná-lo, exceto pelos próprios poderes administrativos do emissor.
* **YieldBlacklistRestrictions** — exclui endereços das distribuições de rendimento; sua parcela proporcional permanece no contrato do token.
* **GLOBAL\_SANCTIONS** — o roteador oferece suporte a módulos em toda a cadeia aplicados a todos os tokens (por exemplo, uma lista de sanções). Nenhum está implantado hoje; o slot é o local natural para um operado no nível da cadeia.

## O modelo de confiança, dito com honestidade

**A sinalização de lista de permissões é a decisão fora da cadeia do emissor.** KYC/AML acontece no processo do emissor (seus fornecedores, suas regras); a cadeia registra e aplica o *resultado* — `isWhitelisted(addr)`. [Integração e revisão](/pt-br/apps-na-rome/bloom.md) é o mecanismo em torno dessa decisão — como um investidor se candidata, como o emissor decide e o rastro de auditoria que isso deixa — e isso não altera este modelo: ainda é uma decisão do emissor, ainda é apenas um booleano on-chain e não há documentos em lugar nenhum. Este é o próprio modelo da estrutura Arc, como usado na Plume. Ele é deliberadamente *não* um sistema de identidade on-chain: não há declarações de identidade, nem atestações on-chain, nem prova criptográfica de a quem pertence um endereço. Padrões que carregam identidade on-chain verificável (por exemplo, ERC-3643) trocam transferências significativamente mais pesadas por essa propriedade; Arc troca mecanismos mais leves por confiança mantida pelo emissor. A Bloom expõe isso com honestidade, em vez de sugerir mais do que existe.

## Poderes do emissor (com formato de agente de transferência)

`ArcToken.initialize` concede ao driver do assistente todas as funções:

| Função                                               | Poder                                                                                                           |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| `ADMIN_ROLE` / `DEFAULT_ADMIN_ROLE`                  | vincular/substituir módulos de restrição, gerenciar funções                                                     |
| `MINTER_ROLE` / `BURNER_ROLE`                        | gerenciamento da oferta                                                                                         |
| `YIELD_MANAGER_ROLE` / `YIELD_DISTRIBUTOR_ROLE`      | definir o token de rendimento, executar distribuições                                                           |
| `UPGRADER_ROLE`                                      | fazer o upgrade do token via UUPS (mantido pelo emissor; conceda à fábrica para upgrades mediados pela fábrica) |
| Módulo de lista de permissões `WHITELIST_ADMIN_ROLE` | adicionar/remover endereços, alternar o modo restrito                                                           |

Consequências que vale a pena conhecer: uma **carteira de investidor perdida** só pode ser recuperada por ação do emissor (colocando um endereço substituto na lista de permissões e, se necessário, usando os poderes de mint/burn/upgrade conforme seu processo jurídico — o Arc não possui primitiva integrada de transferência forçada). A custódia da chave do emissor, portanto, faz parte da postura de conformidade; o visualizador de funções do app torna visíveis os detentores de cada poder.

## O que Rome acrescenta — e o que registerToken preserva

Usuários de carteira Solana aparecem como **endereços EVM sintéticos** (derivados de sua chave pública Solana). Para a camada de conformidade, eles são endereços comuns: o emissor os coloca na lista de permissões, o bloqueio os verifica, o rendimento os alcança — uma lista de permissões abrange os dois mundos de carteira. As implicações de custódia estão em [LANES.md](/pt-br/apps-na-rome/bloom/lanes.md).

Como Rome limita contas por transação, os tokens são implantados em partes e ganham status de fábrica por meio de `ArcTokenFactoryV2.registerToken` em vez do único `createToken`. As proteções preservam exatamente o modelo de segurança upstream: o token deve ser um proxy canônico (codehash), sua implementação deve estar na lista de permissões da fábrica (codehash), o chamador deve deter o `ADMIN_ROLE`, e o registro ocorre apenas uma vez. Nada na superfície de conformidade é enfraquecido por esse caminho em partes.


---

# 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/compliance.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.