Fraud Proof

What Is a Fraud Proof?

A fraud proof is a cryptographic mechanism that enables any network participant to demonstrate that a state transition was executed incorrectly. Rather than requiring every transaction to be verified upfront, fraud proofs operate on an "innocent until proven guilty" model: computations are assumed correct unless someone provides evidence of an error within a designated challenge period.

The concept was formalized in the 2018 paper "Fraud and Data Availability Proofs" by Mustafa Al-Bassam, Alberto Sonnino, and Vitalik Buterin. The paper demonstrated how fraud proofs combined with data availability sampling could replace the honest-majority assumption for light clients with a much weaker requirement: that at least one honest node exists in the network.

Today, fraud proofs are the foundation of optimistic rollups on Ethereum (Arbitrum, Optimism, Base) and are being adapted for Bitcoin Layer 2 scaling through projects like BitVM. They represent one of two main approaches to rollup verification, the other being validity proofs used in ZK rollups.

How It Works

In an optimistic rollup, a sequencer bundles transactions off-chain and posts compressed transaction data along with a state root (a Merkle root representing the rollup's state) to the Layer 1 chain. The process follows a specific lifecycle:

1. The sequencer executes transactions off-chain and publishes a state commitment (containing the old state root and new state root) to L1
2. The batch enters a challenge period during which any verifier can dispute it
3. Verifiers independently download the posted batch data, re-execute the transactions off-chain, and compare their computed state root with the sequencer's claimed root
4. If a discrepancy is found, a verifier submits a fraud proof on-chain
5. If the fraud proof is valid, the invalid state root is rejected, the sequencer's bond is slashed, and the correct state is restored
6. If no challenge is submitted during the window, the batch is finalized on L1

The Interactive Bisection Game

Re-executing an entire batch of transactions on-chain would be prohibitively expensive. The interactive bisection protocol solves this by narrowing a dispute down to a single computational step through a back-and-forth game between the challenger and the asserter.

1. The challenger and asserter disagree about the output state of a computation comprising N steps
2. The disputed computation is divided in half, and each party indicates which half they disagree on
3. The disputed half is bisected again, repeating until the dispute is narrowed to a single instruction
4. L1 executes that one instruction on-chain using the provided witness data, and the party whose result matches wins

This bisection converges logarithmically: a computation of 1 billion steps requires only about 30 rounds of bisection (log₂(N)), making on-chain verification practical regardless of batch size.

// Simplified bisection game logic
function bisect(claim, start, end) {
  const mid = (start + end) / 2;

  // Each round halves the disputed range
  if (challenger.agreesWith(start, mid)) {
    // Dispute is in the second half
    return bisect(claim, mid, end);
  } else {
    // Dispute is in the first half
    return bisect(claim, start, mid);
  }
  // When start + 1 == end: single-step proof on L1
}

The 7-Day Challenge Period

Major optimistic rollups (Arbitrum One, OP Mainnet, Base) use a 7-day challenge window. This duration accounts for several factors:

• Censorship resistance: the window must be long enough for honest challengers to submit proofs even if hostile block builders temporarily delay transactions
• Social coordination: 7 days provides time for the community to detect issues, coordinate responses, and if necessary, escalate to emergency procedures
• L1 finality assumptions: the period accounts for Ethereum's own finality characteristics and the time required to construct and submit a valid dispute

The 1-of-N Security Model

Fraud proof systems operate under a 1-of-N trust assumption: only one honest verifier in the entire network needs to be active and monitoring for the system to remain secure. This stands in contrast to consensus mechanisms like proof-of-work, which require an honest majority. The honest verifier must be able to access posted batch data, re-execute transactions to detect fraud, and submit the proof on-chain within the challenge window.

Fraud Proofs vs. Validity Proofs

Fraud proofs and validity proofs represent two fundamentally different approaches to rollup verification. Validity proofs (used in ZK-SNARKs and ZK-STARKs) cryptographically prove that every batch is correct before it is accepted, eliminating the need for a challenge period entirely.

Use Cases

Optimistic Rollups

The primary use case for fraud proofs is securing optimistic rollups on Ethereum. Arbitrum One and OP Mainnet together process millions of transactions daily while inheriting Ethereum's security guarantees. In 2025, Arbitrum launched its BOLD (Bounded Liquidity Delay) protocol, achieving permissionless fraud proofs with a three-level recursive challenge structure. Optimism deployed its Cannon fault proof system in June 2024, using a MIPS-based virtual machine that can execute a single instruction on-chain via the MIPS.sol contract.

Bitcoin Layer 2 Bridges

BitVM, introduced by Robin Linus in October 2023, adapts fraud proofs for Bitcoin without requiring any protocol changes. Using Taproot contracts and Bitcoin Script, a prover commits to a computation result by depositing BTC as collateral. Any verifier can challenge the result through a bisection game similar to optimistic rollups.

BitVM2 (August 2024) improved on the original design by enabling permissionless challenging and reducing dispute resolution from approximately 70 on-chain transactions to just 3. This approach maintains the 1-of-N trust model while working within Bitcoin Script's constraints. It is particularly relevant for building trustless bridges between Bitcoin L1 and Layer 2 networks.

Data Availability Verification

Fraud proofs also play a role in ensuring data availability. Light clients can use fraud proofs to verify that block producers have made all transaction data available, without downloading entire blocks. This technique combines fraud proofs with data availability sampling to enable scalable light client verification with minimal trust assumptions.

Why It Matters

Fraud proofs are critical infrastructure for blockchain scaling. By shifting verification from "prove everything correct" to "assume correct unless challenged," they dramatically reduce the on-chain computation needed to secure Layer 2 networks. This makes them a practical path toward scaling blockchains while preserving their security properties.

In the Bitcoin ecosystem specifically, fraud proofs unlock capabilities that were previously thought impossible without consensus-level changes. BitVM's fraud proof model enables trustless bridges and arbitrary computation verification on Bitcoin, expanding what can be built on the Bitcoin Layer 2 landscape. For users of Bitcoin Layer 2 solutions, understanding fraud proofs helps evaluate the security tradeoffs of different scaling approaches.

Risks and Considerations

Delayed Finality

The 7-day challenge period means withdrawals from optimistic rollups take significantly longer than from ZK rollups. While third-party liquidity providers can offer faster withdrawals by fronting funds and absorbing the delay risk, this introduces additional trust and cost. Users must weigh the tradeoff between the lower fees of optimistic rollups and the faster finality of validity proof systems.

Liveness Requirements

The 1-of-N security model assumes at least one honest verifier is online and monitoring during every challenge window. If all verifiers go offline, collude, or are censored from submitting proofs for the entire challenge period, invalid state transitions can be finalized. This is a liveness assumption, not a safety guarantee: the system's security depends on continuous participation rather than purely on cryptographic proofs.

Bond and Capital Requirements

Submitting fraud proofs typically requires posting a bond as collateral. In Arbitrum BOLD, assertion bonds are 3,600 ETH and challenge bonds total 1,110 ETH. In Optimism's fault proof system, initial claims cost 0.08 ETH but scale upward at each depth level. These capital requirements can limit who can participate as a challenger, creating a tension between security (higher bonds deter frivolous challenges) and decentralization (lower bonds enable broader participation).

The Fraud Proof Trilemma

Analysis by L2BEAT identifies three competing objectives that no current fraud proof system fully satisfies simultaneously: safety (resource efficiency favoring honest defenders), promptness (fast settlement), and decentralization (low bond requirements enabling broad participation). Different implementations make different tradeoffs: Arbitrum BOLD prioritizes safety, Optimism's fault proofs optimize for promptness, and newer designs like Cartesi Dave target decentralization with approximately 1 ETH bonds.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.