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 — deep dive into how EVM transactions execute on Solana

• Token Interop — how ERC-20 and SPL tokens interact

• Constraints — important limits and boundaries