Fault proofs (also called fraud proofs) are the cryptographic enforcement mechanism that makes optimistic rollups trustless. Any network participant can submit a challenge when a sequencer posts an incorrect state root. If the challenge succeeds onchain, the bad state root is rejected and the challenger is rewarded. Without this mechanism, users must trust rollup operators never to lie.
​

Optimistic rollups get their name from an assumption: transaction batches posted to Ethereum are assumed valid unless someone proves otherwise. The fault proof system is what enforces that assumption. It means the protocol itself, not an operator's good intentions, guarantees that only honest state transitions are finalized.
​

Fault proofs are distinct from zero-knowledge proofs, which prove correctness upfront. A fault proof proves incorrectness after the fact, during a defined challenge window. Both approaches aim at the same goal: users should not have to trust any single party to keep their funds safe.
​

The term "fraud proof" appears frequently in early Ethereum research literature. The Optimism and Arbitrum teams largely adopted "fault proof" as a more precise label because the mechanism detects computational faults, not just intentional fraud. The two terms refer to the same underlying construct and are used interchangeably across the industry. For more context on rollup architectures that depend on this mechanism, see What Is a Rollup.
​

External reference: Ethereum's documentation covers the foundational role of fraud proofs in optimistic rollup design.
​

When a sequencer posts a batch to Ethereum, a state root is recorded: a compact hash representing the entire rollup state after that batch executes. Anyone watching can re-execute the same transactions locally. If their computed state root differs from the posted one, they can open a dispute. The challenge window, typically seven days, is the interval during which disputes must be filed. After it closes with no successful challenge, the state root is finalized.
​

The seven-day window is not arbitrary. Ethereum's finality assumptions and the time required to source and submit a valid dispute transaction informed the choice. A shorter window would disadvantage honest challengers operating in different time zones or with slower infrastructure. A longer window would make withdrawals impractically slow.
​

Opening a dispute triggers what is called the dispute game. The challenger and the proposer (or a defender standing in for the protocol) take turns making claims about what the correct state should be at a given point. Neither party can simply say "your entire output is wrong"; they must narrow down exactly where the disagreement occurs.
​

This narrowing process is bisection. Each round halves the disputed execution trace. If a batch processes 10,000 steps, the first round identifies whether the disagreement is in steps 1-5,000 or 5,001-10,000. The next round halves again. After roughly 13 rounds of bisection on a 10,000-step trace (log base 2), the dispute collapses to a single instruction. The contract then executes that one instruction onchain and checks whose claim it matches.
​

This final step is the one-step proof: the entire dispute resolves by running a single computational step inside a smart contract. Because one step is cheap, the protocol never has to re-execute an entire batch on Ethereum mainnet, which would be prohibitively expensive.
​

If the challenger's claim about that single instruction matches the onchain execution, the challenger wins. The original state root is rejected, the proposer's bond is slashed, and the challenger receives a portion of that bond as a reward. If the proposer wins, the challenger loses their bond.
​

Bond requirements exist on both sides to prevent spam disputes that would congest the system. The economics are designed so that honest challengers always expect a positive return when they find a real fault, and bad-faith challenges are costly to file.
​

L2Beat tracks which rollups have live, permissionless fault proof systems and which still rely on trusted operator multisigs. Their scaling summary is the most frequently updated public reference for this status.
​

Both fault proofs and zero-knowledge proofs solve the same core problem: how does Ethereum know a rollup state root is correct without re-executing every transaction? The approaches differ fundamentally in timing, computational cost, and the trust assumptions they require during the period before finality. Neither is universally superior; the choice involves real engineering tradeoffs.
​

The table below compares the two approaches across the dimensions that matter most for rollup security and user experience.
​

One nuance worth noting: "optimistic" does not mean naive. The security of an optimistic rollup with a live fault proof system is equivalent to Ethereum's own security assumptions, as long as a single honest and economically rational party monitors the chain. The ZK approach removes the liveness requirement but demands that the ZK circuit itself is correct, which introduces a different, less visible category of risk.
​

For a deeper look at the cryptographic foundations underlying ZK proofs, see What Is a Cryptographic Proof.
​

The Ethereum Foundation's research blog has a detailed treatment of the tradeoffs between scaling approaches.
​

Bisection is the mechanism that makes fault proofs economically viable. Without it, resolving a dispute would require replaying an entire batch onchain, which could cost millions of dollars in gas. Bisection reduces the problem to a single computational step, making dispute resolution affordable and practical regardless of batch size.
​

