> 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/introduccion/key-concepts.md).

# Conceptos clave

Terminología esencial de Solana y de Rome EVM para desarrolladores: programas, cuentas, PDA, CPI, tokens SPL y ejecución atómica frente a iterativa.

Terminología y conceptos esenciales para construir sobre Rome Protocol.

## Conceptos de Solana

**Programa** — El equivalente en Solana de un contrato inteligente. Los programas son ejecutables sin estado desplegados en cadena. El Rome EVM es en sí mismo un programa de Solana.

**Cuenta** — Todo el estado en Solana vive en cuentas. Cada cuenta tiene un propietario (programa), un saldo (lamports) y datos. A diferencia de Ethereum, el código y el estado se almacenan en cuentas separadas.

**PDA (Dirección Derivada de Programa)** — Una dirección determinista derivada de semillas y de un ID de programa. Las PDA permiten a los programas "poseer" cuentas sin una clave privada. Rome usa PDA para mapear direcciones de Ethereum a cuentas de Solana.

**CPI (Invocación entre programas)** — Un programa de Solana llamando a otro dentro de la misma transacción. Así es como los contratos de Rome EVM interactúan con Jupiter, Kamino, SPL Token y otros programas de Solana.

**SPL Token** — El programa de tokens estándar de Solana. Equivalente a ERC-20 en Ethereum. Todos los tokens fungibles en Solana (USDC, SOL, etc.) son tokens SPL.

**Token-2022** — El programa de tokens SPL de nueva generación con extensiones como Transfer Hooks, Transferencias Confidenciales y Delegados Permanentes.

**Transfer Hook** — Una extensión de Token-2022 que invoca un programa en cada `transfer_checked` llamada.

**ATA (Cuenta de Tokens Asociada)** — Una cuenta de tokens determinista para un par cartera + mint dado. Cada usuario tiene una ATA por cada token que posee.

**Lamports** — La unidad más pequeña de SOL. 1 SOL = 1,000,000,000 lamports (10^9).

**Unidades de Cómputo (CU)** — El equivalente en Solana al gas de Ethereum. Cada transacción tiene un presupuesto de cómputo (por defecto \~200K CU, máximo \~1.4M CU). Las operaciones consumen CU.

## Conceptos de Rome

**Programa Rome EVM** — El programa de Solana que contiene el intérprete de bytecode de la EVM. Desplegado en un ID de programa específico por entorno.

**ID de cadena** — Cada aplicación en Rome obtiene su propio chain ID de EVM. Esto crea entornos EVM aislados que comparten el mismo estado subyacente de Solana.

**Ejecución atómica (VmAt)** — Una transacción EVM que se ejecuta por completo dentro de una sola transacción de Solana. Se usa para la mayoría de las operaciones.

**Ejecución iterativa (VmIt)** — Una transacción EVM dividida en múltiples transacciones de Solana, en la que cada paso empaqueta tantos opcodes como quepan en el presupuesto de cómputo de una transacción de Solana (adaptativo, no un recuento fijo). Se usa para operaciones que consumen mucho cómputo, como el emparejamiento BN254.

**Cuenta contenedora** — Un búfer en cadena que almacena transacciones EVM grandes (hasta 80 KB) que exceden el límite de tamaño de transacción de Solana (v1) de 4 KB. Gestionado de forma transparente por el SDK.

**StateHolder** — Una cuenta en cadena que almacena el estado serializado de la VM entre pasos de ejecución iterativos.

**Proxy de Rome** — El servidor JSON-RPC (puerto 9090) que traduce llamadas de la API de Ethereum en transacciones de Solana. Tu MetaMask y Hardhat se conectan aquí.

**Hércules** — El indexador de bloques que supervisa los eventos de Rome EVM en Solana y produce datos de bloques compatibles con Ethereum.

**Pagador** — Una clave pública/privada de Solana que firma y paga las transacciones de Solana en nombre de los usuarios de EVM. Gestionada por el Proxy mediante grupos de pagadores.

## Conceptos de tokens

**SPL\_ERC20 / SPL\_ERC20\_cached** — Contratos envoltorio ERC-20 que representan un token SPL dentro de Rome EVM. Para una cartera, el envoltorio lee el saldo directamente de la cuenta de token SPL subyacente. Los tokens que mantiene un contrato residen en la propia cuenta escrow de tokens del envoltorio y se registran en el almacenamiento del envoltorio (véase [Integrar un programa de Solana](/es/guias-para-desarrolladores/integrate-solana-program.md)). La fábrica despliega hoy la variante en caché.

**ERC20SPLFactory** — Un contrato de fábrica que despliega envoltorios para cualquier token SPL.

**Registro** — Los envoltorios canónicos, los tokens de gas y la configuración del puente se curan fuera de la cadena en el [rome-protocol/registry](https://github.com/rome-protocol/rome-registry); no existe un contrato de registro de tokens en cadena. Esto mantiene cada activo asignado a una única mint SPL canónica.

## Precompilados

**Precompilados estándar de Ethereum** — ecrecover (0x01), SHA-256 (0x02), RIPEMD-160 (0x03), identidad (0x04), modexp (0x05), BN254 ecAdd/ecMul/ecPairing (0x06-0x08), Blake2f (0x09).

**Precompilado del sistema** (`0xFF...07`) — derivación de PDA y conversión a base58 desde Solidity.

**Precompilado CpiProgram** (`0xFF...08`) — invocación entre programas (`invoke` / `invoke_signed`) más accesos directos de lectura entre estados.

**Precompilado HelperProgram** (`0xFF...09`) — creación de ATA/PDA, transferencias SPL y conversión gas↔lamports; la superficie principal para operaciones SPL firmadas por el usuario con PDA.

**Precompilado de retiro** (`0x42...16`) — retirar SOL o tokens SPL desde EVM de vuelta a Solana.

Una familia de rutas en caché (`0xff…04/05/06/0b`) las replica para lecturas eficientes en CU; un contrato usa una sola ruta de forma consistente.

## Tipos de transacción

**RheaTx** — Una sola transacción EVM en un rollup. El tipo más común.

**RemusTx** — Múltiples transacciones EVM en distintos rollups, ejecutadas atómicamente. Si alguna transacción falla, todas se revierten.

**RomulusTx** — Transacciones EVM combinadas + instrucciones nativas de Solana en una sola operación atómica. El tipo más poderoso: mezcla Solidity y Solana en una sola transacción.

## Qué sigue

* [Modelo de ejecución](/es/conceptos-basicos/execution-model.md) — análisis profundo de cómo se ejecutan las transacciones EVM en Solana
* [Interop de tokens](/es/conceptos-basicos/token-interop.md) — cómo interactúan los tokens ERC-20 y SPL
* [Restricciones](/es/conceptos-basicos/constraints.md) — límites y fronteras importantes


---

# 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/introduccion/key-concepts.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.