Optimistic Rollup: Fault Proofs, Fees, and Risks

An optimistic rollup is a scaling system that executes transactions outside its settlement chain and publishes the data needed to derive its state to that chain’s data-availability layer. State claims can be accepted after a dispute process rather than requiring a validity proof for each accepted claim. Nodes still execute and check transactions; “optimistic” describes settlement of claims, not an absence of validation.

A challenger can dispute an incorrect claim under the deployed rules. Interactive systems narrow a disagreement to a small computation that an on-chain verifier can check. Security depends on available data, a functioning proof system, timely honest participation, and the chain’s upgrade and emergency controls. (Source: Ethereum optimistic rollup architecture)

Arbitrum One and OP Mainnet are prominent examples; Base launched using the OP Stack. Chains using external data availability have different security assumptions and are often classified separately from Ethereum-data-availability rollups. TVL, total value secured, and transaction counts are distinct, time-sensitive measures.

Optimistic rollups represent one of two dominant approaches to rollup-based scaling (the other being ZK rollups), and are widely considered a critical component of Ethereum’s long-term scalability roadmap as articulated by Ethereum co-founder Vitalik Buterin in his “rollup-centric” vision for the network.

Origin & History

Early research: Off-chain execution with on-chain dispute resolution develops through several proposals and prototypes.

Research foundations: Work on interactive verification, data availability, and execution contributes to optimistic rollup designs; no single early paper captures the entire lineage.

2019: Optimistic rollup designs gain attention as teams explore publishing transaction data to a base chain while resolving execution disputes separately.

2020: Optimism and Offchain Labs develop and test their execution and dispute architectures before broader mainnet deployment.

2021: Both Optimism and Arbitrum launched their mainnets. Optimism soft-launched in January with Synthetix as its first major partner, while Arbitrum One opened to all projects in August 2021, quickly attracting hundreds of DeFi protocols and accumulating billions in TVL.

2022–2023: Arbitrum One migrates to Nitro on August 31, 2022. Optimism’s Bedrock upgrade and Base’s public launch follow in 2023.

2024–2025: OP Mainnet introduces permissionless fault proofs in 2024, while Arbitrum One activates BoLD in February 2025. Ethereum’s March 2024 Dencun upgrade introduces blobs for rollup data; subsequent data-availability upgrades continue the scaling work.

In Simple Terms

1. Imagine homework that classmates can independently check, with disputed results sent to a referee. The analogy only works if someone can obtain the inputs, identify a mistake, and submit a timely challenge.
2. An optimistic rollup is like processing a batch of claims with an enforceable review period. Normal checking occurs continuously; the settlement system resolves disputes instead of repeating all computation on the base chain.
3. A provisional result can become settled after the relevant proof and delay requirements. This does not mean users can freely reverse any transaction for seven days or undo a valid payment.
4. It’s like a restaurant with an open buffet and a security camera. The restaurant trusts everyone to take only what they paid for (optimistic assumption), but if the camera catches someone sneaking extra (fraud detected), the staff can intervene. The camera is always watching, but it only takes action when there’s a problem.

Important: Canonical withdrawals often include a dispute-related waiting period, but its length and additional steps are deployment-specific. Sequencer confirmation, data publication, settlement, and withdrawal eligibility are different milestones.

Key Technical Features

Transaction Execution Model

Optimistic rollups maintain L2 account and contract state. Ordering, execution, batching, and state-claim posting may be handled by separate roles:

• Receiving user transactions via a JSON-RPC endpoint
• Ordering transactions and executing them against the current L2 state
• Producing L2 blocks or preconfirmations at the chain’s configured cadence
• Batching multiple blocks of transactions together for L1 submission
• Posting compressed transaction data to Ethereum as calldata or blobs

How Optimistic Rollup Fraud Proofs Work

1. An execution node derives L2 state from the chain’s inputs; a sequencer commonly orders transactions.
2. A proposer posts a state claim under the rollup’s rules, which may require a bond.
3. Eligible participants can inspect and challenge claims during the configured process.
4. A challenger initiates a dispute when its independently computed state disagrees with a claim.
5. In an interactive design, the parties narrow the disagreement until an on-chain verifier checks the disputed machine step.
6. The dispute rules determine which claims survive and how bonds and costs are handled. Payouts are not identical across protocols.
7. An eligible claim can be confirmed after the required periods and resolution conditions are satisfied.

Interactive Dispute Designs

• OP Stack fault proofs: The fault dispute game interactively narrows claims over outputs and execution traces; Cannon supplies a fault-proof virtual machine for the final step. Cannon is not a non-interactive whole-dispute system. (Source: OP Stack interactive fault proofs)
• Arbitrum: Its interactive design narrows execution disagreements for on-chain verification, using a different architecture and machine representation.
• BoLD: Arbitrum’s Bounded Liquidity Delay protocol permits parallel challenges and bounds confirmation delay under its assumptions. It was activated on Arbitrum One in February 2025. (Source: Arbitrum BoLD design)
• Proof virtual machines, timers, bonds, participation rules, and emergency powers must be assessed for the particular deployment.

