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

# Los dos carriles

Un despliegue de un token, dos mundos de billeteras. Ambos carriles ejecutan el **mismos contratos** con la **misma puerta de cumplimiento** — solo difieren en quién firma y cómo la transacción llega a la cadena.

## Carril EVM

Herramientas estándar de Ethereum, sin cambios: la billetera firma una transacción EVM, el endpoint JSON-RPC de la cadena la acepta, y el contrato del token impone la allowlist. No hay nada específico de Bloom que integrar.

El gas de Rome está denominado en USDC, y una escritura cuesta más que su equivalente en Ethereum siempre que tenga que crear cuentas de Solana (un titular por primera vez, una nueva cuenta de token). Usa `eth_estimateGas`, como hacen las herramientas estándar, y nunca codifiques 21.000; la estimación incluye la creación de la cuenta, y Rome cobra el gas realmente usado. Una transferencia con restricción también paga la comprobación de la allowlist, así que cuesta más que una transferencia simple del mismo tamaño.

## vía Solana

Una billetera de Solana impulsa los mismos contratos EVM **de forma nativa — no existe ninguna clave EVM en ningún sitio**. Cada llamada es una transacción v1 de Solana que el proxy de la cadena compone para que la billetera la firme. No hay tablas de búsqueda de direcciones ni instrucciones de presupuesto de cómputo que construir: el proxy fija por sí mismo el presupuesto de cómputo y de heap.

1. **Identidad.** La dirección del usuario en el lado EVM es *sintética*: derivada determinísticamente como `keccak256(solana_pubkey)[12..32]`. El programa EVM de Rome la deriva on-chain a partir del firmante real de la transacción — no se puede suplantar, y no existe para ella ninguna clave privada secp256k1, así que **la firma de Solana es lo único que puede activar esta dirección**.
2. **Autorizar.** La app construye la llamada como un payload EIP-1559 sin firmar, usando el nonce, el precio del gas y la estimación de gas que lee de la cadena. La billetera firma un mensaje legible — se muestra como *autorización de Rome* seguido de un hash de la llamada — lo que prueba que la clave de Solana autoriza este payload EVM exacto. Este es el primer aviso, y el proxy no compondrá la llamada sin él.
3. **Componer.** La app envía el payload y esa firma al proxy. El proxy verifica la firma, emula la llamada para encontrar qué cuentas de Solana toca y cuáles son escribibles, y devuelve una sola transacción v1 de Solana. La app verifica el mensaje devuelto antes de pedirle a la billetera que lo firme.
4. **Firmar y enviar.** La billetera firma la transacción ella misma: el segundo aviso, una firma distinta sobre una cadena de bytes distinta. La app envía la transacción firmada directamente a un RPC de Solana; el usuario paga la comisión de Solana en SOL desde su propia billetera.
5. **Confirmar.** La transacción se confirma en Solana; la vista EVM se pone al día un momento después, así que la app espera a que el nonce de la dirección sintética cambie antes de enviar la siguiente llamada.

**La billetera tiene que firmar transacciones v1 de Solana.** El carril falla de forma cerrada sin eso: una billetera que no puede firmar una transacción v1 detiene la llamada con un error, y la app nunca recurre a un formato de transacción anterior. Solflare firma v1 en devnet hoy; Phantom todavía no.

### Antes de la llamada: efectivo y la concesión única

Dos cosas pueden ocurrir antes de una llamada del carril de Solana, y cada una aparece como su propio paso con sus propios avisos:

