Skip to content
Financial Context Wiki

Optimistic rollups

A deployment-specific guide to sequencer receipts, L1 derivation data, unsafe/safe/finalized heads, fault-proof games, canonical withdrawals, governance and fast exits.

Updated

For educational purposes only; not protocol, bridge or transaction advice. Optimistic-rollup guarantees depend on the exact deployment, data mode, derivation rules, live fault-proof game, permissions, clocks, governance and withdrawal contracts; verify each stage and asset independently.

Direct answer

An optimistic rollup executes an ordered transaction stream and posts protocol-defined derivation data and state claims without attaching a validity proof to every batch. “Optimistic” means an eligible claim can progress under the deployed rules unless a successful fault-proof dispute establishes that it is wrong. It does not mean a sequencer message proves correctness, nor that every implementation has permissionless challenges or the same withdrawal delay.

Rollup nodes independently derive L2 blocks from canonical L1 inputs and the exact protocol configuration. The security path therefore includes data availability, correct derivation and execution, a live and sound fault-proof system, L1 access and finality, governance and bridge contracts. A state root alone is not enough to reconstruct the chain or challenge an invalid transition.

1
Sequence

The sequencer orders L2 transactions and publishes transaction data or commitments.

How it works

  1. Pin the deployment: L1 and L2 chain IDs, rollup configuration and fork, inbox and bridge contracts, batch format and DA mode, state-claim and dispute-game contracts, portal version, administrators, guardians and observation block. Stack documentation is not evidence that every feature is live on a named chain.
  2. Classify the observed state. A sequencer receipt or unsafe block is a fast local ordering commitment; an L1-published batch can support a safely derived head; L1 finality can support a finalized derived head. A state or output claim, resolved dispute and executable withdrawal are separate objects and clocks.
  3. Reconstruct the L1-to-L2 derivation pipeline. Verify deposits and sequenced inputs, channels and batches, L1 origins, configuration changes and state transitions from canonical L1 data. For blob-backed data, distinguish protocol-window availability from later archival retrieval.
  4. Map liveness and control. Separate sequencer, batcher, proposer, challenger, relayer, guardian and upgrade authority; verify whether forced inclusion or delayed inbox paths exist, their delays and pause conditions, and whether ordinary users have working software to invoke them.
  5. Verify the deployed fault-proof path. Record the respected game type, proposer and challenger permissions, bonds, absolute prestate, proof program and VM, preimage oracle, claim depth, clocks and extensions, resolution rules, blacklist or pause powers and upgrade delay. Do not transplant OP Stack mechanics into Arbitrum or another rollup.
  6. Trace withdrawals and economics separately. Follow L2 initiation, L1 proof, claim or game dependency, maturity and finality delay, re-proving, portal checks and L1 execution. Treat a fast exit as a priced liquidity or credit transaction with a separate counterparty, not as a shorter canonical challenge clock.
  7. Reconcile continuously. Match unsafe, safe and finalized block hashes, L1 batch transactions, state claims, game outcomes, bridge messages, receipts, token contracts and final balances. Reopen the analysis after an L1 or L2 reorganization, missing batch, dispute, pause, contract upgrade or DA migration.

Worked examples

  • Derivation payload. A batch contains 10,000 transactions, 1,200 KB of raw protocol inputs and 300 KB after compression. The ratio is 1,200 / 300 = 4.0x, the reduction is 1 - 300 / 1,200 = 75%, and the decimal average is 300,000 / 10,000 = 30 bytes/tx. These numbers describe only encoded input payload, not L1 gas, execution correctness, state size or archival guarantees.
  • Contribution before omitted costs. Users pay 2.4 ETH; measured L2 execution is 0.3 ETH; L1 DA is 1.2 ETH. The residual is 2.4 - 0.3 - 1.2 = 0.9 ETH, or 0.9 / 10,000 = 0.00009 ETH/tx. It is not net profit because operator infrastructure, L1 execution, proof games, refunds, capital, failures and taxes are omitted.
  • Dispute localization. A teaching execution trace has 2^20 = 1,048,576 steps. Ideal binary narrowing needs log2(2^20) = 20 choices to isolate one step. If each teaching round had a separate 3-hour maximum, a naive serial bound would be 20 * 3 = 60 hours; actual protocols use their own chess clocks, concurrency, extensions and transaction schedule.
  • Withdrawal clocks and fast liquidity. A teaching batch reaches L1 after 10 minutes, a recognized claim after another 30 minutes, then a hypothetical challenge period lasts 7 days, and final relay takes 2 hours. Sequential elapsed time is 10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes. A liquidity bridge that advances 4.97 ETH against a 5 ETH claim charges 0.03 ETH, or 0.03 / 5 = 0.6%, while the canonical claim remains subject to its original clocks and risks.

Risks

  • Wrong L1, L2, chain IDs, rollup config or contract deployment.
  • Treating an unsafe sequencer receipt as safe or final.
  • Sequencer equivocation, censorship, reordering or outage.
  • Delayed, missing, malformed or invalid L1 batch publication.
  • Blob or alternative-DA data becoming unavailable or unarchived.
  • Derivation client, configuration or fork mismatch.
  • L1 reorganization invalidating previously safe derivation inputs.
  • Batcher, state proposer or proof participant outage.
  • Forced-inclusion or delayed-inbox path absent, paused or misunderstood.
  • Fault proofs not deployed, inactive or tied to the wrong game type.
  • Permissioned or allowlisted proposer or challenger roles.
  • Challenger offline, censored, underfunded or missing a deadline.
  • Proof program, VM, absolute prestate, oracle or verifier bug.
  • Clock, extension, claim position, bond or resolution-accounting error.
  • Guardian, security council, pause or blacklist intervention.
  • Immediate upgrade, short timelock or compromised administrator keys.
  • Canonical bridge, messenger, replay or asset-mapping vulnerability.
  • Withdrawal proof, maturity, re-proof, finalization or relay failure.
  • Fast-exit liquidity, pricing, routing, insolvency or counterparty risk.
  • Conflating L1 finality, L2 derived finality, claim resolution and asset receipt.

Common misconceptions

  • Optimistic means users unconditionally trust the sequencer’s displayed result.
  • Posting a state root alone supplies data availability and independent derivation.
  • Every optimistic rollup has live permissionless fault proofs and a universal seven-day clock.
  • A safe or finalized L2 block means its L2-to-L1 withdrawal can already execute.
  • A fast bridge shortens the canonical challenge period or carries only rollup risk.

Sources

Navigation

Search the wiki...