Skip to content
Financial Context Wiki

Fault Proof (Fraud Proof)

A deployment-aware guide to optimistic fault proofs, disputed claims, trace bisection, single-step verification, clocks, bonds, data availability, withdrawal finality and operational verification.

Updated

For educational purposes only; not investment or security advice. Fault-proof safety depends on the exact deployment, data availability, challenger permissions and liveness, clocks, bonds, verifier software, governance, settlement finality and withdrawal contracts.

Direct answer

A fault proof, often called a fraud proof, is a protocol process for contesting an optimistic claim about computation or state. The claimant does not prove every transition before acceptance; instead, an eligible challenger can present a conflicting trace during defined clocks, and the settlement contract resolves the disagreement under a specified verifier. Many interactive designs repeatedly narrow a long trace to one disputed instruction and execute that base case on-chain.

The name does not prove that a deployed system is permissionless, live or safe. Security requires the exact derivation data to be available, at least one correct challenger to reconstruct the claim and act in time, sufficient settlement-chain access and gas, correct proof programs and contracts, and governance that cannot bypass the result. A claim that survives its game may authorize a withdrawal under that deployment’s rules; it does not retroactively prove every L2 transaction, frontend statement or economic outcome.

1
Sequence

The sequencer orders L2 transactions and publishes transaction data or commitments.

How it works

  1. Pin the deployment: L1 and L2 chain IDs, rollup and fault-proof versions, block hashes, factory, portal or bridge, proof program, VM, game type, implementation and admin addresses, permission model, bonds, maximum depth, clocks, maturity delays, pause state and finality policy. The label fraud proof is not a cross-rollup specification.
  2. Reconstruct the claim from authenticated inputs. Record the anchor state, L1 head, disputed L2 block or output root, batch and blob data, chain and rollup configuration, pre-state, withdrawals root and exact derivation rules. A state root alone is not enough to reproduce the transition, and unavailable data can defeat an otherwise open challenge path.
  3. Verify the game was created and can affect the intended object. Check the root claim, claimant, creation block and time, game type, respected or blacklisted status, bond, challenger eligibility and the portal’s actual acceptance rule. Separate a pending claim, a game result and a withdrawal-ready output.
  4. Re-execute with an independent node and fault-proof implementation. Compare the honest trace with every disputed claim and preserve preimages, state witnesses and client versions. In an interactive game, attack or defend the correct interval until the maximum depth identifies a single instruction; then submit the base-case witness to the on-chain VM verifier.
  5. Track each team’s clock and every transaction. Record remaining time, extensions, L1 inclusion and reorganization risk, calldata, gas, replacement, bond exposure, parallel claims and who must respond. Wall-clock challenge duration is not necessarily one fixed countdown, and an honest result can still be lost through a missed move or censored transaction.
  6. Map resolution to protocol consequences. Determine which claims are countered, which team wins, how bonds and costs are distributed, whether an invalid output is excluded, and whether dependent outputs, proofs or withdrawals must be rebuilt. A slashed bond is an incentive, not compensation for every possible bridge loss.
  7. Reconcile finality and withdrawals separately. Verify game resolution, required proof-maturity and post-resolution delays, respected game type, blacklist and pause checks, withdrawal inclusion proof, finalization receipt and L1 finality. Archive the data and evidence, monitor upgrades, and rehearse challenger, forced-inclusion, re-proving and emergency-exit procedures.

Worked examples

  • Trace bisection. A teaching trace has 1,048,576 = 2^20 instructions. If each uncontested round halves the disputed interval, 20 bisections isolate one instruction because 2^20 / 2^20 = 1. Real games may split output and execution traces, branch into a DAG or require extra moves, so this is a complexity example rather than a deployment round count.
  • Independent game clocks. A hypothetical game gives each team 84 hours. The defender consumes 30 hours and the challenger consumes 22 hours, leaving 54 hours and 62 hours respectively. The elapsed wall time is not simply 84 hours: only the applicable team’s clock advances, and protocol-defined extensions, inclusion delays and parallel claims can change the deadline.
  • Bond and gas ledger. Under an explicitly hypothetical rule, an invalid root carries a 2 ETH bond. The winning challenger posted 0.5 ETH, receives that deposit back plus a 1.4 ETH reward, and spent 0.08 ETH on L1 gas; 0.6 ETH of the losing bond goes to a treasury. Challenger net gain is 1.4 - 0.08 = 1.32 ETH; the returned 0.5 ETH is principal, not profit, and 1.4 + 0.6 = 2 ETH. Actual bond recipients and freeloader behavior are contract-specific.
  • Withdrawal clocks. Suppose a withdrawal is proved on 2026-08-01 12:00 UTC, its configured proof-maturity delay is 7 days, the relevant game resolves on 2026-08-06 18:00 UTC, and the post-resolution air gap is 1 day. The two gates end at 2026-08-08 12:00 UTC and 2026-08-07 18:00 UTC; the earliest time satisfying both is 2026-08-08 12:00 UTC. With an additional 20 minutes of L1-finality policy, economic completion is 2026-08-08 12:20 UTC, assuming no pause, blacklist, re-proof or reorganization.

Risks

  • Auditing the wrong L1, L2, deployment, game type or contract version.
  • Reconstructing from a stale, noncanonical or wrong anchor and L1 head.
  • Missing batch, blob, preimage, state-witness or configuration data.
  • Assuming a commitment or available proof input makes all derivation data available.
  • Challenger software deriving a different honest trace because of a client bug.
  • Fault-proof program, VM, preimage oracle or on-chain step-verifier bugs.
  • A permissioned proposer, challenger or game-creation path being unavailable or captured.
  • No honest watcher detecting and opening a dispute before the relevant deadline.
  • Censorship, L1 congestion, reorganization or gas spikes preventing a timely move.
  • Misreading chess clocks, extensions, maximum depth or transaction inclusion time.
  • Attacking or defending the wrong claim, trace interval, position or instruction.
  • Bond requirements or working capital making permissionless participation impractical.
  • Bond-distribution, freeloader or incentive behavior diverging from safety assumptions.
  • Multiple games, duplicate claims or conflicting implementations resolving unexpectedly.
  • Governance changing the respected game type, verifier, threshold or delay.
  • Guardian pause or blacklist powers blocking otherwise valid withdrawals.
  • Treating game resolution as immediate withdrawal or settlement finality.
  • Proving a withdrawal against an invalidated game and failing to re-prove it.
  • Assuming invalid-output rejection repairs every downstream application or bridge effect.
  • Extrapolating one optimistic rollup’s proof and finality model to another system.

Common misconceptions

  • An unchallenged optimistic claim has been cryptographically proven correct.
  • Anyone can challenge every deployed system without permission, capital or infrastructure.
  • A fault proof works even when the derivation data is unavailable.
  • Winning a dispute instantly finalizes every dependent withdrawal and reimburses all losses.
  • A seven-day challenge period, binary game and one honest observer are universal rollup constants.

Sources

Navigation

Search the wiki...