> 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/issuing.md). # Emisión Bloom te permite emitir un **activo del mundo real con permisos** como un contrato Solidity ordinario en una cadena Rome, y administrarlo desde una consola por activo. El activo es accesible desde billeteras EVM y Solana, pero **la emisión es solo para EVM** — una billetera Solana mantiene activos; no los crea. Esta guía cubre la consola del emisor, el asistente de creación, la puerta de inicio de sesión de la consola y cada una de las seis pestañas de administración. > **No le entregas a Bloom ningún documento ni dato personal, y tu inversor tampoco.** Bloom registra la *resultado* de tu decisión de cumplimiento; la cadena registra un booleano por dirección. Tu proceso KYC/AML — tus proveedores, tus archivos, tu retención — permanece por completo en tu propio sistema. El modelo completo está en [COMPLIANCE.md](/es/apps-en-rome/bloom/compliance.md); esta guía lo señala en lugar de repetirlo. *** ## Lo que puedes hacer Como administrador de un activo, todo lo siguiente lo haces desde la consola — y cada una de estas acciones es una transacción real en cadena, vinculada en la página: [Prueba](/es/apps-en-rome/bloom/evidence.md) página: * **Emitir un activo** — el asistente lo despliega como tres contratos (abajo). * **Revisar solicitudes** — aprobar o rechazar cada una (un rechazo incluye un motivo que se le debe al solicitante) y admitir una dirección aprobada en la allowlist. * **Administrar la allowlist** — añadir una dirección, añadir **un lote de direcciones en una sola transacción** (`batchAddToWhitelist`), o eliminar una dirección; el token aplica la lista en cada transferencia. * **Restringir el activo** — restringir las transferencias a la allowlist (lo que hace que la oferta sea definitiva), o levantar la restricción. * **Administrar la oferta** — leer el total, y acuñar o quemar una vez que tengas el rol. * **Gestionar la venta** — abrir una venta (unidades y precio), cerrarla, recuperar el inventario no vendido y retirar los ingresos. * **Establecer y distribuir rendimiento** — establecer la moneda de pago y luego distribuir un pago, que recorre los titulares una transacción a la vez; los titulares excluidos se omiten. * **Administrar roles** — conceder un rol a una dirección, revocar uno o renunciar al propio. Cada una se detalla abajo, junto con lo que la cadena aplica, en la pestaña a la que pertenece. *** ## La consola del emisor ![La consola del emisor en /issuer, que lista los activos que conoce esta implementación y su estado de venta.](https://1082203750-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 los activos que has emitido en esta cadena y te permite iniciar uno nuevo. * Conecta una **billetera EVM**. A un visitante desconectado, o a una billetera Solana, se le muestra un aviso para conectar el tipo correcto de billetera en lugar de una consola vacía — una billetera Solana no puede emitir, y ese es un límite del producto que la cadena aplica como una segunda barrera independiente. * La tabla lista cada activo con su **nombre y símbolo**, su ciclo de vida **fase**, y su **Venta** estado (una *Abre* insignia o *Cerrada*). Dos columnas — **Titulares** y **Por revisar** — muestran un guion. El recuento de titulares necesita la enumeración de la allowlist y la cola de revisión es un almacén fuera de cadena en el que inicias sesión por activo; un guion dice *no solicitado* donde un `0` pretendería afirmar un hecho que la aplicación no ha leído. Pulsa **Emitir un activo** para abrir el asistente, o selecciona una fila para abrir la consola de ese activo. *** ## Crear un activo: el asistente ![El asistente de creación en /create: los campos del activo, y luego seis tarjetas que se iluminan a medida que llegan sus transacciones.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-94683a3a49ac2418aed8cc66dbf47fad940814f7%2Fcreate-wizard.png?alt=media) `/create` recoge cuatro campos y luego despliega tu activo. | Campo | Regla | | ------------- | -------------------------------- | | **Nombre** | Obligatorio. | | **Símbolo** | Obligatorio. | | **Oferta** | Un número entero mayor que cero. | | **Decimales** | Un número entero de 0 a 18. | Pulsa **Iniciar**. Si un campo no es válido, el asistente te dice cuál y por qué, en lugar de quedarse detrás de un botón deshabilitado. Cuando el borrador es válido, se le pide a tu billetera que firme cada paso por turno. ### Por qué se despliega por partes > **Un token se despliega como tres contratos a lo largo de varias transacciones — nunca en una sola.** El de una sola transacción de Arc `createToken` necesitaría **77 bloqueos de cuenta**, y Rome limita una sola transacción a **62 bloqueos**. `ArcTokenFactoryV2.registerToken`Así que el asistente despliega cada pieza en su propia transacción y luego obtiene el estado de fábrica mediante [COMPLIANCE.md](/es/apps-en-rome/bloom/compliance.md#what-rome-adds-and-what-registertoken-preserves). ### Las seis tarjetas El asistente muestra seis tarjetas, que siguen el progreso del despliegue. Una tarjeta pasa de **Esperando** a **Firmando…** a **Hecho** (o **Fallido**) cuando su transacción llega. | # | Tarjeta | Qué hace | | - | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Implementación** | La implementación compartida del activo para esta cadena — resuelta, nada que firmar. (Hecho antes de que se ejecute cualquier paso.) | | 2 | **El activo** | Despliega tu activo y establece su nombre, símbolo, oferta y decimales en un solo paso. | | 3 | **Quién puede poseerlo** | Despliega el propio módulo de permisos de este activo, contigo como administrador. | | 4 | **Aplica en las transferencias** | Apunta el activo a ese módulo, de modo que cada transferencia sea verificada por el propio activo. | | 5 | **Reglas de rendimiento** | Despliega y vincula el módulo que decide quién cobra. | | 6 | **Registro** | Registra el activo — esto es lo que abre la venta y te permite actualizarlo más adelante. | Las seis tarjetas agrupan ocho pasos de despliegue subyacentes, así que una sola **Iniciar** da como resultado **ocho firmas**. Una nota debajo del botón dice *"Tu billetera te pedirá firmar cada paso. Puedes detenerte en cualquier momento y retomar donde lo dejaste — no se pierde nada."* Que el registro sea el paso final es por lo que detenerse es seguro: el activo es un despliegue real en cada etapa, registrado al final. Cuando la ejecución termina, el asistente muestra *"Emitido. Tu activo está en funcionamiento en …"* con un enlace a la consola del activo en `/token/[address]`. > **`initialize` te concede todos los roles.** El ejecutor del asistente — tu dirección EVM — recibe los roles de administrador, acuñador/quemandor, gestor/distribuidor de rendimiento y actualizador del token, además del rol de administrador del módulo de allowlist. Por tanto, la custodia de tu clave forma parte de la postura de cumplimiento del activo: una billetera de inversor perdida solo se puede recuperar mediante tu acción de administrador, y la pestaña de la consola **Derechos** hace visible el titular de cada poder. (`UPGRADER_ROLE` es *no* concedido automáticamente a la fábrica — concédelo explícitamente si quieres actualizaciones mediadas por la fábrica.) *** ## La consola por activo y la puerta de inicio de sesión ![La puerta de inicio de sesión de la consola: firma un mensaje con tu billetera — no hay contraseña.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-a9377e3cad8460af1d9bb4eb3cf6f2a6a8f28b22%2Fconsole-signin.png?alt=media) Al abrir `/token/[address]` no **no** muestra la consola de inmediato. Muestra una **puerta de inicio de sesión**: > *"Inicia sesión para administrar este activo. Firma un mensaje con tu billetera — no hay contraseña. Tu autoridad proviene del propio activo, y se vuelve a comprobar en cada acción, así que revocarla surte efecto de inmediato."* Pulsa **Inicia sesión con tu billetera**. Esto es exactamente lo que sucede: 1. Se le pide a tu billetera que `personal_sign` una breve declaración legible por humanos (encabezada *"Bloom — demuestra que administras este activo"*) que nombra la única acción que autoriza — leer la cola de solicitudes de este activo — junto con la dirección del activo, el id de la cadena y una marca de tiempo. 2. La aplicación envía esa declaración firmada a `GET /api/applications`. 3. La **servidor** la verifica: recupera tu dirección a partir de la firma, confirma que la declaración es para esta cadena y que sigue siendo reciente (autoriza durante una ventana de dos minutos, no una sesión), lee el **módulo de allowlist propio del token** desde la cadena, y comprueba que tu dirección posee el rol que realmente requiere la escritura de allowlist — `MANAGER_ROLE` en ese módulo. 4. Si lo tienes, la cola se devuelve y la consola se renderiza. Si no, el servidor rechaza con `403` y un motivo. ![La puerta mostrando un rechazo citado: se rechaza a una billetera que no administra este activo.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-99040b8d3c752f0f84615b913d6b75fb0d36f81b%2Fconsole-refusal.png?alt=media) > **El activo decide quién puede administrarlo — no esta aplicación.** El rol se comprueba en la allowlist **el módulo**, no en el token, y poseer un rol con el mismo nombre en el token no *no* se transfiere — son autoridades distintas. No hay cuenta ni sesión: cada solicitud posterior lleva su propia firma reciente, que es lo que *"se vuelve a comprobar en cada acción"* significa. Revoca el rol de una billetera en la cadena y deja de poder iniciar sesión de inmediato. Un rechazo muestra el motivo **entre comillas** — Bloom nunca escribe una frase sobre por qué se rechazó una billetera. Si rechazas la firma en tu billetera, ese es tu *"no"*, no el del activo, y no se informa como un rechazo. > **La puerta responde a de-quién-es-la-consola, no a qué-es-secreto.** La oferta, el estado de la venta, la lista de la allowlist y los roles son lecturas públicas de la cadena que cualquier explorador responderá. Lo que la firma compra es la **cola de solicitudes** — las declaraciones de otras personas — y el derecho a que te muestren la consola en absoluto. ### El encabezado de la consola Una vez iniciada la sesión, el encabezado nombra el activo y muestra su **fase** — el dato más trascendente que tiene: | Fase | Significado | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Borrador** | Todavía no hay un módulo de permisos vinculado, así que nada restringe quién puede poseer esto. | | **Abre** | Las transferencias están abiertas y la oferta aún puede cambiar. Restringir el activo hace que su oferta sea definitiva, y eso no se puede deshacer. | | **Restringido** | Solo las direcciones incluidas en la allowlist pueden poseer esto, **y su oferta es definitiva** — ya no se puede acuñar ni quemar más, de forma permanente. | Encima de las pestañas, un resumen muestra cuatro cifras — **Titulares · Por revisar · Vendido · Rendimiento pagado**. Dos se leen de la cadena y del almacén (*Por revisar* una vez que hayas iniciado sesión; *Vendido* de la tienda); *Titulares* depende del recuento de titulares de la vista previa de rendimiento, y *Rendimiento pagado* depende del cursor del historial de pagos que aún está por llegar. Cada celda en espera muestra un guion y explica qué necesita, en lugar de un `0` que pretendería afirmar un hecho que nadie le pidió a la cadena. *** ## Las seis pestañas La consola tiene seis pestañas, en este orden: **Solicitudes · Quién puede poseerlo · Oferta · Venta · Rendimiento · Derechos.** Cada escritura en estas pestañas usa un control compartido que muestra las **precondiciones nombradas** y sus **consecuencias** *antes de* el botón, y nombra su fase mientras se ejecuta (*"Esperando tu billetera…"*, *"Llegando a la cadena…"*). Nada debería revertirse para enseñarte qué podría haberse comprobado primero. ### Solicitudes — la cola de revisión ![La pestaña Solicitudes — la cola de revisión, con una solicitud pendiente para aprobar o rechazar, y la costura de cumplimiento.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-8249de8b76f757101cc945ca4a2687103428839c%2Ftab-applications.png?alt=media) Esta pestaña lista quién ha solicitado poseer el activo. Cada fila muestra la dirección del solicitante, la jurisdicción, el tipo de titular, una **Comprobaciones** columna (*Aprobado* si tu proveedor registró un resultado, si no *Declarado*), y una **Estado** (*Por revisar*, *Aprobado*, *Rechazado*). Expande una fila para ver sus hechos y dos controles: **Aprobar — puede poseerlo** y **Rechazar**. Un rechazo requiere un motivo, que se convierte en la respuesta del solicitante. > **Aprobar son dos actos separados, y la pestaña los mantiene honestos.** Al pulsar **Aprobar** *registra* tu decisión en el almacén de solicitudes. Poner la dirección en la allowlist del activo en la cadena es una **segunda firma** — `batchAddToWhitelist` — y hasta que llegue la fila lo indica así. Cuando la decisión registrada y la cadena no coinciden, la pestaña nombra la brecha y ofrece la escritura que la cierra: **Admitir** para añadir una dirección aprobada a la allowlist, o (para una dirección rechazada que aún figura) el control para eliminarla. La dirección no puede poseer el activo hasta que la escritura de allowlist se confirme. Una nota permanente en esta pestaña — la **costura de cumplimiento** — indica dónde encaja tu propio proceso: > *"No se solicitan ni se guardan documentos aquí — las comprobaciones son tuyas. Conecta a tu proveedor detrás de la `Solicitudes` interfaz, o importa las decisiones que ya hayas tomado. Bloom registra el resultado y la cadena registra un sí o un no contra la dirección."* Esa es la interfaz que sustituye un emisor autohospedado: cambia la implementación del almacén de solicitudes por tu propia implementación duradera y ningún llamador cambia. Bloom no realiza comprobaciones y no guarda ningún documento. ### Quién puede poseerlo — la puerta de transferencias ![La pestaña Quién puede poseerlo — el recuento de la allowlist y el control de restringir transferencias, mostrando sus consecuencias de puerta de sentido único.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-d32c410e3b5798d86dc5b914bce2f927eb4b1620%2Ftab-holders.png?alt=media) Esta pestaña informa cuántas direcciones están en la allowlist del activo, y te permite cambiar si la allowlist está **aplicada**: * Cuando las transferencias están **sin restricciones**, ofrece **restringir las transferencias a la allowlist**. Las consecuencias de la escritura indican que hacerlo hace que la oferta sea definitiva y es una puerta de sentido único para los no administradores. * Cuando las transferencias están **restringidas**, ofrece **levantar la restricción**. Sus consecuencias dejan claro que esto no es una reversión. En un *sin restricción* (borrador) sin módulo de permisos vinculado, la pestaña lo indica — *"No hay ningún módulo de permisos vinculado, así que nada restringe quién puede poseer esto"* — y el interruptor no se muestra. > **El token comprueba ambos lados de cada transferencia.** Mientras el activo esté restringido, una transferencia en la que cualquiera de las partes esté fuera de la allowlist se revierte en la cadena con un error tipado. La misma puerta se aplica a una transferencia desde una billetera EVM, una transferencia firmada por Solana, una venta en la tienda y el movimiento inicial de liquidez — no hay forma de rodearla salvo con tus propios poderes de administrador. ### Oferta ![La pestaña Oferta — unidades totales en existencia.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-29eb2d741e5193eef3ea94a214a199f2eb404fe7%2Ftab-supply.png?alt=media) Esta pestaña informa la oferta total en existencia, en unidades enteras. ### Venta — abrir, cerrar y retirar ingresos ![La pestaña Venta — una venta abierta, con los controles para cerrar la venta, recuperar lo no vendido y retirar los ingresos.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-573a99f9028a984b038162dc885a16b715673293%2Ftab-sale.png?alt=media) Esta pestaña ejecuta la venta principal a través del contrato de la tienda. * **Cuando no hay ninguna venta abierta**, ofrece abrir una: introduce **Unidades a vender** y **Precio por unidad** (en `wUSDC`), luego pulsa **Abrir la venta**. Las precondiciones de la escritura se muestran primero — el token debe estar registrado, la tienda debe tener el inventario de la venta y la propia tienda debe estar en la allowlist del token que vende — de modo que una venta que aún no se puede abrir dice exactamente lo que necesita. * **Cuando una venta está abierta**, muestra cuántas unidades quedan de la oferta y ofrece **Cerrar esta venta**. * **Recuperar unidades no vendidas** mueve el inventario no vendido desde la tienda de vuelta a un destinatario (por defecto, tú). Esto es **no** un cierre — la venta sigue habilitada, y la consecuencia de la escritura lo dice, así que una recuperación no puede confundirse con una reversión. * **Retirar ingresos** envía la recaudación de la tienda a una dirección (por defecto, tú). Los ingresos se acumulan independientemente del estado de la venta, así que se pueden retirar tanto si la venta está abierta como cerrada. ### Rendimiento — pagar a los titulares, uno por transacción ![La pestaña Rendimiento — el campo del importe de distribución, con el recordatorio de establecer primero una moneda de pago.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-cc8150ea6fee72d99bd5a2254073779cbd896c11%2Ftab-yield.png?alt=media) Esta pestaña distribuye un pago de rendimiento a los titulares. > **Una distribución es un recorrido, no un clic.** En Rome, `distributeYieldWithLimit` paga **un titular por transacción** (el límite de cuentas), así que un pago es una secuencia de ventanas, cada una con su propia firma. Introduces el importe una sola vez, en unidades enteras de la moneda de pago, y queda bloqueado una vez que comienza el recorrido. La **primero** ventana extrae de ti el pago completo y paga al primer titular; cada ventana posterior solo mueve dinero que ya está dentro del contrato del token. Bloom vuelve a leer el cursor de la cadena después de cada ventana — el conjunto de titulares se reordena a medida que cambian los saldos, y enviar un índice desactualizado reiniciaría desde cero y volvería a retirar tu dinero una segunda vez. La pestaña muestra el progreso — *"Pagando al titular N de M"* — y termina cuando el cursor vuelve al inicio. Si el activo no tiene una moneda de pago configurada, la pestaña lo indica; establecer la moneda de pago es el único campo de una distribución que solo tú puedes elegir. > **Las participaciones de los titulares restringidos permanecen en el contrato.** Se omite una dirección excluida por el módulo de lista negra de rendimiento, y su parte proporcional permanece en el contrato del token en lugar de pagarse. Los pagos pasados aún no se muestran — leerlos recorre los eventos de distribución hacia atrás hasta el primer bloque del activo, lo que necesita un cursor de historial que aún está por llegar. La pestaña lo dice dentro de sí misma en lugar de mostrar un `0`. ### Derechos — los roles ![La pestaña Derechos — cada rol y si se posee, y el control para conceder / revocar / renunciar.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-fb54f6c73c2d194dd5b6321bc3cb0af825f6f637%2Ftab-rights.png?alt=media) Esta pestaña lista cada rol que declara el token y si se posee, cada uno leído con una sola `hasRole` llamada al token. Un rol que está **no** poseído se muestra como tal en lugar de omitirse — en una pestaña de derechos, una fila ausente y un *"no"* son hechos distintos. Debajo de la lista, un control cambia los roles: | Acción | Actúa sobre | Autoridad | | ------------------------- | --------------------------------------------------------------------------- | -------------------- | | **Conceder a una cuenta** | Una dirección que introduces | `DEFAULT_ADMIN_ROLE` | | **Revocar de una cuenta** | Una dirección que introduces | `DEFAULT_ADMIN_ROLE` | | **Renunciar al propio** | Tú mismo (OpenZeppelin requiere que la confirmación sea el propio llamador) | Tú | Las opciones de rol son las propias del token, así que el control nunca puede ofrecer un rol que el token no tenga. Como en toda escritura, la fila de autoridad y la consecuencia se muestran antes del botón, así que la puerta y su carácter de sentido único se indican antes de que firmes. *** ## Lo que nunca toca Bloom ni la cadena Para no dejar dudas sobre dónde reside el cumplimiento: | Cosa | Dónde reside | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Documentos KYC/AML e información personal identificable | Tu propio sistema, con tus propios proveedores y retención — **nunca** esta aplicación o la cadena | | Tu decisión de admitir una dirección | Un registro fuera de cadena; tú eres dueño del almacén | | El efecto en cadena de esa decisión | Un booleano — `isWhitelisted(address)` — escrito por `batchAddToWhitelist` | | Aplicación de la regla | El contrato del activo, en cada transferencia | | Quién puede administrar el activo | El rol que se posee en el módulo de allowlist del activo, comprobado en cada solicitud | Para ver el modelo de cumplimiento completo, lee [COMPLIANCE.md](/es/apps-en-rome/bloom/compliance.md); para la mecánica de dos vías (EVM y Solana) que usan tus titulares, lee [LANES.md](/es/apps-en-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/es/apps-en-rome/bloom/issuing.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.