Optimistic Rollup Fault Proof Games: How Disputes Work

Updated on Oct 25, 2026

10 min read

Optimistic rollup fault proof games are the dispute mechanism that lets participants challenge a proposed Layer 2 state instead of trusting its publisher. They matter most when users withdraw assets to Ethereum: the bridge needs a way to reject a false state claim before treating it as final. This explainer focuses on the OP Stack design, whose interactive game separates a claim about chain state from the program and virtual machine used to check it. Other optimistic rollups use their own contracts and dispute protocols, so the details are not interchangeable.

What Are Optimistic Rollup Fault Proof Games?

A fault proof game is an onchain dispute over whether a proposed rollup state follows from the chain’s published inputs. A proposer posts a claim, such as an output representing the L2 state at a particular point. Another participant who believes that claim is wrong can enter the dispute. The participants then narrow their disagreement until the protocol can check a small, concrete computation.

The OP Stack fault proofs explainer describes this as permissionless proposals and challenges about the state of an OP Stack chain. The Optimism project uses the OP Stack across its ecosystem, but the system’s guarantees still depend on the chain’s specific configuration and security controls.

The name can be confusing. A fault proof is not necessarily a single cryptographic object produced in advance and submitted with every block. In the OP Stack, the dispute protocol coordinates claims and counterclaims; an execution trace and a fault-proof virtual machine let the game resolve the contested step. The normative fault proof specification defines the program, VM, pre-image oracle, and interactive game interfaces.

The Problem Fault Proof Games Solve

Rollups execute transactions away from Ethereum to reduce the cost of using the base layer. They still need to publish enough data for independent parties to reconstruct the L2 chain and check its state. Without an effective challenge process, a bridge could accept an incorrect state claim and release assets based on a false withdrawal.

Optimistic designs start by treating a posted claim as valid, subject to challenge. This avoids requiring a validity proof for every state update, but it creates a monitoring and response requirement: somebody must be able to detect an incorrect claim and complete the dispute before the relevant deadline. The Ethereum overview of optimistic rollups explains the broader relationship between offchain execution, onchain data availability, and fraud-proving schemes.

The game addresses the verification cost. Re-executing a long L2 history directly in an Ethereum transaction would be too expensive. Instead, the participants interactively locate the first point where their execution traces disagree. The L1 contract then checks a small terminal step. This makes a large computation contestable without asking Ethereum to execute the entire rollup.

How a Fault Proof Game Works

The exact contracts and deadlines are chain-specific, but an OP Stack dispute can be understood as a sequence of stages:

A state proposal is published. A proposer submits an output claim through the dispute-game system on Ethereum. The claim is used by the bridge when checking withdrawals; it is not a separate proof for each L2 transaction.
A challenge is opened. During the challenge period, a participant who observes a disagreement can create a counterclaim. The game is permissionless at the protocol level, although participants need suitable node data, software, funds, and transaction access.
The disagreement is narrowed. The participants commit to execution traces and repeatedly choose which half of a disputed trace contains the first divergence. This bisection process turns an argument about a long computation into a smaller subgame.
The final step is checked. Once the disagreement reaches a single VM instruction, the game invokes the relevant onchain step verifier. In the OP Stack, the fault-proof VM is designed to make that execution checkable by Ethereum contracts.
The game and proposal are resolved. The contract applies its game rules, clocks, and bond outcomes. A proposal that loses the dispute cannot be used as the accepted output for the affected bridge operation.
Withdrawal safeguards still apply. A successful game does not mean a user receives funds immediately. The withdrawal proof, dispute window, and any additional chain-specific safety delays remain separate stages.

This is an interactive protocol, not an automatic review of every transaction as it arrives. Each move is posted onchain and must satisfy the game contract’s rules and timing. A participant that misses a response window may lose even when its underlying claim is correct, which is why operational readiness matters.

Feature	OP Stack fault proof game	Validity-proof rollup
Initial state update	A state claim is proposed and can be challenged	A state update is accompanied by a validity proof
Dispute trigger	A participant contests the claim during the allowed window	The verifier contract checks the submitted proof
Main computation	Participants narrow an execution disagreement to a step	A prover generates a proof for the defined computation
Onchain verification	The contract checks the terminal VM step and game result	The contract verifies the proof
Main operational dependency	Honest monitoring, available data, timely moves, and correct software	Prover capacity, proof generation, and correct verifier logic
Withdrawal timing	Includes a dispute period and applicable safety delays	Depends on proof production, verification, and bridge rules

The table describes broad design patterns, not a guarantee that every project fits neatly in one column. In particular, an optimistic rollup’s game, challenge duration, and fallback controls are implementation-specific. For the larger architecture comparison, see optimistic and zero-knowledge rollups.

