Key Concepts

Essential Solana and Rome EVM terminology for developers — programs, accounts, PDAs, CPI, SPL tokens, and atomic vs. iterative execution.

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 transfer_checked call.

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, each step packing as many opcodes as fit in one Solana transaction's compute budget (adaptive, not a fixed count). 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.

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

SPL_ERC20 / SPL_ERC20_cached — ERC-20 wrapper contracts representing an SPL token inside Rome EVM. The wrapper reads balances directly from the underlying SPL token account — no separate state. The factory deploys the cached variant today.

ERC20SPLFactory — A factory contract that deploys wrappers for any SPL token.

Registry — Canonical wrappers, gas tokens, and bridge wiring are curated off-chain in the rome-protocol/registry; there is no on-chain token-registry contract. This keeps each asset mapped to a single canonical SPL mint.

Precompiles

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

System Precompile (0xFF...07) — PDA derivation and base58 conversion from Solidity.

CpiProgram Precompile (0xFF...08) — Cross-program invocation (invoke / invoke_signed) plus cross-state read shortcuts.

HelperProgram Precompile (0xFF...09) — ATA/PDA creation, SPL transfers, and gas↔lamports conversion; the primary surface for user-PDA-signed SPL operations.

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

A cached-track family (0xff…04/05/06/0b) mirrors these for CU-efficient reads; a contract uses one track consistently.

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.

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