Fault Proof

Overview

A fault proof, often called a fraud proof, is used by optimistic rollups to challenge an incorrect state commitment. A challenger supplies evidence or participates in an interactive dispute that narrows execution to the disputed step for verification on the settlement layer. The system assumes claims are valid unless challenged within a defined window. Security therefore depends on published data, at least one honest and capable challenger, correct verifier contracts, and enough time to respond. Proof systems vary across rollups.

Bridges and payment platforms should understand challenge periods, proof maturity, upgrade controls, and the difference between sequencer confirmation and settled finality. Operators need monitoring and resources to submit challenges. Users should not assume every optimistic rollup has identical or fully permissionless fault-proof deployment.

Fault Proof should be described through its execution, sequencing, data-publication, proof or challenge, bridge, and settlement stages. A transaction accepted by a sequencer has not necessarily been published, proven, finalized on the base layer, or made withdrawable. A cryptographic proof can reduce execution trust while leaving censorship, data, governance, and contract risks. The security model for Fault Proof includes sequencer control, proof or fault-resolution rules, data availability, bridge contracts, upgrade keys, and the base-layer verifier.

Payment applications using Fault Proof should maintain separate states for local acceptance, batch publication, proof verification or challenge completion, bridge execution, and base-layer finality. Fulfillment and withdrawal policies should use the stage that matches the business risk. Users should have a documented route to recover or exit when the preferred sequencer, prover, or interface is unavailable. Operational support needs monitoring for sequencer outages, delayed batches, proof failures, forced-inclusion paths, contract pauses, and upgrade events.