Data Availability and Compression

• A rollup needs sufficient published data for independent state derivation and challenges. Blob availability is time-limited at the base-layer protocol level; operators need appropriate retention and archival arrangements.
• Calldata has byte-dependent gas costs. Actual batch expenses depend on data, compression, gas prices, and the active fee rules.
• Blobs have a separate fee market, not a fixed “one gas per byte” price. They can reduce data costs, but savings fluctuate with demand and how batches are filled.
• Compression and efficient encoding reduce the published footprint; supported techniques vary by rollup.
• Ethereum’s Fusaka upgrade activated PeerDAS in December 2025, supporting further blob-capacity scaling. Future capacity changes should be distinguished from already deployed features.

Bridging and Cross-Chain Communication

• Canonical deposits pass through L1 contracts and the rollup’s derivation process; timing depends on the chain and confirmation requirements.
• Canonical withdrawals follow the deployed proving, dispute, and finalization requirements. “Seven days” is a common approximation, not a universal end-to-end promise.
• Liquidity bridges may offer faster transfers by advancing funds or using alternative verification. They add fees, liquidity constraints, and distinct trust assumptions.
• Canonical messaging systems allow smart contracts on L1 and L2 to send arbitrary messages to each other, enabling cross-chain contract interactions

Advantages & Disadvantages

Risk Management

Liveness and Verifier Requirement

• The security of optimistic rollups depends on at least one honest verifier monitoring the chain and submitting fraud proofs when needed
• Encourage independent operators and implementation diversity where supported. Monitoring alone is insufficient without the ability to submit binding challenges.
• Check who can actually challenge the deployed system and whether those participants are operationally independent.

Sequencer Failure or Censorship

• If the centralized sequencer goes offline, users cannot submit new L2 transactions through the normal channel
• Some rollups support delayed force inclusion through L1. Availability, cost, and timing vary; not every chain has an equivalent escape route or guaranteed immediate withdrawal.
• Decentralized sequencer research is ongoing, with multiple teams exploring shared sequencing, MEV auctions, and committee-based sequencing models

Smart Contract Upgrade Risk

• Rollup bridge contracts are typically upgradeable by a multisig or security council, which could theoretically be compromised to steal bridged funds
• Mitigation: time-locked upgrades, multi-party security councils with geographic and organizational diversity, and progressive decentralization roadmaps
• Users should monitor upgrade proposals and security council membership changes, particularly for high-value positions

Economic Attack Vectors

• An attacker with sufficient capital could potentially submit many invalid state proposals simultaneously, requiring honest verifiers to post bonds for each challenge
• Review the deployed dispute protocol’s delay and bond design. BoLD and OP Stack fault proofs address these issues differently; multiple proof systems should not be assumed active merely because they are proposed.
• Dispute windows must be evaluated alongside data retention, transaction inclusion, and response capacity. A seven-day label alone does not establish security.

Cultural Relevance

Optimistic rollups have contributed to Ethereum’s execution-scaling approach. Their appeal includes familiar tooling and dispute-based settlement, while their limitations continue to motivate protocol improvements.

Optimistic and validity rollups involve different engineering trade-offs. Compatibility, proof costs, latency, and administrative controls should be compared for actual deployments rather than treated as a fixed hierarchy.

The rollup-centric approach assigns substantial execution to separate chains while Ethereum supplies settlement and data availability. Different rollup systems have developed on overlapping timelines.

The cultural impact extends to governance innovation. Optimism’s two-house model and RetroPGF have inspired conversations about how decentralized communities can fund public goods, while Arbitrum’s ARB token launch and DAO formation demonstrated the challenges of decentralized governance at scale.

Real-World Examples

1. Arbitrum One — DeFi Ecosystem Hub

• Scenario: Ethereum DeFi protocols needed a cheaper execution environment to attract retail users priced out by L1 gas fees during the 2021 bull market.
• Implementation: Arbitrum One launched in August 2021 as an optimistic rollup using interactive fraud proofs. Major protocols like Uniswap, Aave, GMX, and Curve deployed on Arbitrum, creating a detailed DeFi ecosystem.
• Outcome: Arbitrum One supports an active application ecosystem. Any comparison of value or activity should identify a date and metric rather than mixing TVL with total value secured.

2. Base — Institutional Adoption of OP Stack

• Scenario: Coinbase develops Base as an Ethereum scaling network with a consumer-facing ecosystem.
• Implementation: Base launched on the OP Stack as an optimistic rollup in August 2023. Coinbase leveraged its brand recognition, fiat on-ramps, and developer relationships to bootstrap the ecosystem. Smart wallet technology and gasless transactions lowered the barrier for mainstream users.
• Outcome: Base demonstrates adoption of a shared rollup software stack. Application growth and daily activity vary over time and do not by themselves establish decentralization or safety.

