> 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/investing.md). # Invertir Bloom es un mercado para **activos del mundo real con permisos**. Cada activo es un contrato Solidity ordinario desplegado una sola vez en una cadena Rome, y la regla sobre quién puede tenerlo vive dentro de ese contrato. Esta guía acompaña a un comprador desde la página de inicio, pasando por explorar un activo, comprobar la elegibilidad, solicitar la allowlist, comprar y mantenerlo — y luego cubre la única cosa que realmente es diferente para un titular que firma con una billetera Solana. > **La regla viaja con el activo.** Quién puede tener un activo lo hace cumplir el propio contrato del activo, en cada transferencia — no este sitio web. Nada en ninguna pantalla aquí puede anularlo, y no existe ningún rodeo. Bloom es una ventana a la cadena; la cadena es la que decide. *** ## Qué significa «con permisos» para un comprador Un activo con permisos tiene una **allowlist**: un conjunto de direcciones que el emisor ha decidido que pueden tenerlo. La allowlist no es una función de Bloom: vive en un módulo adjunto al contrato del activo, y el activo la consulta en cada acuñación, quema y transferencia. > **La cadena guarda un solo hecho sobre ti: un único sí o no frente a tu dirección.** Nunca se almacena ningún documento, información personal ni declaración de identidad en la cadena ni en esta aplicación. Cuando un emisor te admite, lo único que llega a la cadena es `isWhitelisted(yourAddress) = true`. El modelo completo de cumplimiento está en [COMPLIANCE.md](/es/apps-en-rome/bloom/compliance.md). De ello se desprenden dos consecuencias, y ambas son visibles en el producto: * Antes de que puedas comprar, se le pregunta al activo si **tu dirección** puede tenerlo. Una negativa es un hecho sobre la regla del activo, no un problema con tu billetera. * Una transferencia a una dirección que el emisor no ha aprobado **se revierte en cadena**. El activo la rechaza; ninguna pantalla tiene que hacerlo. *** ## Los dos mundos de billeteras Un solo activo de Bloom es accesible desde **ambas** una billetera EVM (como MetaMask) y una billetera Solana (como Solflare). Conectas una billetera a la vez. Una billetera Solana tiene que poder firmar transacciones de Solana versión 1: Solflare lo hace hoy en devnet, y Phantom todavía no. | Billetera | Dónde se mantiene el activo | Qué firma | | -------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Billetera EVM** | Su propia dirección EVM, como en cualquier cadena EVM | Una transacción EVM | | **wallet de Solana** | Una dirección EVM **derivada de tu clave pública de Solana** | Tu firma de Solana, solicitada dos veces por paso (véase [Pagar, y las solicitudes de firma adicionales](#paying-and-the-extra-signature-prompts)) | Para una billetera EVM no hay nada nuevo que aprender. Para una billetera Solana, el activo reside en una *derivada* dirección — calculada como `keccak256(solana_pubkey)[12..32]` — y solo tu firma de Solana puede moverlo. No hay **ningún puente, ningún segundo token ni ninguna cuenta EVM** implicados. Esto se cubre por completo en [la sección del titular de Solana](#for-a-solana-holder) abajo y en [LANES.md](/es/apps-en-rome/bloom/lanes.md). *** ## La página de inicio ![La página de inicio de Bloom: el titular, las dos filas de mundos de billeteras y las puertas de Inversor y Emisor.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-d24cbcc96b6ec85d6a62caa993ccd38d3aff82fc%2Flanding.png?alt=media) La página de inicio (`/`) indica qué es Bloom — *activos en Solidity, abiertos tanto a Solana como a EVM* — y te da dos puertas: **Inversor** (que te lleva a los activos abiertos en `/invest`) y **Emisor**. Como comprador, elige **Inversor**. Dos filas, **billeteras Solana** y **billeteras EVM**, enumera las billeteras que tu navegador ha anunciado realmente a través de los protocolos de descubrimiento EIP-6963 y Wallet Standard. No se muestra nada que no tengas instalado; el nombre y el icono de cada billetera son propios. Al pie, una **Contratos** sección enumera las direcciones con las que habla esta implementación — la fábrica de tokens, la implementación compartida, el enrutador de permisos, la tienda de venta primaria y el token de efectivo — cada una enlazando al explorador de bloques, de modo que la aplicación nunca afirma una dirección con su propia voz. ### «¿Cómo es posible con Solana?» ![La explicación de custodia: una firma entra por la izquierda y el activo la admite por la derecha, sin puente entre ambas.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-18d251b822b78890123e6049df399d603523af5d%2Fcustody.png?alt=media) La página de inicio incluye una explicación que responde cómo una billetera Solana puede tener un activo en Solidity. Plantea tres puntos: * **Un despliegue.** El activo es un contrato Solidity ordinario, desplegado una sola vez. No existe una copia puenteada en ningún sitio: una segunda copia es exactamente lo que le permitiría escapar de las reglas. * **Dos mundos de billeteras.** Una billetera EVM accede al contrato del mismo modo que accede a cualquier cadena. Una billetera Solana accede al *misma* contrato porque una cadena Rome se ejecuta dentro de Solana: el activo se mantiene en una dirección EVM derivada de tu clave de Solana, y tu firma es lo único que puede moverlo. * **El activo contiene la regla.** Quién puede tenerlo lo hace cumplir el contrato en cada transferencia — no este sitio ni un puente. Una dirección que el emisor no ha aprobado simplemente no puede recibirlo. *** ## Explorar activos abiertos ![La lista de activos abiertos en /invest, con precio e inventario leídos en vivo de la cadena.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-18422483cf862d7243349361c7dcbd4d9c6b436b%2Finvest-list.png?alt=media) `/invest` enumera todos los activos con una venta abierta ahora mismo. Para cada fila ves: | Columna | Significado | | ----------- | ------------------------------------------------------------------ | | **Activo** | El nombre y el símbolo del activo, leídos del propio token | | **Precio** | El precio de una unidad, en `wUSDC` | | **Vendido** | Unidades vendidas de unidades ofrecidas, con una barra de progreso | El resumen sobre la tabla cuenta **Abiertas ahora** (cuántas ventas están activas), **Emitidas aquí** (cuántos activos ha emitido esta cadena) y **Pagado en** (`wUSDC`, el token de efectivo para cada venta en este despliegue). > **Nada en esta página está codificado.** El precio, el inventario y el estado se leen en vivo de la cadena en cada visita. Si la cadena no responde, la página lo dice — *«La cadena no respondió…»* — en lugar de mostrar un número obsoleto o afirmar que está vacío. *«No hay nada a la venta ahora mismo»* es una afirmación sobre la cadena, y solo aparece cuando la cadena realmente devuelve una lista vacía. Puedes leer precios e inventario sin conectar. Para comprar, necesitarás una billetera: la página muestra una **Conectar billetera** solicitud, ofreciendo tus billeteras EVM y Solana bajo dos encabezados. Al seleccionar una fila se abre la página de detalles de ese activo. *** ## Un activo ![Una página de detalles del activo: los datos a la izquierda, la tarjeta de elegibilidad y el panel de compra a la derecha.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-341ebd012e46da597a5832fe6ba39af8704be545%2Fasset-detail.png?alt=media) Una página de activo (`/invest/[address]`) tiene dos mitades: los datos y reglas del activo a la izquierda, y tu elegibilidad y el panel de compra a la derecha. ### Los datos | Dato | Significado | | ------------------------- | ----------------------------------------------------------------- | | **Precio** | Precio de una unidad, en `wUSDC` | | **Disponible** | Unidades aún disponibles en la venta abierta | | **Rendimiento pagado en** | La moneda en la que se distribuye cualquier rendimiento (`wUSDC`) | ### Quién puede tenerlo La página establece tres reglas que el activo aplica: | Regla | Qué dice | | ------------------------ | ------------------------------------------------------------------------------------- | | **Titulares permitidos** | Direcciones aprobadas por el emisor. Verificadas por el activo en cada transferencia. | | **Mínimo** | 1 unidad. Sin bloqueo. | | **Transferencias** | Solo a otra dirección permitida, desde cualquiera de los dos mundos de billeteras. | > **El activo verifica esto por sí mismo en cada transferencia. Nada en esta página puede anularlo.** Las reglas se expresan como hechos sobre el token, no como la política de esta aplicación, porque eso es lo que son. *** ## Elegibilidad — verificada en el token, antes de cualquier compra ![La tarjeta de elegibilidad resolviéndose en la página del activo: conectar, luego comprobando, luego permitido o no permitido.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-2280eee77f97ef3f1334451fb95811391fedf519%2Feligibility.png?alt=media) Antes de ofrecerte una compra, la página del activo le pregunta al propio módulo de allowlist del activo si **tu dirección** puede tenerlo. La tarjeta de elegibilidad muestra uno de estos estados: | Estado | Significado | | -------------------------- | -------------------------------------------------------------------------------------- | | **Conecta para comprobar** | Todavía no hay ninguna billetera conectada. Conecta una para ejecutar la comprobación. | | **Comprobando…** | Conectada; la comprobación en cadena aún no se ha resuelto. | | **Permitido** | Tu dirección puede tener este activo. | | **No permitido** | La regla del activo rechaza tu dirección. Un enlace ofrece solicitar la allowlist. | | **No disponible** | La comprobación no pudo leerse ahora mismo (no es un rechazo). | > **La comprobación es bilateral.** Una compra mueve unidades *de la tienda a ti*, por lo que ambas partes de esa transferencia deben estar en la allowlist. Bloom formula la pregunta así: una comprobación unilateral te declararía elegible y luego vería cómo la compra se revierte porque la tienda no figura en ese token. Una vez que tu dirección está en la allowlist, la misma tarjeta muestra **Permitido**, y la compra queda abierta para ti: ![La tarjeta de elegibilidad mostrando Permitido — el comprador está en la allowlist, y el panel de compra está activo.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-46bb4f6d6d75bd6d0674c3fdbece1d8acd70f5b5%2Finvest-permitted.png?alt=media) Cuando se te rechaza, el motivo que se muestra es **el propio**del token, citado textualmente. Bloom nunca escribe una frase sobre por qué se te rechazó. Si el activo aún no tiene un módulo de allowlist vinculado (un borrador), está *sin restricciones* — no se está restringiendo a nadie, y estás permitido. Si se te rechaza, la tarjeta enlaza a **Solicitar la allowlist**. *** ## Solicitar la allowlist ![El formulario de solicitud: una dirección, una jurisdicción, un tipo de titular y dos declaraciones — sin documentos.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-cd846bf05c44424259e0308af395f1cb3acd16ae%2Fapply.png?alt=media) `/apply` es donde pides a un emisor que admita tu dirección. Su introducción dice toda la historia: **Sin documentos. Solo declaraciones.** > **El formulario no guarda nada que merezca filtrarse, y no escribe nada en ninguna cadena.** Una solicitud es un registro fuera de la cadena sobre el que el emisor decide. El emisor ejecuta sus propias comprobaciones en su propio sistema; la escritura en la allowlist ocurre de su lado, y lo único que llega a la cadena es el resultado sí o no frente a tu dirección. Debes proporcionar cuatro cosas y ninguna quinta: | Campo | Notas | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **La dirección que lo tendrá** | Rellenada previamente desde tu billetera conectada. Para una billetera Solana, esta es tu **derivada** dirección — la dirección donde se encuentra el activo, no la clave que firma por él. | | **Jurisdicción** | Una de una lista fija (Singapur, Emiratos Árabes Unidos, Suiza, Reino Unido). | | **Eres** | Individuo, individuo acreditado o institución. | | **Dos declaraciones** | Ambas deben aceptarse: que actúas por tu cuenta y controlas la dirección, y que aceptas que el emisor decide quién puede tener el activo y puede revocarlo. | La `?` junto al lede explica por qué no se piden documentos: el emisor solo necesita aquello sobre lo que actuará, nada de lo que podrías subir podría almacenarse aquí, y en cadena el registro es un único sí o no. **Para solicitar:** 1. Confirma la dirección, elige tu jurisdicción y tipo de titular, y acepta ambas declaraciones. 2. Pulsa **Enviar solicitud**. El formulario valida localmente y el almacén vuelve a comprobar todo en el servidor, porque un formulario está a una solicitud de ser eludido. 3. Se te da un **enlace privado** del formulario `…/apply/status?ref=AP-XXXX-XXXX-XXXX`. > **Guarda el enlace — es la única forma de volver a tu solicitud.** La referencia se acuña a partir de 60 bits de aleatoriedad criptográfica y *es* la autorización: nada más se interpone entre tus declaraciones, y no hay ninguna cuenta ni contraseña para recuperarlas. En la demo, un **Cableado de prueba** te señala `/approve`, donde puedes aprobar tu propia solicitud para completar el ciclo. Un emisor real hace este paso en su propio sistema — [véase abajo](#approve-the-test-wiring-stand-in). *** ## El estado de tu solicitud y borrar declaraciones ![La página de estado — la referencia, los hechos declarados, la línea de tiempo y el control de borrado.](https://1082203750-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` lee una solicitud a partir de su referencia (desde el `?ref=` enlace, o el último que este navegador recuerda). No hay sesión; la referencia es la clave. La página muestra dónde estás — **Con el emisor**, **Puedes tener este activo**, o **Rechazado** — junto con una tabla de detalles (referencia, fecha de solicitud, la dirección, el activo, la jurisdicción y una **Comprobaciones** fila) y una breve cronología de lo que ha sucedido. Si has sido aprobado, aparece un **Compra el activo** enlace. Un rechazo muestra el propio motivo del emisor, citado. La **Comprobaciones** fila refleja el propio registro KYC del emisor. En esta demo no hay ningún proveedor integrado, así que dice *«Solo declaraciones — no se solicitaron documentos»* en lugar de insinuar una verificación que no ocurrió. ### Borrando lo que declaraste Puedes borrar tus declaraciones en cualquier momento, desde esta página. > **Borrar destruye las declaraciones y deja la decisión.** Lo que dijiste sobre ti se elimina y no puede recuperarse. La decisión del emisor permanece, porque ya se ha actuado sobre ella en público, en una cadena — y desdecir eso es una firma que el emisor debe hacer, no un borrado que tú puedas hacer. (El propio registro KYC del emisor, si existe, también permanece, porque es la evidencia del emisor para admitir una dirección que ahora está en una cadena pública; borrarlo aquí no borraría nada en su proveedor tampoco.) *** ## `/approve` — el sustituto del cableado de prueba ![La página de aprobación — el banner «cableado de prueba, no el emisor», la dirección, la acción de aprobar y sus requisitos en cadena en el pliegue de abajo.](https://1082203750-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 todo el recorrido pueda hacerse de extremo a extremo en la demo. Lleva un banner que dice **«Cableado de prueba — no el emisor»**, y ese banner es la razón de que sea honesto tenerlo: en producción el emisor aprueba las solicitudes dentro de su propio flujo de trabajo, no aquí. **Lo que es real en ella:** la aprobación es una escritura genuina de allowlist en cadena. La página llama a un `TestApprover` contrato desplegado que está *habilitado en el activo de demostración* (Mineral Vault I, `ARCV`, en `0x2b13ba16a429bf630f94882e477fe775d34b7c74`). Ese contrato necesita **ningún rol** de quien lo llama — cualquiera puede aprobar cualquier dirección a través de él — que es precisamente la razón por la que existe: permite cerrar el ciclo de la demo para cualquier billetera, desde cualquiera de las dos vías. **Para aprobar tu propia dirección:** 1. Conecta la billetera con la que solicitaste (EVM o Solana). Tu dirección ya viene rellenada. 2. Pulsa **Aprobar esta dirección**. Las precondiciones y consecuencias de la escritura se despliegan debajo del botón — abre *«Qué hace esto»* para ver exactamente qué ocurrirá antes de firmar. 3. Si tiene éxito, la página dice *«Aprobado. El solicitante ahora puede tener el activo.»* Si iniciaste sesión con una billetera Solana, una nota dice *«Esto aprobará la dirección derivada de tu clave de Solana»* — la dirección que firma la ejecución **por** es la derivada; la clave con la que firma **con** es tu clave de Solana. > **En producción, esta es la decisión del emisor, tomada en el sistema del emisor.** La demo `TestApprover` está abierta por construcción para que el ciclo pueda recorrerse; una escritura real de la allowlist está protegida por un rol que posee el emisor. Nada del modelo de cumplimiento cambia: sigue siendo decisión del emisor, sigue siendo un único booleano en cadena y siguen sin haber documentos en ninguna parte. Una vez aprobado, vuelve a la página del activo; tu elegibilidad ahora dice **Permitido**. *** ## Compra El panel de compra se encuentra debajo de la tarjeta de elegibilidad en la página del activo. > **¿Necesitas wUSDC primero?** Cada venta tiene precio en wUSDC, y una billetera nueva no tiene ninguno. [Llevar fondos a Rome](/es/apps-en-rome/bloom/funding.md) te guía en la entrada de efectivo: puentea USDC o ETH desde Sepolia, y luego envuelve el gas puenteado en wUSDC — todo en la `/bridge` pantalla. ![El panel de compra después de que aterriza una compra — «Comprado. Se mostrará en Posiciones.»](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-e2ffc015b988fb56be5cf364aa05ac431a0cb5a2%2Fbuy-done.png?alt=media) 1. Introduce el número de **Unidades** que quieres. El panel muestra el precio unitario y el total que pagarás, en `wUSDC`. (El efectivo que la compra realmente retira se calcula a partir del precio en unidades base, por lo que el importe aprobado siempre coincide con el importe cotizado.) 2. Pulsa el control de compra. Una compra es una secuencia corta, no un solo clic: si la venta aún no tiene permiso para tomar tu `wUSDC`, un **paso de aprobación** aparece primero (*«Permitir que la venta tome tu efectivo»*), y luego la **Compra** en sí. 3. Cada paso encabezado por su botón y desplegando sus **precondiciones** y **consecuencias** debajo — a un clic antes de firmar — y nombra su fase a medida que se ejecuta — *«Esperando tu billetera…»*, luego *«Aterrizando en la cadena…»*. La secuencia vuelve a comprobar las condiciones entre pasos, de modo que una venta que se cierre después de tu aprobación detiene la compra en lugar de revertirla. 4. Si tiene éxito, el panel dice *«Comprado. Se mostrará en Posiciones.»* Desde **wallet de Solana** una **Permitir transferencias de wUSDC** secuencia puede ser más larga la primera vez. Si tu dirección del lado Rome tiene menos wUSDC del que necesita la compra, primero aparece un paso para mover efectivo desde tu billetera, y si el permiso de transferencia de wUSDC aún no está en su lugar, un **Permitir transferencias de wUSDC** paso [Pagar, y las solicitudes de firma adicionales](#paying-and-the-extra-signature-prompts). aparece antes de la aprobación. Después de pulsar Comprar, la billetera Solana ejecuta la entrada de efectivo, el permiso, la aprobación y la compra de una sola vez, y el botón indica «dos solicitudes de la billetera» mientras cada paso firma. Los nombres de los pasos y los conteos de solicitudes al principio se muestran en Trade y Credit, no aquí. Una billetera EVM también obtiene el único > **paso** La compra pasa por la misma puerta de allowlist que cualquier transferencia. *** ## Tus posiciones `/portfolio` muestra lo que tienes. Conecta la billetera que tiene el activo y obtienes: ![La página de posiciones — la tenencia, su valor y el resumen.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-adabd845843de879d366f0d21b03dfb87fc0573d%2Fpositions.png?alt=media) * un resumen — **Valor total** (en `wUSDC`), **Activos** (cuántos activos distintos tienes), y **Rendimiento recibido**; * un **Tenencias** tabla que enumera cada activo, tus unidades y su valor. Todo se lee en vivo de la cadena. Cuando aún no tienes nada, la página lo dice y te enlaza con las ventas abiertas. **Rendimiento recibido** actualmente muestra un guion: leer tu historial de pagos significa recorrer los eventos de distribución hasta el primer bloque del activo, lo cual es un trabajo que aún está por venir — un guion es honesto donde un `0.00` sería una afirmación. > **Las posiciones son una vista, no un mercado.** Bloom muestra la compra de un activo en su venta primaria y su tenencia. El propio activo permite transferencias a *otras direcciones permitidas* desde cualquiera de los dos mundos de billeteras (esa es una de sus reglas declaradas), pero Bloom actualmente no expone un control de transferencia o venta secundaria. *** ## Para un titular de Solana Todo lo anterior se aplica a ti sin cambios. Esta sección cubre la única sorpresa que realmente es tuya: **el activo se mantiene en una dirección que tu billetera Solana nunca listará**, y por qué eso es seguro. ### La cadena de custodia ![Las posiciones del titular de Solana — «Mantenido para tu clave de Solana», la dirección de tenencia derivada, la cadena de custodia y la tenencia ARCV comprada en la vía Solana.](https://1082203750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-b4f6ea043299e63183ceb7393e25b83948975218%2Fpositions-solana.png?alt=media) Cuando conectas una billetera Solana, `/portfolio` muestra una **Mantenido en** línea con la dirección EVM donde se encuentra tu activo, y un **¿Cómo se mantiene esto?** conmutador que abre un panel de custodia explicando la derivación en tres pasos: 1. **Tu clave de Solana** — la clave que ya está en tu billetera. Firma; nunca sale. 2. **Se calcula como — la dirección que contiene el activo** — la dirección EVM derivada. Es *aritmética, no una cuenta*: se deriva de tu clave, y no hay una clave privada para ella. 3. **Qué puede moverlo** — solo una firma de tu clave puede mover lo que está en esa dirección. > **Por qué esto es seguro.** El activo reside en el estado EVM: su saldo es almacenamiento dentro de las cuentas del programa Rome. Hay **ninguna acuñación SPL de él**, ninguna cuenta de token, y nada nativo de Solana que mover — así que la infraestructura del lado de Solana no tiene ninguna instrucción que pueda sacarlo. Solo tu firma de Solana puede impulsar la dirección derivada, y todo movimiento que pueda expresar es una llamada al contrato del activo, que ejecuta la compuerta de la lista de autorizados. Una transferencia a una dirección no permitida revierte de forma idéntica tanto si está firmada por una clave EVM como por una clave de Solana. Esta es exactamente la propiedad que quiere un activo con permisos — ver [LANES.md](/es/apps-en-rome/bloom/lanes.md#custody-why-the-rwa-stays-at-the-synthetic). Como no hay ningún token SPL que listar, **tu wallet de Solana no mostrará la posición en RWA** — la app Bloom es tu superficie de posiciones. Una clave de Solana perdida se recupera mediante el proceso del emisor, no moviendo el activo por fuera. ### Pagar, y las solicitudes de firma adicionales * **Pagas la comisión de Solana en SOL desde tu propia wallet.** La dirección EVM derivada nunca necesita SOL. Su gas solo se consume en el único caso descrito abajo, una llamada demasiado grande para una sola transacción. * **Cada llamada es una transacción de Solana versión 1, y cada llamada son dos confirmaciones.** Una aprobación, una compra o una transferencia son compuestas para tu wallet por el proxy de la cadena. Tu wallet primero firma un mensaje legible que comienza *autorización de Rome*, lo que demuestra que tu clave de Solana autoriza esta llamada exacta. Luego firma la propia transacción. Aprobar y luego comprar son, por lo tanto, cuatro confirmaciones. * **Una wallet que no puede firmar transacciones de versión 1 se detiene ahí.** Bloom falla de forma segura en vez de enviar un formato anterior. Usa Solflare en devnet por ahora; Phantom todavía no firma transacciones de versión 1. * **Mover efectivo hacia adentro es una confirmación, solo cuando hace falta.** Una compra gasta wUSDC desde tu dirección derivada, que no mantiene nada en reposo. Si tiene menos de lo que cuesta la compra, Bloom primero mueve la diferencia desde la cuenta de token USDC de tu propia wallet. En Trade y Credit este paso se llama *Transferir tu efectivo*; en la compra de Invest se ejecuta como parte de la compra después de pulsar Comprar. * **La autorización única es un paso aparte, una vez por wallet.** La primera vez que tu dirección derivada gasta wUSDC, Bloom coloca **Permitir transferencias de wUSDC** antes de la aprobación. Es una llamada como cualquier otra (dos confirmaciones), y no se vuelve a pedir una vez que está en su sitio. La razón de su existencia está en [Concesión única por wallet](/es/conceptos-basicos/token-interop.md#one-time-grant-per-wallet). * **Una llamada demasiado grande para una sola transacción de Solana se retransmite, con menos confirmaciones.** Bloom siempre intenta primero la transacción directa, firmada por la wallet. Si la cadena la rechaza porque no cabe, la misma firma de autorización se entrega al proxy, que la envía por ti: una confirmación para esa llamada. Como el proxy la envía, la llamada se paga en gas de Rome desde tu dirección derivada, así que si ese saldo es insuficiente Bloom primero lo recarga desde tu wallet, lo que supone una confirmación más, normalmente una vez por wallet. Ver [LANES.md](/es/apps-en-rome/bloom/lanes.md#calls-too-large-for-one-transaction). Una primera compra desde una wallet nueva de Solana es por tanto: mover efectivo hacia adentro (1 confirmación), permitir transferencias de wUSDC (2), aprobar la venta (2), comprar (2). > **Las acciones más grandes se retransmiten, no se rechazan.** Una compra cabe en una transacción de Solana, y un «viaje de varios pasos» (aprobar y luego comprar) son varias transacciones completas, cada una atómica por sí sola. Solo una llamada que el proxy informa como demasiado grande para una sola transacción, que en Credit puede incluir las acciones de mercado más grandes, toma la ruta de retransmisión descrita arriba. *** ## Dónde está realmente el cumplimiento Para resumir qué se aplica y dónde, para que nada de esto se confunda con una política de Bloom: | Preocupación | Aplicado por | No por | | --------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------- | | Quién puede poseer el activo | El módulo de lista de autorizados del activo, en cada transferencia | Este sitio web | | Una transferencia a una dirección no aprobada | Revertida en la cadena por el activo | Cualquier filtro fuera de la cadena | | Qué se almacena sobre ti | Un booleano (`isWhitelisted`) por dirección | Documentos o información personal identificable, en cualquier lugar | | Quién puede admitirte | La decisión fuera de la cadena del emisor | Bloom | Para el modelo completo, lee [COMPLIANCE.md](/es/apps-en-rome/bloom/compliance.md); para la mecánica de dos carriles, [LANES.md](/es/apps-en-rome/bloom/lanes.md). > **Esto no es una maqueta.** Un comprador real compró este activo desde una wallet EVM, y una wallet real de Solana lo compró en el carril de Solana — el mismo token, la misma lista de autorizados, el mismo wUSDC. Cada transacción está enlazada en la página [Prueba](/es/apps-en-rome/bloom/evidence-investor.md) . La tarjeta Permitted, las posiciones y la cadena de custodia de Solana en esta guía son de esos compradores, después de esas transacciones. --- # 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/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.