What Are Optimistic Rollups?

In brief

• Optimistic rollups move execution off Ethereum while using Ethereum for data availability, batch ordering and dispute settlement. A sequencer still chooses the order of transactions inside each submitted batch.
• A state assertion or withdrawal claim is accepted after a challenge period unless a valid fault proof defeats it.
• “Fraud proof” and “fault proof” are often used for the same family of mechanisms; implementations differ substantially.
• A centralized sequencer can give fast confirmations, but users initially trust it for ordering and inclusion.
• A canonical L2-to-L1 withdrawal commonly waits about a week, but the exact period is a protocol parameter.
• Upgrade keys, guardians and bridge controls can be more powerful than the proof system, so “inherits Ethereum security” needs qualifications.

The broader Layer 2 article maps the category. This article focuses on the optimistic mechanism rather than repeating the whole L2 survey.

Why the design is “optimistic”

Ethereum cannot cheaply re-execute every transaction from every rollup. An optimistic rollup therefore publishes transaction data and commitments to its resulting state, while doing most execution elsewhere. The rollup’s contracts provisionally accept a claim about the result.

During the challenge period, independent participants can run the rollup software, reconstruct the state from published data and compare their result with the claim. If they disagree, they can open a dispute on the settlement chain. If nobody successfully challenges before the deadline, the claim becomes usable for the protocol operation it protects, such as finalizing a withdrawal.

That last sentence is deliberately narrower than “all transactions take a week to finalize.” OP Stack documentation, for example, distinguishes:

1. a sequencer confirmation, which is fast but trusts the sequencer;
2. the transaction data becoming anchored to Ethereum;
3. Ethereum finalizing the block that contains that data; and
4. a separate challenge delay before a canonical withdrawal claim can be executed.

Other optimistic systems use different terminology and timing. The challenge window is usually measured in days to give honest challengers time to notice a bad claim, obtain the data, submit transactions during congestion and complete the dispute. About seven days is common, not a rule imposed by Ethereum. Arbitrum One’s BoLD documentation, for example, specifies a configurable 6.4-day challenge period.

What a fault proof actually proves

The claim being disputed is normally an assertion about rollup state or a withdrawal, not a casual allegation that a sequencer “sent a bad transaction.” A challenger and defender commit to incompatible execution results. In an interactive design, they repeatedly bisect the disputed execution trace until they isolate one instruction or small transition. An L1 contract can then evaluate the final step using the rollup’s defined state-transition rules.

Some systems use different game structures, virtual machines, timing rules and bond incentives. OP Stack’s permissionless fault-proof system uses dispute games and its Cannon virtual machine; Arbitrum BoLD uses assertions and a WebAssembly-based one-step proof. These are examples, not a universal recipe.

Bonds make spam and dishonest participation costly, but “the sequencer is automatically slashed” is not a safe generalization. The bonded actor may be a state proposer, validator, challenger or another participant. The protocol’s contracts decide which claim wins and how bonds are distributed.

The minimum security assumption is often summarized as “one honest challenger.” That is meaningful only if:

• challenging is actually permissionless;
• an honest challenger can reconstruct the relevant state;
• the proof software and L1 verifier implement the same transition correctly;
• the challenger can get transactions included before its clocks expire; and
• privileged governance cannot simply replace or bypass the rules.

Data availability is part of the proof system

A challenger cannot replay hidden transactions. Optimistic rollups therefore publish the data needed to derive their state to Ethereum, commonly through transaction calldata or EIP-4844 blobs.

Blob transactions give rollups a separate, cheaper data market. The EVM can access a commitment to blob data, not the blob bytes themselves. Ethereum guarantees blob availability for a protocol-defined retention window—EIP-4844 set a minimum of 4,096 epochs, roughly 18 days—rather than permanent storage. That window is longer than the usual challenge period, allowing watchers to fetch and verify the data before normal pruning.

Temporary blob retention does not mean the rollup state vanishes after 18 days. Rollup nodes, archives and other data services can retain history, and newer state can be reconstructed incrementally. It does mean Ethereum’s protocol-level promise is availability during the required window, not indefinite historical hosting.

Sequencers: speed with a trust boundary

Most deployed rollups use a sequencer to order transactions and issue quick confirmations. Before a batch is posted to Ethereum, the sequencer may be able to omit, delay or reorder transactions and may capture ordering-related value. A fast wallet confirmation is therefore not the same assurance as Ethereum-finalized batch data.

A robust design includes an L1 route for deposits or forced inclusion when the sequencer censors or disappears. The exact escape hatch matters: who can call it, how long it takes, whether it pauses during upgrades, and whether users can exit without cooperation. “Rollups have forced inclusion” should be checked per network, not inferred from the label.

Published data limits what a sequencer can rewrite after Ethereum orders it. Fault proofs limit which unsupported claims can authorize withdrawals. Neither property guarantees continuous service: a sequencer outage can still make the L2 inconvenient or temporarily unusable.

Deposits, withdrawals and bridges

To deposit through a canonical bridge, a user generally locks an asset in an L1 contract and receives a corresponding balance on L2. To withdraw, the user initiates an L2-to-L1 message, proves it against a recognized state commitment and waits until the challenge rules permit finalization.

Liquidity bridges can pay the user sooner and later collect the canonical withdrawal. That improves speed by introducing liquidity-provider, smart-contract and routing risks; it does not shorten the underlying fault-proof window. The Bridges article covers those trust models in detail.

Cross-layer contract calls are asynchronous. An L1-to-L2 message and an L2-to-L1 withdrawal do not have identical timing or failure behavior, so applications should not treat them as synchronous calls within one chain.

Security is more than the proof type

The proof mechanism constrains invalid state claims, but deployed rollups are systems of contracts, operators and governance. Important questions include:

• Can an admin upgrade the bridge or verifier immediately?
• Can a guardian pause withdrawals or select a different dispute game?
• Is the sequencer centralized, and is forced inclusion live?
• Who can propose and challenge state?
• Where is batch data published?
• Are users dependent on one implementation of the node or proof program?

Optimism’s own security documentation states that governed OP Stack chains depend on multisig-controlled upgrade powers and that the Guardian can intervene in fault-proof operation. This is not evidence that every optimistic rollup has the same controls. It illustrates why a functioning proof system does not erase upgrade-key or governance risk.

Fees and compatibility

A user’s fee can include L2 execution, a share of Ethereum data costs and an operator margin. Batching and compression spread L1 publication costs across many L2 transactions. Fees still rise when blob space, calldata, proving infrastructure or the rollup itself is congested.

Many optimistic rollups closely reproduce EVM behavior, making existing Solidity contracts and tooling easier to reuse. Compatibility is a spectrum: precompiles, gas accounting, block fields, finality labels and cross-layer messaging can differ. EVM compatibility is useful engineering, not proof that two networks have identical security.

Optimistic versus ZK rollups

Both designs execute away from L1 and need a settlement contract plus available state data. The main distinction is how L1 rejects invalid state transitions:

• an optimistic rollup gives challengers time to submit a fault proof;
• a ZK rollup requires a validity proof before L1 accepts the new state.

That difference explains the canonical withdrawal delay, but it does not by itself reveal which rollup has safer upgrade controls, better data availability, a more decentralized sequencer or stronger escape hatches.