> 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/open-to-solana-users.md).

# Abre tu contrato a usuarios de Solana

Despliega un contrato Solidity en Rome (testnet Hadrian, mainnet Rubicon) y ábrelo a carteras de Solana: lo que necesita el contrato, cómo lo llama un usuario con cartera de Solana, direcciones por red y un lanza

Un despliegue, dos tipos de usuarios. Un contrato en Rome es alcanzado por usuarios de MetaMask con su clave EVM y por usuarios de billetera de Solana (Solflare, por ejemplo) con su clave de Solana — la misma dirección, el mismo estado. Esta página es el recorrido de extremo a extremo: desplegar, dejar el contrato listo para Solana, cablear la vía de Solana en tu app y lanzarlo en mainnet.

## 1. Despliega en la red que quieras

Las cadenas Rome son destinos EVM estándar: Hardhat, Foundry, viem y ethers funcionan sin cambios (recorrido completo en [Deploy Solidity Contracts](/es/guias-para-desarrolladores/deploy-solidity.md)).

| Red                                           | ID de cadena | RPC                                         | Explorador                                                                            | Token de gas   | Cómo obtener gas                                                                                                                                                                            |
| --------------------------------------------- | ------------ | ------------------------------------------- | ------------------------------------------------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [**Rubicon**](/es/redes/rubicon.md) (mainnet) | `7531`       | `https://rubicon.mainnet.romeprotocol.xyz/` | [via-rubicon.mainnet.romeprotocol.xyz](https://via-rubicon.mainnet.romeprotocol.xyz/) | USDC           | Puentea USDC desde Ethereum (CCTP) o desde Solana con el [Rome Bridge](https://bridge-api.mainnet.romeprotocol.xyz/); llega como gas                                                        |
| **Hadrian** (testnet)                         | `200010`     | `https://hadrian.testnet.romeprotocol.xyz/` | [via-hadrian.testnet.romeprotocol.xyz](https://via-hadrian.testnet.romeprotocol.xyz/) | USDC de prueba | Puentea USDC de prueba desde una testnet ([Faucets](/es/recursos/faucets.md)) o envuélvelo desde una billetera de devnet de Solana en la [App de Rome](https://app.devnet.romeprotocol.xyz) |

El gas es USDC con 18 decimales en el lado EVM; no existe un faucet de Rome en ninguna red. Las escrituras cuestan más gas de lo que sugiere la intuición de Ethereum, porque la mayor parte del costo es crear cuentas de Solana: un destinatario nunca usado, una nueva cuenta de token, un contrato desplegado. Usa `eth_estimateGas`, que es lo que hace la instrumentación estándar, y nunca codifiques 21.000. Medido en Hadrian, desplegar un contrato de 10 bytes estimó y usó 1.147.921 gas, y una transferencia nativa a una dirección nunca usada 1.086.961, frente a 21.000 para una transferencia a una dirección existente. Rome cobra el gas realmente usado, que en estas mediciones nunca fue mayor que la estimación. Financia unos pocos USDC antes de un primer despliegue. Verifica el código fuente en el explorador después ([Verificar contratos](/es/guias-para-desarrolladores/verify-contracts.md); el verificador de mainnet es `https://verify.mainnet.romeprotocol.xyz`).

Desarrolla en Hadrian y luego vuelve a desplegar los mismos artefactos en Rubicon con el chain id y las direcciones del wrapper de mainnet intercambiados; nada en el contrato cambia entre redes. Rubicon no está en el registro público, `create-rome-app` o `rome-cli` todavía, así que las herramientas que leen los valores de la cadena desde él no pueden apuntarlo; rellena los valores a mano desde [Rubicon](/es/redes/rubicon.md). El gas en Rubicon es USDC real a aproximadamente diez veces el precio del gas de Hadrian, así que allí un despliegue cuesta dinero real.

## 2. Qué hace que un contrato esté listo para Solana

La identidad EVM de un usuario de Solana es su **dirección sintética**, `keccak256(solana_pubkey)[12:]`: una dirección ordinaria `msg.sender`, con un nonce ordinario. La mayoría de los contratos no necesita ningún cambio. Las tres cosas que importan:

* **Toma el valor como ERC-20, no `msg.value`.** Los fondos de un usuario de Solana son tokens SPL en su billetera, vistos en el lado EVM como el wrapper del token (`wUSDC`, `wETH`, `wSOL`). El sintético no retiene nada en reposo y los activos del usuario llegan como el wrapper, así que extrae con `transferFrom` después de un `approve` y devuelve con `transfer`.[Una sola vez: concede al wrapper](/es/guias-para-desarrolladores/dual-lane-app.md#one-time-grant-the-wrapper)). `payable` Un punto de entrada solo funciona una vez que al sintético se le ha dado gas nativo (el de la ruta de relé `rome_composeExternalDepositV1`). Un vault ERC-20 existente, un AMM o un mercado de préstamo ya tiene la forma correcta.
* **Usa los wrappers canónicos.** Cada cadena tiene un wrapper por mint; las direcciones están en [Contract Addresses](/es/referencia/contract-addresses.md) (el de Hadrian también está en el público [registro](https://github.com/rome-protocol/rome-registry)). Apunta los constructores a esas direcciones; no despliegues el tuyo propio.
* **Ajusta el presupuesto atómico donde firma una billetera.** Una billetera de Solana firma una transacción de Solana, así que una llamada por la vía de Solana debe ajustarse a eso: alrededor de 1,4M unidades de cómputo, 64 cuentas, 4 KB ([Restricciones](/es/conceptos-basicos/constraints.md)). Medido en Hadrian: una transferencia, una aprobación y un suministro de Aave encajan; un swap de Uniswap V3 encaja con poco margen (alrededor de 1,24M CU); un préstamo de Aave no encaja y toma la ruta de relé en la siguiente sección. Mide con el recibo de Solana, solicitando la transacción con `computeUnitsConsumed`maxSupportedTransactionVersion: 1 `maxSupportedTransactionVersion: 1` (las etapas de Rome son transacciones v1; sin eso el campo lee 0).

Lo que no necesitas: un programa de Solana, un puente, un segundo despliegue ni ninguna Solidity específica de Rome. Si el contrato también llama a programas de Solana a través de los precompiles, consulta [Llamar a Solana desde EVM](/es/guias-para-desarrolladores/call-solana-from-evm.md).

## 3. Deja que una billetera de Solana lo llame

La ruta EVM de tu app no cambia (MetaMask + `submitRomeTx`, o viem/ethers sin formato). Para la ruta de Solana hay dos formas.

**La vía del SDK — una transacción Solana v1 por llamada.** [`@rome-protocol/sdk`](https://github.com/rome-protocol/rome-sdk-ts) (`submitRomeTxV1`) hace que el proxy componga una transacción Solana v1 para tu llamada EVM (hasta 64 cuentas y 4 KB, sin tabla de búsqueda de direcciones; no hay instrucción ComputeBudget, billetera de tesoro ni descubrimiento de cuentas en tu código). La billetera firma dos veces con la misma clave: primero un mensaje de autorización legible (`autorización de Rome` en una línea, `0x` y el hash de la transacción EVM en la siguiente), que la cadena verifica mediante el programa Ed25519, luego la transacción. La app envía la transacción firmada al RPC de Solana; la llamada devuelve el hash de la transacción EVM y su recibo. Antes de que la billetera firme la transacción, el SDK la comprueba: el pagador es el único firmante, solo se ejecutan el programa Rome y el verificador Ed25519, la instrucción Rome lleva exactamente la llamada que el usuario autorizó y no hay comisión de prioridad. Se rechaza cualquier otra cosa.

Si una llamada no cabe en una transacción, el composer la rechaza y el SDK la entrega al proxy para retransmitirla, con la misma firma de autorización, así el usuario sigue viendo un único aviso de autorización. El resultado entonces tiene `route: "relay"`Las reglas para las llamadas relé y las llamadas largas están en [Llamadas reenviadas y llamadas largas](/es/guias-para-desarrolladores/call-evm-from-solana.md#relayed-calls-and-long-calls). `fundSyntheticGas(deps, amountWei)` mueve el token de gas de la cadena (USDC en Hadrian y Rubicon) desde la cuenta de tokens de la billetera hacia él, en una transacción v1 firmada por la billetera.

La pierna de fondeo (`buildFundLeg`) y la creación de la cuenta de tokens de la billetera antes de un sweep son instrucciones Solana normales; `submitSolanaInstructionsV1` también las envía como transacciones v1, firmadas por el mismo firmante de la billetera, sin que intervenga el proxy. La propia llamada del sweep (`buildSweepLeg`, `HelperProgram.transfer_spl`) pasa por `submitRomeTxV1` como cualquier otra, y el proxy encuentra las cuentas de tokens. `submitRomeTxV1` no crea por sí sola la cuenta de un nuevo sintético: antes de la primera llamada que mueva valor, comprueba `isSyntheticProvisioned(...)` y, si es falso, envía `buildCreatePdaCall(synthetic)` a través de `submitRomeTxV1` una vez. Un recorrido completo de depósito y retiro con código está en [Construir una app de doble carril](/es/guias-para-desarrolladores/dual-lane-app.md); la mecánica está en [Llamar a EVM desde Solana](/es/guias-para-desarrolladores/call-evm-from-solana.md). El anterior `submitRomeTxSolanaLane`, que construye una transacción Solana heredada en el cliente, sigue estando en el SDK como la ruta antigua.

**De dónde proviene cada `deps` valor.** El `deps` del SDK tiene cinco campos obligatorios (el resto, como `fetchImpl` y los timeouts, son opcionales). Cuatro vienen de la cadena y uno de la billetera:

| `deps` campo | De dónde viene                                                                                                                   | Getter del registro (`@rome-protocol/registry` v0.2.0)                                                  |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `proxyUrl`   | la URL RPC de la cadena                                                                                                          | `getChain(chainId).rpcUrl`                                                                              |
| `chainId`    | el ID de la cadena                                                                                                               | `getChain(chainId).chainId`                                                                             |
| `programId`  | el ID del programa Rome en el que corre la cadena                                                                                | `getChain(chainId).romeEvmProgramId`                                                                    |
| `connection` | un RPC de Solana para el clúster de la cadena, donde se envía la transacción firmada (devnet para Hadrian, mainnet para Rubicon) | `getChain(chainId).solana.rpc` (una URL pública de devnet para Hadrian); para mainnet usa un RPC propio |
| `signer`     | el `LaneSigner`, o una `Keypair` en scripts                                                                                      | ninguno                                                                                                 |

Los constructores de las etapas toman valores que no están en `deps`. Su `mint` (llamado `usdcMint` en el recorrido) es el mint de Solana del token de gas, de `getTokens(chainId)` (la entrada con `kind: "gas"`, campo `mintId`). La dirección del wrapper wUSDC no es una entrada del constructor de etapas; la usas para las llamadas ERC-20 y es la entrada con `kind: "spl_wrapper"` y símbolo `wUSDC` (campo `address`). El registro cubre Hadrian. Para Rubicon, complétalos a mano: `proxyUrl` `https://rubicon.mainnet.romeprotocol.xyz/`, `chainId` `7531`, `programId` `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX`, `mint` `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v`, el wrapper de la tabla en la sección siguiente, y un RPC de mainnet de Solana para `connection`. [Rubicon](/es/redes/rubicon.md) tiene la lista completa.

**Los endpoints externos V1 del proxy — la misma vía sin el SDK.** El SDK envuelve la composición atómica, el relé y el depósito de gas (`fundSyntheticGas`). Los métodos RPC en bruto siguen ahí para clientes que no usan el SDK, e incluyen la composición iterativa, que el SDK no envuelve. La billetera firma un mensaje Ed25519 sobre la llamada (la forma legible `Autorización de Rome\n0x<hash>` o el hash en bruto), y el proxy o bien compone la(s) transacción(es) Solana para que la billetera las firme (`rome_composeUnsignedAtomicV1`, `rome_composeUnsignedIterativeV1` + `rome_submitSignedV1Plan`) o ejecuta toda la ejecución por sí mismo con una sola firma de billetera (`rome_relayUnsignedV1`, después de un `rome_composeExternalDepositV1` (el del SDK `fundSyntheticGas`) que financia el saldo de gas del sintético; las llamadas relé gastan de él, así que recárgalo cuando se agote). Formas de método en [Soporte de JSON-RPC](/es/referencia/json-rpc.md); las reglas de autorización en [Llamar a EVM desde Solana](/es/guias-para-desarrolladores/call-evm-from-solana.md#the-external-v1-endpoints). Usa el relé para cualquier cosa iterativa, y la vía del SDK para todo lo que encaje.

En cualquier caso el contrato ve una transacción normal desde la dirección sintética y el usuario nunca tiene una clave EVM.

## 4. Direcciones de wrapper por red

| Red              | `wUSDC` wrapper                              | Otros wrappers                                                                                           |
| ---------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Rubicon (7531)   | `0x0952d233b0c254cd375f3bfb3e5869c1a906f9b3` | `wETH` `0x01e8b3573da1d4b7b4b1ce0932cf07c8af0c92e9`, `wSOL` `0xc4e29e0f726a906e93277cbbc37bf27a9848a113` |
| Hadrian (200010) | `0xbce339ba4c3a8de3bb8af1c5539e6ac11da3112d` | `wETH` `0x02aeace038269f9961c93d04dcacd6fb3adfa55f`, `wSOL` `0x39f36444fcb79b3e691544aee2a832ebef54ca9f` |

El token de gas nativo aparece como `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` en las listas de tokens; no es un contrato ERC-20. Los wrappers llevan los decimales del mint SPL, no 18: wUSDC 6, wETH 8, wSOL 9.

## 5. Lista de verificación de lanzamiento

1. Desplegado en Hadrian; la ruta EVM funciona desde MetaMask.
2. Cada punto de entrada que mueve valor se basa en ERC-20 y apunta al wrapper canónico de la cadena.
3. Una billetera de Solana que firma transacciones v1 (Solflare lo hace hoy en devnet; Phantom aún no) completa el viaje de ida y vuelta completo en Hadrian: provisionar el sintético (`create_pda`, una vez) → pierna de fondeo → conceder → aprobar → llamar → pierna de sweep, usando la vía del SDK; o la ruta de relé si la llamada es iterativa.
4. El `computeUnitsConsumed` de cada llamada por la vía de Solana
5. se lee del recibo de Solana y queda bajo el presupuesto atómico, o la llamada se enruta por el relé. `isEnabled(user)` se comprueba `approve_spl` y[Una sola vez: concede al wrapper](/es/guias-para-desarrolladores/dual-lane-app.md#one-time-grant-the-wrapper)).
6. se envía una vez cuando es falso (
7. Verificado el origen en el explorador. `deps` los valores se completan a mano desde [Rubicon](/es/redes/rubicon.md). Se ejecuta el mismo viaje de ida y vuelta una vez con fondos reales, usando una billetera que has verificado firma transacciones v1 en mainnet.

## Qué sigue

* [Construir una app de doble carril](/es/guias-para-desarrolladores/dual-lane-app.md) — el ejemplo de vault, paso a paso, ambas billeteras
* [Llamar a EVM desde Solana](/es/guias-para-desarrolladores/call-evm-from-solana.md) — direcciones sintéticas, descubrimiento de cuentas, los endpoints externos V1
* [Deploy Solidity Contracts](/es/guias-para-desarrolladores/deploy-solidity.md) · [Verificar contratos](/es/guias-para-desarrolladores/verify-contracts.md) · [Contract Addresses](/es/referencia/contract-addresses.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/guias-para-desarrolladores/open-to-solana-users.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.