In each round of bisection, both parties commit to a claim about the state of execution at the midpoint of the disputed range. Because both claims are hashed commitments, neither party can revise their position after seeing the other's. The smart contract compares the two midpoint commitments. If they agree on the midpoint, the dispute lies in the second half. If they disagree, the dispute lies in the first half. The next round focuses on that half.
​

This continues until the disputed range is a single step: one EVM instruction, one memory write, one opcode execution. The contract then runs that step and declares a winner. The entire dispute is resolved without re-executing the batch.
​

Arbitrum and Optimism have taken different implementation paths for this protocol.
​

Arbitrum's multi-round approach uses a system called BoLD (Bounded Liquidity Delay), introduced after several iterations of their interactive dispute game. BoLD allows multiple parties to participate in a dispute simultaneously, which prevents a class of delay attacks where a bad actor files many disputes purely to stall finality. Arbitrum's approach runs bisection over their custom AVM (Arbitrum Virtual Machine) instruction set, which is compiled from EVM bytecode. See What Is Arbitrum for full context on their architecture.
​

Optimism's Cannon VM is a MIPS-based virtual machine designed to execute a single EVM instruction inside a Solidity smart contract. The key design choice: Cannon compiles Ethereum's Go client (go-ethereum) into MIPS, so the dispute runs the same execution environment Ethereum nodes use. This makes the one-step proof verifiable by any Ethereum node without requiring a custom VM. More on Optimism's overall architecture in What Is Optimism.
​

The role of honest verifiers matters throughout this process. The bisection game only resolves correctly if at least one participant is willing to challenge a false claim at each round. This is the liveness assumption embedded in fault proof systems. If all potential challengers go offline simultaneously, a dishonest proposer could win by default. This is not a theoretical concern; it is why rollup teams run their own challenger nodes and why some projects have granted permission to a small set of whitelisted challengers during initial deployment phases.
​

Arbitrum's BoLD documentation is a useful technical reference for understanding how multi-party dispute games handle this liveness challenge: BoLD Technical Deep Dive.
​

L2Beat's Stage framework is the most widely cited rubric for evaluating how much a rollup relies on human trust versus code. Fault proofs are the central mechanism that separates Stage 0 rollups (trusted operators) from Stage 1 and Stage 2 (code-enforced security). Understanding where a rollup sits in this framework directly affects what risks users accept when bridging assets.
​

Stage 0 rollups post data to Ethereum but do not have a live, permissionless fault proof system. Security relies on a multisig or a small set of permissioned parties who can override the state. Most rollups launched at Stage 0 with the intention of adding fault proofs later. Stage 0 is not fraudulent; it is an honest description of the trust model.
​

Stage 1 requires a live fault proof system that anyone can participate in, a security council with strict limitations on what overrides are permitted, and a minimum delay on upgrades. Reaching Stage 1 means the code, not the team, enforces correctness under normal conditions. The security council acts as a backstop only for critical bugs, not routine operation.
​

Stage 2 removes nearly all training wheels. Upgrade delays must be long enough that users can exit before any change takes effect, the security council's override powers are eliminated or near-eliminated, and the dispute game is fully permissionless with multiple independent challenger implementations.
​

As of early 2026, Arbitrum One reached Stage 1 after deploying BoLD. Optimism's OP Mainnet reached Stage 1 after shipping Cannon and the permissionless fault proof system in 2024. Most other OP Stack chains and newer rollups remain at Stage 0, either because they are still developing their dispute systems or because they are waiting to verify their implementations before removing training wheels.
​

The practical implication for users: a Stage 0 rollup's 7-day withdrawal window does not provide the same guarantee as a Stage 1 rollup's 7-day window. At Stage 0, the window is an interface convention, not an enforced property. At Stage 1, it is enforced by a smart contract that no single party can override.
​

L2Beat publishes live stage ratings for every tracked rollup: L2Beat Scaling Summary.
​

Building a fault proof system that is both correct and safe to deploy without training wheels is significantly harder than building one that works in a lab setting. The gap between "we have a dispute game" and "we removed the security council override" reflects real engineering risk that rollup teams have been cautious to address before proceeding.
​

Invalid state root bugs are the most straightforward risk: a bug in the proposer code produces an incorrect state root, which an honest challenger must catch and dispute. The concern is whether the challenge infrastructure is live, incentivized, and fast enough to catch faults before the window closes. If challenger software has its own bugs, a valid fault could go unchallenged.
​

Dispute game contract bugs are more dangerous. If the smart contract that resolves disputes has a flaw, an attacker could win a dispute they should lose, or prevent a valid challenger from winning. This is a category of risk that does not exist in ZK systems, where the proof verifier is simpler and more easily audited. Optimism's pre-launch security reviews ran for over a year partly because of how difficult it is to fully verify a dispute game contract.
​

