Fault proofs

Fault proofs are how OP Stack chains secure withdrawals without a trusted third party: anyone can propose the state of the chain on Ethereum, and anyone can challenge a proposal they believe is wrong. A dispute is narrowed down, through a bisection game, to a single instruction of execution, and that one instruction is proven on Ethereum inside an onchain virtual machine. This page is the recommended reading order for the whole topic. Start with the explainer for the mental model, work through the component pages to see how the pieces fit, then use the hands-on guides if you operate a chain or want to run a challenger. The bond economics and the normative spec close the loop for readers who need full depth. Every stop is an existing page; nothing here replaces them.

​

Start here

• Fault proofs explainer: read this first for the mental model, covering permissionless proposals, permissionless challenges, and the Guardian backstop behind both.

​

Go deeper

• FP system components: the three modules of the system (fault proof program, fault proof virtual machine, dispute game protocol), why they are decoupled, and why kona-client is the default fault proof program today.
• Fault proof VM: Cannon: the default fault proof virtual machine, split between the onchain MIPS64.sol contract and the offchain mipsevm Go implementation.
• Fault proof VM: MIPS64.sol: the onchain half at instruction level, an EVM implementation of the multithreaded 64-bit MIPS instruction set.
• OP-Challenger explainer: how the honest actor detects faults, and how it defends valid proposals and counters invalid claims move by move.

​

Get hands-on

• Run a fault-proof challenger: the end-to-end path to a challenger that defends a chain, from bond budgeting and prestate selection through infrastructure, configuration, and monitoring.
• How to configure challenger for your chain: the per-flag configuration walkthrough behind that path.
• Challenger configuration reference: the full catalogue of op-challenger flags, environment variables, and defaults to keep open while you configure.
• Generating absolute prestate and preimage files: build and verify the kona-client absolute prestate that anchors every dispute for your chain.
• Migrating to permissionless fault proofs: move a chain from the permissioned dispute game to permissionless fault proofs in four phases.
• Chain monitoring options: run op-dispute-mon, the security monitoring service that tracks the status of every game over the last 28 days.

​

Economics and incentives

• Fault proofs explainer FAQs: what proposals cost a chain operator to run and how bonds are sized to deter invalid claims.
• OP-Challenger explainer FAQs: what the bond does, how much ETH a full-depth game can require, and the infrastructure questions (like blob retention) that decide whether you can win.

​

The normative spec

The definitive definition of fault proof behavior lives in the OP Stack specifications:

• Fault proof: the fault proof program and the pre-image oracle it reads from.
• Fault dispute game: the game itself, including bisection, clocks, and resolution.
• Honest challenger: the behavior an honest challenger must implement, which op-challenger follows.
• Bond incentives: the normative bond economics behind the FAQ answers above.
• Multithreaded Cannon fault proof VM: the specification of the FPVM that Cannon implements.

​

Audits and security

• Fault proofs security: the security model and its safeguards, including the Guardian role, game blacklisting, the global pause, and delayed bond payouts through DelayedWETH.
• Audit reports: the standing index of OP Stack security reviews, which routes to the full list in the monorepo.