> 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/es/apps-en-rome/bloom/compliance.md).

# Modelo de cumplimiento

Bloom ejecuta el marco Arc de Plume sin modificaciones. El cumplimiento es **aplicado por el propio contrato del token** — no por ningún filtro fuera de la cadena, filtro del secuenciador o política del lugar de negociación. Esa es la propiedad que lo hace portable: las reglas viajan con el token a cualquier ruta de ejecución, en ambas vías de monedero.

## Arquitectura de aplicación

```
ArcToken._update (en cada transferencia/mint/burn)
   └─ RestrictionsRouter (uno por cadena, registro de módulos por tipo)
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions (por token)
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions (por token)
        └─ GLOBAL_SANCTIONS     → (el espacio existe; no hay ningún módulo global desplegado)
```

* **WhitelistRestrictions** — la lista blanca. Mientras `transfersAllowed` es falso (modo restringido), una transferencia en la que cualquiera de las partes no esté en la lista revierte con el error tipado `TransferRestricted()` (`0xe827105e`). La comprobación se ejecuta dentro del token en cada movimiento de saldo — una transferencia de monedero EVM, una transferencia firmada de Solana, una venta en la tienda y el movimiento inicial de liquidez pasan todos por la misma puerta. No hay forma de rodearlo salvo mediante los propios poderes administrativos del emisor.
* **YieldBlacklistRestrictions** — excluye direcciones de las distribuciones de rendimiento; su parte proporcional permanece en el contrato del token.
* **GLOBAL\_SANCTIONS** — el router admite módulos a nivel de cadena aplicados a cada token (p. ej., una lista de sanciones). Hoy no hay ninguno desplegado; el espacio es el lugar natural para uno operado a nivel de cadena.

## El modelo de confianza, dicho con honestidad

**La bandera de lista blanca es la decisión fuera de la cadena del emisor.** KYC/AML ocurre en el proceso del emisor (sus proveedores, sus reglas); la cadena registra y aplica el *resultado* — `isWhitelisted(addr)`. [Incorporación y revisión](/es/apps-en-rome/bloom.md) es el mecanismo que rodea esa decisión — cómo solicita un inversor, cómo decide el emisor y la pista de auditoría que deja — y no cambia este modelo: sigue siendo decisión del emisor, sigue siendo solo un booleano en la cadena y no hay documentos en ninguna parte. Este es el propio modelo del marco Arc tal como se usa en Plume. Es deliberadamente *no* un sistema de identidad en la cadena: no hay reclamaciones de identidad, ni atestaciones en la cadena, ni prueba criptográfica de a quién pertenece una dirección. Los estándares que incorporan identidad verificable en la cadena (p. ej., ERC-3643) intercambian transferencias significativamente más pesadas por esa propiedad; Arc intercambia mecánicas más ligeras por una confianza en manos del emisor. Bloom lo muestra con honestidad en lugar de insinuar más.

## Poderes del emisor (con forma de agente de transferencia)

`ArcToken.initialize` concede al controlador del asistente todos los roles:

| Rol                                             | Poder                                                                                                                     |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `ADMIN_ROLE` / `DEFAULT_ADMIN_ROLE`             | vincular/reemplazar módulos de restricción, gestionar roles                                                               |
| `MINTER_ROLE` / `BURNER_ROLE`                   | gestión de suministro                                                                                                     |
| `YIELD_MANAGER_ROLE` / `YIELD_DISTRIBUTOR_ROLE` | establecer el token de rendimiento, ejecutar distribuciones                                                               |
| `UPGRADER_ROLE`                                 | actualizar el token mediante UUPS (en manos del emisor; conceder al factory para actualizaciones mediadas por el factory) |
| Módulo de lista blanca `WHITELIST_ADMIN_ROLE`   | añadir/eliminar direcciones, activar/desactivar el modo restringido                                                       |

Consecuencias que conviene conocer: una **billetera de inversor perdida** solo puede recuperarse mediante una acción del emisor (incluir en la lista blanca una dirección de reemplazo y, si es necesario, usar los poderes de mint/burn/upgrade según su proceso legal — Arc no tiene una primitiva integrada de transferencia forzosa). La custodia de la clave del emisor forma por tanto parte de la postura de cumplimiento; el visor de roles de la app hace visibles a los titulares de cada poder.

## Lo que añade Rome — y lo que preserva registerToken

Los usuarios de monederos Solana aparecen como **direcciones EVM sintéticas** (derivadas de su clave pública de Solana). Para la capa de cumplimiento son direcciones ordinarias: el emisor las añade a la lista blanca, la puerta las comprueba, el rendimiento les llega — una sola lista blanca abarca ambos mundos de monedero. Las implicaciones de custodia están en [LANES.md](/es/apps-en-rome/bloom/lanes.md).

Como Rome limita las cuentas por transacción, los tokens se despliegan por partes y obtienen estado de factory mediante `ArcTokenFactoryV2.registerToken` en lugar del `createToken`. Las comprobaciones preservan exactamente el modelo de seguridad original: el token debe ser un proxy canónico (codehash), su implementación debe estar en la lista blanca de la factory (codehash), el llamador debe poseer el del token `ADMIN_ROLE`, y el registro es de una sola vez. Nada de la superficie de cumplimiento se debilita por la ruta por 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/es/apps-en-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.