Components and Key Concepts

Fault-proof program and execution trace

The fault-proof program represents the rollup state transition that needs to be checked. Given the same committed inputs, it must produce a deterministic execution trace so both sides can identify the disputed step. For the OP Stack, the official component guide describes the program as a composition of execution and consensus logic that derives an L2 output from L1 inputs.

Fault-proof virtual machine

The VM provides the instruction-level execution model that the game can verify. The onchain verifier does not repeat an entire node’s work; it checks the terminal instruction reached after the dispute has been narrowed. Separating the program from the VM lets implementations evolve the state-transition program and proving machinery independently, subject to the protocol’s interfaces.

Pre-image oracle

An execution may need data from L1 or L2, such as block data or state. A pre-image oracle supplies those inputs in an authenticated, deterministic form. If required historical data cannot be retrieved, a challenger may be unable to reproduce a trace or respond in time. Data retention and node configuration are therefore part of the security operation, not optional conveniences.

Game contracts, bonds, and clocks

The dispute-game contract records claims and moves, enforces the rules for each turn, and determines the result. Bonds make claims economically consequential and can help discourage spam, but they do not by themselves prove a claim is true. Game clocks also turn liveness into a security condition: an honest participant must respond before its clock expires.

The OP Stack’s system component documentation describes the program, VM, and dispute-game protocol as modular components. The fault-proof security documentation also describes safeguards around the OptimismPortal, respected game types, and delayed bond withdrawals. On OP Mainnet, privileged security roles remain a backstop; permissionless games do not mean that governance controls have disappeared.

Challengers and monitoring

The op-challenger service monitors games and uses a trusted, synced rollup node plus a trace provider to decide how to respond. It can defend a valid claim or challenge one that disagrees with its node’s state. Running this service is not the same as casually clicking a “challenge” button: operators must plan for historical data, uptime, transaction costs, keys, and game-specific configuration.

Real-World Use Cases

The most visible use is an L2-to-L1 withdrawal. A user first initiates a withdrawal on the rollup and proves it against the bridge’s expected state. The system must not honor that proof against a state proposal that can still be successfully disputed. Fault proof games supply the dispute path that helps the bridge distinguish an accepted output from a contested or invalid one.

The same architecture matters to chain operators and ecosystem developers. Operators need monitoring and dispute infrastructure; bridge and wallet developers need to explain the difference between an L2 transaction confirmation and a withdrawal that is ready to finalize on Ethereum. This connects to the broader rollup design questions discussed in sequencer architecture and rollup sequencing economics.

Getting Started: Inspect Before Operating

For a first pass, check that the Ethereum JSON-RPC endpoint used by an operator is reachable. This read-only request returns the latest L1 block number; it does not inspect a dispute game or prove that a node has the historical data needed to challenge one.

: "${L1_RPC_URL:?Set L1_RPC_URL to an Ethereum JSON-RPC endpoint}"

curl --fail-with-body --silent --show-error "$L1_RPC_URL" \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' |
  jq -er '.result'

If the endpoint check succeeds, confirm that the chain’s own rollup node is synced and that the trace provider and historical data source match the supported configuration. Operators can inspect the locally installed challenger CLI without submitting a transaction:

op-challenger --help

Use the OP-Challenger guide and the chain operator’s configuration reference before starting a service. Do not copy game-creation examples into production: the documentation explicitly marks the create-game subcommand as test-only. A real challenger may post bonded onchain moves and incur gas costs. An RPC health check or successful help command is not evidence that the challenger is correctly configured or able to protect a live bridge.

When evaluating a rollup rather than operating one, check who runs the challenger, what data sources it depends on, which dispute-game type the bridge accepts, how long challenges and safety delays last, and what privileged roles can pause or override the system. Comparing these details is more useful than treating “fraud proofs enabled” as a complete security statement.

Common Misconceptions

“A fault proof is generated for every transaction”

No. The game begins with a claim about rollup state. Only when a participant contests it does the interactive process narrow the disagreement to a terminal computation. Batch publication and data availability remain necessary for independent reconstruction.

“Permissionless means no trusted roles remain”

Permissionless proposals and challenges widen participation, but the deployed system may still have guardian or system-owner controls. OP Stack documentation describes pause, blacklist, game-type, and delayed-bond safeguards. Those controls reduce certain risks but also remain part of the trust model.

“A completed game instantly completes a withdrawal”

A game resolves a claim under its contract rules. Withdrawal proofs, challenge windows, any extra delay, and the portal’s safety checks are distinct steps. Users should rely on the target chain’s bridge rules rather than assuming every optimistic withdrawal has identical timing.

Changelog

2026-10-25: Published the canonical explainer.