Fraud Proof

A fraud proof is a piece of evidence that shows a blockchain, or the nodes that verify it, that a claimed result is incorrect. The idea is used mainly by optimistic rollups, which post summaries of their transactions to a base layer such as Ethereum and assume them to be valid unless someone proves otherwise within a set challenge window. If a fraud proof succeeds, the false result is thrown out and the party that posted it loses a deposit.

Fraud proofs are also called fault proofs, a term some projects prefer because errors need not be deliberate. They are one of two main ways to secure rollups. The other is the validity proof used by ZK-rollups, which proves every batch correct in advance using zero-knowledge proofs. The fraud-proof approach is cheaper to run day to day but makes users wait longer before withdrawals to the base layer are final.

Imagine a club treasurer who posts the month's accounts on a noticeboard. Nobody checks every line in advance. Instead, any member can object within a week, and if they show a mistake, the accounts are corrected and the treasurer pays a fine. Because cheating would probably be caught and punished, the treasurer has every reason to be honest.

A fraud proof is that objection. On an optimistic rollup, an operator posts the results of many transactions to Ethereum. Anyone watching can re-run the transactions; if the numbers do not match, they submit a fraud proof. As long as at least one honest watcher is paying attention, wrong results cannot stand.

1. A rollup operator, often called a sequencer or proposer, collects transactions, executes them off-chain and posts the transaction data and a claim about the new state to the base chain, together with a bond.
2. The claim enters a challenge period, commonly about seven days on major rollups.
3. Independent verifiers download the data, re-execute the transactions and compare their result with the claim.
4. If they disagree, a verifier opens a dispute by posting its own bond. The base chain's smart contracts then settle who is right.
5. The losing side forfeits its bond. If no challenge succeeds before the window closes, the claim becomes final.

Early designs proposed re-running a whole batch on the base chain, which is expensive. Most production systems use interactive fraud proofs: the two sides repeatedly split the disputed computation in half until they isolate a single step they disagree on, and only that one step is executed on-chain. This makes disputes cheap enough to run on Ethereum.

Large optimistic rollups such as Arbitrum and those built on the OP Stack, including Optimism, rely on fraud proofs. For several years after launch, some systems limited who could submit proofs or kept powerful upgrade controls in the hands of their teams, which meant users still had to trust the operators. Optimism introduced permissionless fault proofs on its main network in 2024, and Arbitrum has also moved to a dispute system open to anyone. Independent trackers rate rollups on how far their proof systems are live and permissionless, since a fraud-proof design only protects users if it is actually switched on.

Fraud proofs also appear outside rollups. Some proposals for data availability sampling and for light clients let nodes that do not check every transaction rely on full nodes to alert them with a fraud proof if a block is invalid.

• Withdrawal delays. The challenge period means withdrawals from an optimistic rollup to the base chain usually take about a week, unless users pay a third-party bridge for faster exits, a role described under liquidity provider.
• Need for watchers. Security depends on at least one honest party monitoring the chain and being able to submit a proof in time.
• Data availability. Verifiers can only spot fraud if the transaction data has been published; if it is withheld, no proof can be built.
• Censorship and delay attacks. An attacker who could stop challenges reaching the base chain, or who forced many disputes at once, might try to run out the clock; challenge windows are sized with this in mind.

Because validity proofs avoid the waiting period, some optimistic rollups have explored adding zero-knowledge proofs over time. Both approaches aim to let a layer 2 network inherit much of the security of its base layer while helping to ease the blockchain trilemma.