Fault Proof
Pronunciation: FAWLT PROOF
Definition
A fault proof demonstrates that a claimed rollup state transition is invalid, allowing the settlement system to reject or correct the disputed result. 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.
Overview
Meaning and scope
A fault proof demonstrates that a claimed rollup state transition is invalid, allowing the settlement system to reject or correct the disputed result. 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.
Mechanism and operation
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. 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.
Practical payment example
A rollup observer challenges a disputed state transition using the system’s fault-proof process rather than trusting the sequencer’s assertion.
Operational checks
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.
Distinctions and limits
Bridges and payment platforms should understand challenge periods, proof maturity, upgrade controls, and the difference between sequencer confirmation and settled finality. Users should not assume every optimistic rollup has identical or fully permissionless fault-proof deployment. Fulfillment and withdrawal policies should use the stage that matches the business risk.
Related reading
Related definitions: optimistic rollup.
Example
A rollup observer challenges a disputed state transition using the system’s fault-proof process rather than trusting the sequencer’s assertion.
Comparison
Security therefore depends on published data, at least one honest and capable challenger, correct verifier contracts, and enough time to respond. Bridges and payment platforms should understand challenge periods, proof maturity, upgrade controls, and the difference between sequencer confirmation and settled finality.
Key Takeaway
Fault proofs secure optimistic claims through challenge, making data availability, honest monitoring, verifier correctness, and dispute timing essential.
Sources
- Ethereum Documentation: Scaling — Ethereum Foundation (2026-07-30)
- Ethereum Documentation: Zero-Knowledge Proofs — Ethereum Foundation (2026-07-30)