# Key Concepts

Essential terminology and concepts for building on Rome Protocol.

## Solana Concepts

**Program** — Solana's equivalent of a smart contract. Programs are stateless executables deployed on-chain. The Rome EVM is itself a Solana program.

**Account** — All state on Solana lives in accounts. Each account has an owner (program), a balance (lamports), and data. Unlike Ethereum, code and state are stored in separate accounts.

**PDA (Program Derived Address)** — A deterministic address derived from seeds and a program ID. PDAs allow programs to "own" accounts without a private key. Rome uses PDAs to map Ethereum addresses to Solana accounts.

**CPI (Cross-Program Invocation)** — One Solana program calling another within the same transaction. This is how Rome EVM contracts interact with Jupiter, Kamino, SPL Token, and other Solana programs.

**SPL Token** — Solana's standard token program. Equivalent to ERC-20 on Ethereum. All fungible tokens on Solana (USDC, SOL, etc.) are SPL tokens.

**Token-2022** — The next-generation SPL token program with extensions like Transfer Hooks, Confidential Transfers, and Permanent Delegates.

**Transfer Hook** — A Token-2022 extension that invokes a program on every token transfer. Rome enables EVM smart contracts to act as transfer hooks.

**ATA (Associated Token Account)** — A deterministic token account for a given wallet + mint pair. Every user has one ATA per token they hold.

**Lamports** — The smallest unit of SOL. 1 SOL = 1,000,000,000 lamports (10^9).

**Compute Units (CU)** — Solana's equivalent of Ethereum gas. Each transaction has a compute budget (default \~200K CU, max \~1.4M CU). Operations consume CU.

## Rome Concepts

**Rome EVM Program** — The Solana program that contains the EVM bytecode interpreter. Deployed at a specific program ID per environment.

**Chain ID** — Each application on Rome gets its own EVM chain ID. This creates isolated EVM environments that share the same underlying Solana state.

**Atomic Execution (VmAt)** — An EVM transaction that executes entirely within a single Solana transaction. Used for most operations.

**Iterative Execution (VmIt)** — An EVM transaction split across multiple Solana transactions, executing \~500 opcodes per step. Used for compute-intensive operations like BN254 pairing.

**Holder Account** — An on-chain buffer that stores large EVM transactions (up to 80 KB) that exceed Solana's 1,232-byte transaction size limit. Managed transparently by the SDK.

**StateHolder** — An on-chain account that stores serialized VM state between iterative execution steps.

**Rome Proxy** — The JSON-RPC server (port 9090) that translates Ethereum API calls into Solana transactions. Your MetaMask and Hardhat connect here.

**Hercules** — The block indexer that monitors Rome EVM events on Solana and produces Ethereum-compatible block data.

**Rhea** — The mempool bridge that relays transactions from OP-Geth to Solana (used only in OP-Geth mode).

**Payer** — A Solana keypair that signs and pays for Solana transactions on behalf of EVM users. Managed by the Proxy via payer pools.

## Token Concepts

**ERC20SPL** — An ERC-20 wrapper contract that represents an SPL token inside Rome EVM. The wrapper reads balances directly from the underlying SPL token account — no separate state.

**ERC20SPLFactory** — A factory contract that deploys ERC20SPL wrappers for any SPL token on first bridge.

**Canonical Token Registry** — Maps each asset to a single canonical SPL mint to prevent fragmented representations (e.g., USDC always maps to Circle's native SPL mint).

## Precompiles

**Standard Ethereum Precompiles** — ecrecover (0x01), SHA-256 (0x02), RIPEMD-160 (0x03), identity (0x04), BN254 ecAdd/ecMul/ecPairing (0x06-0x08), Blake2f (0x09).

**System Program Precompile** (`0xFF...07`) — PDA derivation, base58 conversion, account creation from Solidity.

**CPI Precompile** (`0xFF...08`) — Cross-program invocation from Solidity. Call any Solana program with `invoke()` or `invoke_signed()`.

**Withdraw Precompile** (`0x42...16`) — Withdraw SOL or SPL tokens from EVM back to Solana.

## Transaction Types

**RheaTx** — A single EVM transaction on one rollup. The most common type.

**RemusTx** — Multiple EVM transactions across different rollups, executed atomically. If any transaction fails, all revert.

**RomulusTx** — Combined EVM transactions + native Solana instructions in one atomic operation. The most powerful type — mix Solidity and Solana in a single transaction.

## Deployment Modes

**Single-State Mode** — Users connect directly to Rome Proxy. Simpler setup, lower latency. EVM blocks produced by Hercules and stored in PostgreSQL.

**OP-Geth Mode** — Users connect to OP-Geth for full Ethereum RPC compatibility. Rhea bridges the mempool to Solana. Hercules feeds blocks to OP-Geth via Engine API.

## What's Next

* [Execution Model](/core-concepts/execution-model.md) — deep dive into how EVM transactions execute on Solana
* [Token Interop](/core-concepts/token-interop.md) — how ERC-20 and SPL tokens interact
* [Constraints](/core-concepts/constraints.md) — important limits and boundaries


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.rome.builders/getting-started/key-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.