COLORFIGURE / ETHEREUM
Execute above, settle below

How a rollup settles to Ethereum

The L2 executes many transactions. Ethereum makes the batch data available in blobs and anchors the rollup’s verification state on L1.

Conceptual diagram: exact sequencer, proving, bridge, challenge and withdrawal designs vary by rollup. No universal timing or delay is implied.

READY / choose a step0 of 6
Rollup relationship to EthereumTransactions enter an L2 sequencer and execution engine; compressed batch data is posted in an Ethereum blob transaction, while commitments and proofs are checked by rollup contracts on Ethereum. USER TRANSACTIONSsend to the L2 L2 SEQUENCER + EXECUTIONorder · execute · update L2 state COMPRESSED BATCHblob transaction + commitment ETHEREUM DA + CONSENSUSblob sidecars checked by consensus L1 ROLLUP CONTRACTSpersistent state roots · verifier logic WITHDRAWAL ELIGIBILITY CLAIM + DISPUTE BLOBS ARE DATA AVAILABILITY• batch data is temporary• EVM sees versioned hashes, not bytes• L1 does not rerun every L2 tx
Choose a proof model, then step through the machine.
1

Execution

The sequencer orders transactions and the L2 executes them. A fast sequencer confirmation is useful UX, but it is not the same as L1 data finality, settlement acceptance, or withdrawal eligibility.

2

Data availability

A batch publisher puts compressed data in blob sidecars linked to an Ethereum transaction. Ethereum checks availability; L2 nodes can retrieve data to reconstruct and verify. The EVM sees versioned hashes—not full blob bytes.

3

Settlement

L1 rollup contracts persist state/output commitments and apply verification rules. A blob’s KZG commitment binds data; it is not the rollup state commitment or a proof of correct L2 execution.

OPTIMISTIC

Assume, then dispute

A state commitment is accepted under the rollup’s rules unless successfully challenged. A dispute/fault-proof process can reject a bad claim; it does not imply every L2 transaction waits for the withdrawal delay to be called final.

  • L1 data/order finality and withdrawal eligibility are separate milestones.
  • Challenge design and delays are deployment-specific.
VALIDITY PROOF

Prove, then verify

A validity proof accompanies a state update. An Ethereum verifier contract checks the proof against public inputs and state commitments.

  • Execution-proof acceptance is distinct from blob availability.
  • A validity proof does not guarantee instant withdrawal eligibility.

Sources & scope

  1. EIP-4844 — Shard Blob Transactions: blob transactions, KZG commitments, versioned hashes, consensus-layer availability, temporary retention, and blob non-accessibility to EVM execution.
  2. Ethereum.org — Optimistic rollups: state commitments, dispute/fault-proof concepts, and withdrawal implications.
  3. Ethereum.org — Zero-knowledge rollups: validity proofs and L1 verification.
  4. Ethereum.org — Proof of stake: ordering, attestations, and finality.
  5. OP Stack — Transaction finality: one concrete model separating soft confirmation, L1 data finality, and withdrawal proving/finalization.

Conceptual educational overview, not a specification for any named rollup. Visual grammar inspired by April Zhu’s Colorfigures, MIT licensed; built on ISO-GLOW by April Zhu and iso-figure by Tolga Cohce. No downloaded skill code is embedded.