3. EIP-4844 Impact on Rollup Economics

• Scenario: Publishing transaction data is one component of rollup operating costs and user fees.
• Implementation: Ethereum’s March 2024 Dencun upgrade introduces EIP-4844 blob transactions. Rollup operators adopt the new data path through their own upgrades.
• Outcome: Blobs lower data-publication costs under many conditions, but user fees also depend on execution, demand, operator rules, and data pricing. There is no permanent 90–95% discount across every rollup.

4. External Data Availability: A Different Security Model

• Scenario: A scaling chain chooses an external data-availability service to reduce Ethereum publication costs.
• Implementation: It settles claims on Ethereum while obtaining data availability elsewhere. This differs from a rollup that publishes all derivation data through Ethereum.
• Outcome: The design adds data-withholding and recovery assumptions. Ethereum settlement alone does not give it the same data-availability guarantees as an Ethereum rollup.

Comparison Table

Related Terms

• ZK Rollup — The alternative rollup approach that uses zero-knowledge validity proofs instead of fraud proofs, offering faster finality but requiring more complex cryptographic proof generation.
• Fault Proof — A mechanism for disputing an incorrect execution claim under a deployment’s participation and verification rules.
• Sequencer — Orders L2 transactions; batching and state-claim posting can be separate roles.
• Data Availability — The guarantee that all transaction data needed to reconstruct the rollup state is accessible to any network participant, a fundamental requirement for fraud proof security.
• EIP-4844 — Introduces blob transactions with a separate fee market for data availability.
• Optimism — The leading optimistic rollup implementation using the OP Stack framework, known for its Superchain vision and retroactive public goods funding.
• Arbitrum — An Ethereum scaling ecosystem whose Arbitrum One chain uses Nitro and BoLD.
• Layer 2 Scaling — Systems that move work from a base chain with varying settlement and data-availability assumptions.
• Ethereum Rollup-Centric Roadmap — The Ethereum community’s strategic vision where L1 optimizes for data availability and settlement while rollups handle execution.
• Challenge Period — A configured interval for disputing claims; it is one part of the complete settlement and withdrawal process.
• State Root — A cryptographic hash representing the complete state of the rollup at a given point in time, proposed to L1 for verification.
• Data-Availability Scaling — Upgrades that increase efficient access to rollup data, including deployed PeerDAS and further planned capacity changes.

FAQ

Q: What makes optimistic rollups “optimistic”?

Claims can settle without a validity proof if they satisfy the system’s dispute and confirmation rules. Independent nodes still verify execution, and security requires a capable honest challenger when a false claim appears.

Q: How do optimistic rollups compare to ZK rollups?

Compare actual deployments. Optimistic systems use disputes; validity rollups verify proofs. EVM compatibility, operator costs, settlement timing, upgrade controls, and data availability vary within both categories.

Q: Can optimistic rollups be hacked?

Yes. Bugs, compromised upgrade authority, unavailable data, challenge failures, and bridge vulnerabilities can threaten assets. Native bridges also have contracts and administrative assumptions; using one does not remove most risks automatically.

Q: Why is there a seven-day withdrawal delay?

A waiting period gives eligible participants time to challenge a claim before an exit is finalized. The exact period, proving steps, and additional delays depend on the chain and its current configuration.

Q: What happens if the sequencer goes offline?

Normal sequencing may stop. Some deployments offer L1 force inclusion or other recovery mechanisms, with specific delays and requirements. Check the chain’s actual escape and withdrawal procedures rather than assuming uninterrupted access.

Q: How much cheaper are optimistic rollups compared to Ethereum L1?

Fees vary with transaction type, chain demand, blob prices, and operator parameters. Compare live estimates for the same operation and include bridge costs; historical dollar ranges are not reliable current quotes.

Q: What is the difference between Arbitrum and Optimism’s fraud proof approaches?

Both use interactive dispute mechanisms in their relevant fault-proof designs. OP Stack’s dispute game can use Cannon for execution-step verification; Arbitrum’s BoLD uses its own dispute structure and timing rules. Compare current deployed parameters and permissions, not a non-interactive-versus-interactive label.

Conclusion

An optimistic rollup combines separate execution with dispute-based settlement. Its security and costs depend on the deployed proof system, data availability, honest participation, and administrative controls—not simply a seven-day window or an Ethereum settlement label.

Further reading on UEEx: Ethereum overview; Centralized and decentralized exchanges; Crypto security and risk

Sources

Ethereum optimistic rollup architecture

OP Stack interactive fault proofs

Arbitrum BoLD design

EIP-4844 blob transactions

Fusaka and PeerDAS deployment

Arbitrum Nitro launch