What Is a Fault Proof System? Arbitrum and Optimism Compared

A fault proof system is the mechanism optimistic rollups use to let anyone on the network challenge and prove that a submitted transaction batch is invalid, allowing the chain to reject fraudulent state updates without requiring every single transaction to be proven correct upfront the way a ZK-rollup's validity proofs do.

Why optimistic rollups need fault proofs

Optimistic rollups get their name from their core assumption: transactions are assumed valid by default ("optimistically" accepted), and only get scrutinized if someone actually challenges them. This is different from ZK-rollups, which generate a cryptographic proof of correctness for every batch before it's accepted.

This design means optimistic rollups need a robust way for outside parties to catch and prove fraud when it happens, since there's no upfront cryptographic guarantee. That's the job of the fault proof (also called fraud proof) system: a mechanism, plus a challenge period during which anyone can submit a proof showing a specific batch was processed incorrectly.

How a fault proof dispute typically works

Rather than requiring a challenger to re-execute and prove an entire disputed batch at once (which would be prohibitively expensive), most modern fault proof systems use an interactive, step-by-step process: the challenger and the original submitter narrow down their disagreement through several rounds, each time bisecting the disputed computation into smaller pieces, until they isolate the exact single step where they disagree. That one step is then executed directly, on-chain, in a way cheap enough to verify — resolving who was right and, if fraud is confirmed, reverting the invalid batch.

This interactive approach is why the challenge period matters: it needs to be long enough to allow this dispute process to fully play out, which is part of why optimistic rollup withdrawals often take about a week, as covered in our piece on transaction finality.

Arbitrum's BOLD vs. Optimism's Cannon

Both major optimistic rollup ecosystems have developed their own fault proof implementations:

• Arbitrum's BOLD (Bounded Liquidity Delay) is designed to allow permissionless, multi-party disputes with a fixed, predictable time bound, aiming to let anyone — not just a small, permissioned set of validators — participate in challenging fraudulent state.
• Optimism's Cannon is a fault proof system built around a custom MIPS-based virtual machine that allows disputed computation to be executed and verified step by step on-chain, also aiming for permissionless participation in the challenge process.

Both systems share the same underlying goal — permissionless, economically bounded fraud challenges — but differ in their specific technical implementation and virtual machine design.

Why "permissionless" fault proofs matter

Many optimistic rollups launched with fault proof systems that were live in theory but only usable by a small, permissioned set of trusted validators in practice — meaning ordinary users technically couldn't submit a challenge themselves, even if they detected fraud. Moving to fully permissionless fault proofs, where anyone can submit a valid challenge, is considered an important decentralization milestone, since it removes reliance on a specific trusted party to police the chain's honesty.

Fault proofs vs. validity proofs

Aspect	Fault (fraud) proofs — optimistic rollups	Validity proofs — ZK-rollups
Default assumption	Transactions assumed valid unless challenged	Transactions cryptographically proven valid upfront
Finality delay	Longer (challenge period, often ~7 days)	Shorter (proof generation/verification time)
Computational cost	Lower ongoing cost, cost only on dispute	Higher upfront cost (proof generation)
Permissionless challenge requirement	Essential for security model	Not needed — proof is checked directly

What this means for evaluating a chain

When assessing an optimistic rollup, check whether its fault proof system is actually live and permissionless, or still in a "training wheels" phase where only a permissioned set can challenge fraud — a status often paired with a security council that can override the chain in the meantime. A chain without live, permissionless fault proofs is relying more heavily on trusted parties than its long-term design intends.

Economic incentives for challengers

For a fault proof system to work in practice, there needs to be a real economic incentive for someone to actually go through the effort of monitoring the chain and submitting a challenge when they spot fraud, since running this infrastructure isn't free. Most designs include a bonding and reward mechanism: a party submitting a batch typically posts a bond that can be slashed if they're proven wrong, and a successful challenger is often rewarded from that slashed bond, creating a direct financial incentive to police the network. Without this incentive structure, a fault proof system could be technically live but practically unused, since no one would have a reason to bear the cost of constant vigilance and potential dispute resolution otherwise.

What happens during an actual dispute, end to end

Walking through a full dispute end to end: a challenger identifies a batch they believe was processed incorrectly and initiates a challenge, posting their own bond. The interactive bisection process then plays out over several rounds, each narrowing down exactly where the disagreement lies, until a single computational step is isolated. That step gets executed directly on the base layer, which definitively resolves who was correct. If the original submitter was wrong, their bond is slashed (with the challenger typically rewarded from it), and the invalid batch is reverted, protecting the chain's users from the fraudulent state update that would otherwise have gone through unchallenged.

Bottom line

Fault proof systems are what let optimistic rollups operate on an "innocent until proven guilty" model, using an interactive dispute process to isolate and verify exactly where a disagreement lies rather than requiring every transaction to be proven correct upfront. Arbitrum's BOLD and Optimism's Cannon are the two leading real-world implementations of this idea, both aiming for permissionless participation. Before trusting a specific optimistic rollup with significant funds, check whether its fault proof system is genuinely live and open to anyone, not just a small permissioned set of validators.