* **Moviendo efectivo.** Una llamada que gasta wUSDC lo extrae de la dirección sintética, que no mantiene nada en reposo. Si la sintética tiene menos de lo que la llamada necesita, la app primero mueve la diferencia desde la propia cuenta de token USDC de la billetera a la de la sintética. Esta es una sola transacción de Solana firmada con un aviso, no una llamada EVM: una creación idempotente de la cuenta de token de la sintética, seguida de la instrucción activate-token-account del programa Rome, que mueve los tokens sin ejecutar el EVM. Se omite cuando la sintética ya tiene suficiente.
* **La concesión única del wrapper.** wUSDC es el wrapper de un token SPL, y un wrapper mueve los tokens de un usuario como delegado SPL de ese usuario. La primera vez que la dirección sintética de una billetera gasta wUSDC, la concesión aún no está en su lugar, y la app pone un **Permitir transferencias de wUSDC** paso por delante del resto. Es una llamada como cualquier otra (dos avisos), una vez por billetera. Véase [Concesión única por wallet](/es/conceptos-basicos/token-interop.md#one-time-grant-per-wallet).

Por tanto, una compra desde una billetera nueva de Solana es una secuencia corta: mover efectivo, permitir transferencias wUSDC, aprobar el escaparate, comprar.

### Llamadas demasiado grandes para una sola transacción

Una transacción atómica de Solana tiene límites fijos: unos 1,4M de unidades de cómputo, 64 cuentas y 4 KB en la red (véase [Restricciones](/es/conceptos-basicos/constraints.md)). Bloom siempre intenta primero la transacción directa firmada por la billetera. Solo cuando el proxy rechaza la llamada porque no cabe en una sola transacción la app la entrega al proxy para **reenviar**, y nunca antes:

* **Un aviso para esa llamada.** El reenvío reutiliza el mensaje de autorización que la billetera ya firmó para el intento rechazado, así que no hay un segundo aviso idéntico ni una transacción que firmar. El proxy compone la llamada, la envía a Solana (en tantas transacciones como necesite) y paga él mismo las comisiones de Solana.
* **El gas de Rome sale del saldo de la sintética.** Una llamada reenviada se paga en el gas nativo de la cadena, en wei, desde la dirección sintética. Si ese saldo no alcanza para cubrir el coste de la llamada, la app primero lo recarga desde la billetera, en unidades completas de 10^12 wei: un aviso más, normalmente una vez por billetera, igual que la concesión.
* **El hash es un hash de transacción de Rome.** El resultado de una llamada reenviada es el hash de transacción EVM del proxy, no una firma de Solana, así que no se abrirá en un explorador de Solana; búscalo en el explorador propio de la cadena.

El reenvío se aplica a cualquier llamada que el proxy informe como demasiado grande para una sola transacción, lo que en Credit puede incluir las acciones de mercado más grandes. La mayoría de las llamadas, incluida una transferencia simple y una aprobación, caben en una sola transacción y nunca toman esta ruta. La mecánica de las llamadas reenviadas y sus límites está en [Llamadas reenviadas y llamadas largas](/es/guias-para-desarrolladores/call-evm-from-solana.md#relayed-calls-and-long-calls).

### Avisos por paso

| Paso                                                                        | Avisos de la billetera                                       |
| --------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Mover efectivo (solo si falta)                                              | 1                                                            |
| Permitir transferencias wUSDC (una vez por billetera)                       | 2                                                            |
| Una llamada que cabe en una sola transacción (aprobar, comprar, transferir) | 2: el mensaje de autorización, luego la transacción          |
| Una llamada que tiene que ser reenviada                                     | 1, más 1 para la recarga única de gas si el saldo no alcanza |

En la página del activo Invest, una billetera de Solana pasa por la entrada de efectivo, la concesión, la aprobación y la compra en una sola ejecución tras pulsar Buy, y el botón indica "dos avisos de la billetera" mientras cada paso firma. Los pasos nombrados ("Transfiriendo tu efectivo") y los conteos de avisos por adelantado se muestran en Trade y Credit. Una billetera EVM también recibe un paso único *Permitir transferencias de wUSDC* en el panel de compra.

### Cómputo medido, desde el carril anterior

Antes del cambio a transacciones v1, el carril construía su propia transacción y midió estas cifras en Rome devnet, rangos observados en dos cadenas. No se han vuelto a medir en la transacción v1 que el proxy compone ahora, así que léelas como un orden de magnitud, no como un presupuesto:

| Flujo del carril de Solana                                                      | CU         |
| ------------------------------------------------------------------------------- | ---------- |
| Transferencia de RWA con restricción                                            | \~339–381K |
| Aprobación wUSDC                                                                | \~189–191K |
| Compra en escaparate (aprobar + comprar, dos transacciones)                     | \~730–796K |
| Barrido de la pata de efectivo a la propia cuenta de token de la billetera      | \~42–54K   |
| Transferencia simple de valor                                                   | \~47K      |
| `TestApprover.approve` — admisión en la allowlist, **firmada por la billetera** | 220,794    |

El límite de cómputo por transacción de Solana es de 1,4M CU. Mide tu propia llamada a partir de `meta.computeUnitsConsumed` (`getTransaction` en un RPC de Solana; el recibo EVM de la cadena no tiene ese campo) en lugar de asumir uno de estos.

## Custodia: por qué el RWA permanece en la sintética

La pregunta de diseño que todo activo con permisos debe responder: *¿puede el token escapar del perímetro de cumplimiento?* En el carril de Solana la respuesta es estructural, no de política:

* **El RWA reside en el estado EVM.** Sus saldos son almacenamiento dentro de las cuentas del programa EVM de Rome. No hay **ningún mint SPL** de ello, ninguna representación de cuenta de token, nada nativo de Solana que mover. (Esto es deliberado — una versión envuelta/reflejada sería la puerta de escape.)
* **La infraestructura del lado de Solana no puede tocarlo.** Las patas de movimiento de activos del carril (`create_ata`, transferencias SPL, barridos) operan sobre cuentas de token SPL; los saldos de almacenamiento EVM no tienen tal cuenta. No hay ninguna instrucción que mueva un saldo EVM a una cuenta de token de Solana.
* **Solo la firma de Solana del propietario impulsa la sintética**, y cada movimiento que puede expresar es una llamada al contrato del token — que ejecuta la puerta de la allowlist — así que una transferencia a una dirección no permitida revierte de forma idéntica tanto si la firma una clave EVM como una clave de Solana.
* **La pata del efectivo es la excepción deliberada.** wUSDC (rendimientos, producto de ventas) está respaldado por SPL y *debería* hacer ida y vuelta: la pata de salida (`transfer_spl`) lo mueve de la sintética a la cuenta de token asociada propia de la billetera, verificada de extremo a extremo. El activo permanece en el perímetro; el efectivo fluye libremente.

Dos consecuencias prácticas, expresadas claramente: la interfaz de billetera de Solana no mostrará la tenencia de RWA (no hay ningún token SPL que listar) — la app Bloom es la superficie de posiciones; y una clave de Solana perdida se recupera mediante el proceso del emisor ([COMPLIANCE.md](/es/apps-en-rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), no moviendo el activo fuera de banda — que es exactamente la propiedad que quiere un activo con permisos.


---

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