Prover liveness is the coordination problem described above. During the initial deployment of Optimism's fault proof system in 2024, the team ran permissioned challengers before opening participation to all. This was an explicit acknowledgment that the liveness assumption needed to be verified in production before removing the fallback.
​

The OP Stack fault proof launch in mid-2024 was a meaningful milestone: it was the first time a major rollup shipped a permissionless fault proof to mainnet where any address could submit a dispute bond and open a challenge. The system ran alongside a security council that retained the ability to override outcomes during an initial observation period, with the council's powers intended to decrease as the system proved reliable.
​

One underappreciated challenge: testing fault proofs requires adversarial conditions that are hard to simulate in testnets. The economics of dispute games only work correctly when bonds are real and the cost of spam is real. Testnet deployments have consistently missed issues that only appeared under mainnet conditions.
​

The OP Stack documentation covers the fault proof architecture in detail: Fault Proofs Overview.
​

For most users, fault proofs are invisible infrastructure. Transactions confirm fast, fees are low, and nothing obviously signals that a dispute game is available. But fault proofs determine whether the assets users hold on a rollup are backed by Ethereum's security or by the good intentions of an operator team. That distinction becomes relevant the moment something goes wrong.
​

The 7-day withdrawal window is the most visible consequence. When a user initiates a native bridge withdrawal from OP Mainnet or Arbitrum One, the funds are locked for seven days before they appear on Ethereum. This delay exists because the protocol must wait for the challenge window to close before treating the state root as final. The withdrawal is initiated in a specific state root; if that root is disputed and overturned, the withdrawal cannot be honored from that root.
​

Users who need immediate access to funds can use third-party liquidity bridges. These services front the funds on Ethereum immediately and collect the rollup-side funds after the window closes. They charge a fee that reflects the cost of capital and the risk they accept. Fault proofs do not eliminate the 7-day window; they are the reason liquidity bridges can charge a lower fee than the 7-day wait implies, because the bridges can assess the risk of the state root being overturned.
​

Bridge security depends directly on fault proofs. The canonical bridge between a rollup and Ethereum is only as secure as the mechanism that validates state roots. A rollup without a live fault proof system means the bridge's security rests on a multisig. Fault proofs replace that trust with code: the bridge contract will not release funds unless the state root has survived the challenge window without a successful dispute.
​

Trust minimization in practice means users do not have to monitor the rollup themselves. If anyone, anywhere, with sufficient bond capital is monitoring the chain and willing to challenge faults, the system is secure. This is a public good: one honest challenger protects all users. The bond reward structure is designed to make challenging profitable enough that rational actors will do it even without altruistic motivation.
​

Understanding rollup architecture helps users make informed decisions about which chains they use and which bridges they trust. Both What Is Arbitrum and What Is Optimism cover how each team has implemented these protections in production. The Optimism developer docs provide additional detail on the withdrawal flow and finality guarantees.
​

Nothing substantive. "Fraud proof" is the older term used in early Ethereum research; "fault proof" is the term Optimism and Arbitrum adopted for production systems. Both describe the same construct: a mechanism that lets any party prove onchain that a rollup state root is incorrect. The terminology shift reflects precision rather than a change in the underlying design.
​

No. Fault proofs protect against invalid state roots, meaning they prevent operators from stealing funds by posting incorrect state. They do not protect against sequencer censorship (refusing to include transactions), data availability failures, or bugs in the dispute game contract itself. Each risk category requires its own mitigation, which is why rollup security frameworks evaluate multiple dimensions simultaneously.
​

Seven days is a convention, not a mathematical requirement. It reflects a judgment about how much time honest challengers need to detect a fault, assemble a bond, and submit a challenge transaction, while accounting for network congestion and time zones. Ethereum's own finality guarantees informed the lower bound. Some research proposals suggest shorter windows are possible with improved tooling, but no major rollup has deployed one yet.
​

Your withdrawal is tied to a specific state root. If that state root is under active dispute, the bridge contract will not release funds until the dispute resolves. If the state root is overturned, your withdrawal is invalidated and must be resubmitted from a correct state root. This edge case is rare; no major rollup withdrawal has been invalidated by a successful challenge on mainnet as of early 2026.
​

No. Many rollups built on the OP Stack or other optimistic architectures remain at Stage 0, meaning they post data to Ethereum but use a permissioned multisig rather than a live fault proof system for state root validation. Arbitrum One and OP Mainnet have live permissionless fault proofs. L2Beat's stage ratings page lists the current status for every major rollup and is updated when deployments change.
​