> 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/guias-para-desarrolladores/from-home.md). # Desde casa: accede a Rome desde otra cadena Permite que usuarios de otra cadena lleguen a tu aplicación Rome sin salir de casa: introduce activos, actúa y retíralos de nuevo. Tus usuarios no tienen que mudarse a Rome. Desde su cadena de origen — una L2 como Arbitrum o Monad, o Solana — traen activos, usan tu app de Rome y luego vuelven a sacar los activos. El puente está en cadena y autorizado por la propia firma del usuario; conectas tu app a él mediante una sola API. ## Cómo funciona * **Entrante (cadena de origen → Rome):** en la ruta del token de gas USDC sobre CCTP, la `settle_inbound_bridge_v2` instrucción del programa de Rome acredita al usuario, bajo una **EIP-712** `SettleAuthorization`, así que no hay un liquidador privilegiado. Las otras rutas entrantes no usan esa instrucción ni esa firma. El USDC envuelto, ETH sobre Wormhole y SOL llegan directamente como el token envuelto en la cuenta del usuario. El USDC de Solana en una cadena cuyo token de gas es USDC necesita una transacción más, firmada por el usuario, para convertir el envoltorio en gas nativo. La cotización te dice qué firmas necesita una ruta. * **Saliente (Rome → cadena de origen):** `RomeBridgeWithdraw` (en [`rome-solidity`](https://github.com/rome-protocol/rome-solidity)) quema el activo en Rome. Luego el usuario lo reclama en la cadena de origen con su propia transacción. * **Transporte:** Circle **CCTP** para USDC y el **Wormhole** puente de tokens para ETH. Las cadenas de origen de Solana usan transferencias SPL simples de entrada y una retirada de Rome de salida. Wormhole es la vía entrante solo para ETH. Existe una ruta genérica de Wormhole solo para salidas, y cada activo en ella debe ser habilitado primero por los operadores de Rome. * **Orquestación:** el [`rome-bridge-api`](https://github.com/rome-protocol/rome-bridge-api) fuera de la cadena cotiza una ruta, verifica la transacción de la cadena de origen y patrocina la comisión de liquidación. No guarda fondos ni claves. Solo puede activar lo que el usuario ya firmó. ## Constrúyelo La API es pública en devnet en `https://bridge-api.devnet.romeprotocol.xyz`. `GET /v1/routes` enumera todas las rutas activas (activo, vía, dirección, cadena de origen, cadena de Rome, velocidades). Las llamadas siguientes son las mismas cuatro que el SDK envuelve en `@rome-protocol/sdk/bridge` (`requestQuote`, `registerTransfer`, `getTransfer`, `reportStep`). La CLI ejecuta todo el flujo por ti: `rome fund` y `rome bridge` para las transferencias y `rome verify --path from-home` para un viaje de ida y vuelta, como se describe en la [CLI de Rome](/es/productos/rome-cli.md) página. ### Trae activos 1. **Cotiza la ruta.** Envía la cadena de origen del usuario, el activo, el importe y las direcciones. Las cadenas se envían como ids CAIP-2, como `eip155:84532`; `romeChainId` es tu cadena de Rome. Los nombres antiguos `ethereum` y `solana` todavía se aceptan, pero están obsoletos, y la API marca esas respuestas con un encabezado `Sunset` La estructura completa de la solicitud y la respuesta está en la [referencia de la API](https://github.com/rome-protocol/rome-bridge-api/blob/main/docs/API.md). ```bash curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \ -H 'Content-Type: application/json' \ -d '{ "asset": "USDC", "direction": "to-rome", "sourceChain": "eip155:84532", "romeChainId": "200010", "amount": "1000000", "sender": { "ethereum": "0xUSER" }, "recipient": "0xUSER" }' ``` Los importes son enteros de unidades base en cadenas (`"1000000"` es 1 USDC). Los importes de ETH están en wei y, al salir, deben ser múltiplos de 10,000,000,000 wei (el envoltorio tiene 8 decimales); la API rechaza cualquier valor más fino. La respuesta enumera los `pasos`. El usuario firma las transacciones de cada paso marcado con `userSigns: true`, en orden de pasos: las transacciones EVM están en `unsignedTxs`, las instrucciones de Solana en `unsignedTx`. Fírmalas exactamente como se devuelven. Los pasos sin nada que firmar los realiza el patrocinador una vez que Circle o Wormhole han atestiguado la transferencia. La reclamación saliente es la excepción, descrita abajo: la construye el usuario. 2. **Haz que el usuario firme.** Para una cotización CCTP, eso es la aprobación de USDC y la quema en la cadena de origen. Si la cotización tiene una entrada en `signatureRequests`, el usuario también firma esa `SettleAuthorization` EIP-712 `una vez que se conoce el hash de la quema; rellena el hash de la quema y pasa el resultado como` userSettleSig 3. **Registra la transferencia.** `POST /v1/transfers` con la cotización completa y `step1TxHash`, el hash de la última transacción en el primer paso (la quema). La API comprueba que la transacción en la cadena de origen coincida con la cotización y devuelve un `id`. 4. **Consulta** `GET /v1/transfers/{id}` cada pocos segundos hasta que `resultado` es `complete`. Entonces el usuario recibe fondos en Rome y puede usar tu app. Las cadenas de origen de Solana siguen la misma forma con pasos diferentes. El usuario envía una transferencia SPL a la cuenta de tokens de su cuenta de Rome. SOL llega como wSOL después de esa única transferencia. En una cadena cuyo token de gas es USDC, como Hadrian, USDC necesita un segundo paso: una transacción de Rome que el usuario firma y que convierte el envoltorio llegado en gas nativo. Cualquier otro token SPL pasa por la `spl-solana-to-rome` ruta, que toma el mint en `splAsset`. ### Sacar activos de nuevo La salida de fondos no es el flujo de entrada ejecutado al revés. Tiene más de una firma, y el usuario la completa en la cadena de origen. Cotízala con `direction` establecido en `from-rome`. `sourceChain` nombra el lado no Rome y `destinationChainId` elige la cadena en la que el usuario reclama. Pasa ambos: `destinationChainId` es lo que decide la cadena de reclamación, y una cotización sin él por defecto usa Ethereum Sepolia whatever `sourceChain` dice: ```bash curl -X POST https://bridge-api.devnet.romeprotocol.xyz/v1/quote \ -H 'Content-Type: application/json' \ -d '{ "asset": "USDC", "direction": "from-rome", "sourceChain": "eip155:84532", "destinationChainId": 84532, "romeChainId": "200010", "amount": "1000000", "sender": { "rome": "0xUSER" }, "recipient": "0xUSER" }' ``` Para USDC sobre CCTP la cotización devuelve dos pasos, y el usuario firma ambos: 1. **En Rome, dos transacciones en orden.** La primera concede `RomeBridgeWithdraw` derechos de delegado sobre el wUSDC del usuario en Solana (`approve_spl`). La concesión cubre exactamente el importe de esta quema, así que la cotización la incluye siempre y el usuario la firma antes de cada quema. La segunda quema el wUSDC mediante `RomeBridgeWithdraw`, lo que inicia la transferencia CCTP. Registra la transferencia con el hash de la quema. La quema gasta wUSDC, el token que la cotización nombra como `burnToken`, no el USDC nativo de gas. Los fondos que entraron como gas no son lo que se quema, así que para un viaje de ida y vuelta trae USDC con `intent: "wrapper"`. 2. **En la cadena de destino, la reclamación.** Consulta `GET /v1/transfers/{id}` hasta que el paso 2 esté `listo`. Entonces lleva la `message` y `attestation`. El usuario llama a `receiveMessage(message, attestation)` en el transmisor de mensajes de Circle en la cadena de destino (la cotización nombra al transmisor y el dominio CCTP). Aquí no se patrocina nada, así que el usuario necesita gas en esa cadena. Reporta el hash de la reclamación con `POST /v1/transfers/{id}/steps/2`. ETH sobre Wormhole tiene la misma forma. El usuario concede los mismos derechos de delegado sobre wETH, quema wETH en Rome y espera a que los guardianes de Wormhole firmen. Luego el usuario canjea en Ethereum con su propia transacción: `completeTransferAndUnwrapETH` en el puente de tokens que la cotización nombra (`claimTokenBridge`), usando el mensaje firmado (`vaa`) del paso 2. Retirar a una dirección de Solana no tiene paso de reclamación. USDC es una sola transacción de Rome que retira a la cuenta de Solana del usuario. SOL es un paso de Rome con tres transacciones: la misma concesión de delegado sobre wSOL, la creación opcional de la cuenta de token wSOL del destinatario en Solana (se omite cuando ya existe) y la retirada mediante `RomeBridgeWithdraw`. **La primera transferencia saliente necesita una cuenta activada.** Una quema CCTP crea una cuenta de mensaje en Solana, y la cuenta del usuario en Rome tiene que tener suficientes lamports para pagarla. Una billetera nueva no los tiene, así que la primera transferencia saliente falla hasta que el usuario la active una vez. La comprobación es que la cuenta tenga al menos 15,000,000 lamports. Léelos con `account_lamports(bytes32)` en el precompilado CPI en `0xff00000000000000000000000000000000000008`, pasando la cuenta de autenticación externa del usuario en Solana (la CLI hace esta lectura por ti). La activación llama a `activate()` en el `SimpleActivator` contrato listado en el [registro](https://github.com/rome-protocol/rome-registry) para tu cadena, y la llamada lleva un pago en el token de gas de la cadena. En Hadrian eso son 2 USDC. La CLI hace esto con `rome activate `y `rome bridge --to` se detiene y te dice que lo ejecutes si la cuenta no está lista. La reserva cubre una quema, y el alquiler regresa después de que Circle atestigua la quema, lo que tarda unos 30 minutos. Una segunda quema antes de eso, o una cuenta que se haya vaciado desde que fue activada, necesita `topUpUserPda(lamports)` en el mismo contrato, porque `activate()` revierte una vez que la cuenta ha sido activada. `rome activate` elige la llamada correcta. Las transferencias entrantes no necesitan activación. La cotización no incluye la activación como un paso, así que tu app tiene que comprobar la cuenta y ofrecerla antes de la primera cotización saliente. ## Lee el código * [appia](https://github.com/rome-protocol/appia) — una app de cadena de origen: los usuarios traen USDC desde su cadena de origen y usan DeFi del lado de Rome sin salir de ella. * [rome-bridge-api](https://github.com/rome-protocol/rome-bridge-api) — el orquestador (cotizar → verificar → patrocinar). ## Qué sigue * [Obtener financiación](/es/recursos/faucets.md) — la misma ruta de puente financia una billetera de dev recién creada. * [Desplegar Solidity](/es/guias-para-desarrolladores/deploy-solidity.md) — coloca tu app en Rome. --- # 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/guias-para-desarrolladores/from-home.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.