Antler by Autoflux
HomeOptimism (OP Stack)Architecture
Report an error

Architecture

The full component topology — consensus client, execution engine, batcher, proposer, fault-proof system, and L1 contracts — and how they connect.

Path: architecture

Third-party documentation. This is independently authored analysis of the public Optimism (OP Stack) codebase — not the official docs, and not reviewed or endorsed by the Optimism (OP Stack) team.

Architecture

An OP Stack chain is split into two trust domains: a set of off-chain services (Go binaries) that produce and verify blocks, and a set of on-chain contracts (Solidity) that anchor the chain to Ethereum and mediate deposits and withdrawals. The two halves communicate only through data published on L1.

Off-chain services

  • op-node — the consensus client. It reads L1, derives canonical L2 blocks from batched data, and drives op-geth through the engine API. It is the component that answers "what is the canonical chain?"
  • op-geth — the execution client, a fork of go-ethereum with rollup modifications (deposit transactions, the L1Block system contract, engine-API-driven block production). It executes transactions and maintains the EVM state.
  • op-batcher — compresses and batches L2 blocks into transactions posted to an L1 inbox contract, guaranteeing data availability.
  • op-proposer — submits L2 output roots (state commitments) to the L1 output-root contract, driving settlement and withdrawals.
  • op-program — a self-contained fault-proof program: given an L1 state + a claimed output, it deterministically recomputes the L2 state transition. It is the executable the fault-proof VM runs.
  • op-challenger — participates in dispute games on L1, proving or disputing output roots with the op-program + Cannon (the MIPS/WASM fault-proof VM).
  • op-bootnode — a lightweight P2P discovery node used by op-node peers.

On-chain contracts (L1)

  • OptimismPortal — the single bridge contract. All deposits enter here; all withdrawals are proven and finalized here.
  • CrossDomainMessenger — the message-passing layer that deposits/withdrawals and cross-chain contract calls route through.
  • L1StandardBridge / L2StandardBridge — convenience token bridge (ETH and ERC-20s), layered on the messenger.
  • SystemConfig — holds L1-relevant chain parameters (gas limits, fee scalar, the batcher/sequencer addresses) and emits the configuration events op-node reads during derivation.
  • L2OutputOracle (legacy) / DisputeGameFactory — records output roots. Modern deployments use the dispute-game machinery with fault proofs; the oracle contract still serves the same role for the state.

How the two halves connect

  1. The sequencer (an op-node + op-geth pair) produces L2 blocks and propagates them over P2P to other op-nodes.
  2. op-batcher reads canonical L2 blocks, encodes them into channels/frames, and posts them as L1 transactions to the batch inbox.
  3. Every op-node derives the canonical chain from those L1 transactions — the L1 data, not the P2P gossip, is the source of truth for ordering.
  4. op-proposer periodically posts the L2 output root to L1. If a challenger disagrees, a dispute game runs op-program inside Cannon on L1 to adjudicate.
  5. Users bridge through the portal; deposits are queued into op-geth as deposit transactions, and withdrawals are proven against the output root and finalized after the challenge window.

Design principles

  • L1 is the source of truth. No off-chain service can permanently fork the chain; canonicality is derived from L1 data.
  • Sequencing is centralized, verification is not. One sequencer orders blocks for UX and throughput, but anyone can run an op-node and verify every block.
  • Modularity is deliberate. Every component has a small, well-defined interface, which is what makes the "stack" forkable and combinable (a new DA layer swaps in at the batcher/derivation boundary, a new VM at the op-program boundary, etc.).

System Diagram

User
Frontend
Lending
Vaults
Trading
Liquidation
Core
Oracle
Data / Storage

Interface

Interface
text
                    ┌─────────────────────────────┐
                    │        L1 (Ethereum)        │
                    │  OptimismPortal · L1Standard │
                    │  Bridge · L2OutputOracle     │
                    │  SystemConfig · DisputeGame  │
                    │  BatchInbox (batch tx data)  │
                    └──────────▲──────────▲────────┘
                               │ batches │ output roots
          ┌────────────────────┘         └─────────────────────┐
          │                                                    │
   op-batcher │ op-proposer                            op-challenger
          │                                                    │
   ┌──────┴──────────┐   P2P   ┌──────────────────────────┐    │
   │     op-node     │◄────────┤   op-geth (execution)     │    │
   │ consensus/      │  blocks │   EVM fork · deposit txs  │    │
   │ derivation      │         │   engine API (rollup v2)  │    │
   └─────────────────┘         └──────────────────────────┘    │
          │                                                      │
   ┌──────┴──────────┐   ┌──────────────────────────┐             │
   │   op-program    │◄──│  fault-proof VM (Cannon) │             │
   └─────────────────┘   └──────────────────────────┘◄────────────┘
 
STATUSinterface