Skip to main content
This guide takes an operator who wants an honest challenger defending an OP Stack chain and walks the whole path in one pass: what the challenger does and spends, the version and prestate choices that decide whether it can win games, the four pieces of infrastructure it depends on, and how to confirm it is actually defending the chain. It involves op-challenger, the Cannon VM with a kona-client prestate, an op-node with SafeDB, an op-reth archive node, and your chain’s dispute game contracts on L1.

​
Is this guide for you?

Use this guide if:
  • Your chain runs the fault proof system: a DisputeGameFactory is deployed and proposals are settled by dispute games.
  • You are responsible for the chain’s defense (chain operator) or you are an independent participant willing to put funds at stake to help secure it.
If you are creating a new chain and setting up the challenger as one step of that, follow the challenger step of the create L2 rollup tutorial inside that series instead. If you want to understand how dispute games work before operating anything, start with the fault proofs explainer. If you are investigating one specific game rather than running a standing service, use monitoring tooling.

​
Before you start

You should already have:
  • Your chain’s contract addresses, in particular the DisputeGameFactory proxy address (automatic in Step 3 if your chain is in the superchain-registry).
  • An L1 account you can fund with enough ETH to post bonds (sized in Step 2), and infrastructure to run several services with persistent storage.
  • Your chain’s rollup.json and L2 genesis file if the chain is not in the superchain-registry.

​
Step 1: Understand the role you are staffing

The challenger is the honest actor in the dispute system: an autonomous agent that monitors every game, defends valid proposals, challenges invalid ones, and resolves games so bonds pay out. Read the op-challenger explainer and take away:
  • The five responsibilities (monitor, defend, challenge, resolve, claim bonds), and that the challenger acts on whatever its trusted op-node reports, so the integrity of your rollup node is the integrity of your challenger.
  • That the respected game type is cannon-kona (run with kona-host), and that the legacy cannon / op-program game type has reached end of support: op-program does not support the now-active Karst hardfork, so the kona variants are the only maintained option.
Then read the fault proofs security model and take away what happens when games go wrong anyway: the Guardian can blacklist a bad game or change the respected game type, and bonds sit in DelayedWETH with a delay so incorrect payouts can be recovered. Your challenger is the first line of defense, not the only one.

​
Step 2: Budget your bonds and fees

Every claim your challenger posts carries a bond, sent as transaction value, and correct claims are refunded while incorrect ones pay the counter-claimer. Read the bond FAQs in the explainer and take away:
  • The sizing logic: honest actors combined must be able to outspend an attacker, so there is no fixed safe number. Playing a single game chain to maximum depth costs about 315.6 ETH per side, and a well-funded operator keeps significant funds available at short notice rather than pre-funding everything.
  • The cash-flow shape: bonds from won games pay out only after a 7-day delay, so budget for capital being locked while games resolve.
  • The backstop: attackers who try to outspend honest actors lose their bonds to Guardian intervention, which is the disincentive that keeps the realistic spend far below the worst case.
Decide now how much ETH the challenger’s account holds and how quickly you can top it up during an active dispute; that operational answer matters more than the exact starting balance.

​
Step 3: Pin your versions and prestate

The challenger refuses to interact with games whose absolute prestate it does not have, and playing with the wrong prestate loses games, so version selection is a correctness decision, not housekeeping. Check the op-challenger release history for the latest release, then read the version guidance in the configuration guide and take away which op-challenger, op-reth, and kona-client versions are compatible with your chain’s deployment. Then choose your configuration path: For generating and verifying a prestate, follow the absolute prestate tutorial; for custom chains, the kona-client custom prestate tutorial covers embedding your chain’s configuration.

​
Step 4: Provision the four endpoints

The challenger consumes four services, and each has a requirement beyond “reachable RPC”. Read the key configuration flags in the configuration guide and take away, per endpoint:
  • L1 RPC (--l1-eth-rpc): a trusted node that can absorb heavy request volume. The challenger signs transactions worth real fees based on what this node tells it, so “trusted” is load-bearing.
  • L1 beacon (--l1-beacon): serves the blobs batches were posted in. Decide the blob-archiver question now: if your chain proposes valid outputs regularly, the roughly 18-day blob retention window is enough; if proposals can stall longer than that, a blob archiver is required or the challenger can be pushed into an unwinnable position.
  • L2 archive node (--l2-eth-rpc): an op-reth archive node with the debug API and the historical-proofs store enabled and seeded before first start, sized to cover the dispute window (28 days or more).
  • Rollup node (--rollup-rpc): an op-node with SafeDB enabled (--safedb.path). Take away the warning about never restoring the SafeDB from a snapshot: a SafeDB that disagrees with L1 makes the challenger attack valid outputs, and the challenger cannot detect the condition.

​
Step 5: Configure and start the challenger

With versions, prestate, and endpoints in hand, the configuration guide is the canonical stop. Choose your deployment form: Follow the matching tab of the challenger configuration guide end to end. It covers the environment file, the startup script or compose file, and the flag-by-flag explanations. Keep the guide’s --trace-type value, which includes the cannon-kona game type from Step 1, and use the transaction signer posture you use for your other services (private key, mnemonic, or op-signer).

​
Step 6: Attach monitoring

A challenger that silently stops is worse than none, because you believe you are defended. Read the dispute-mon section of chain monitoring and take away that op-dispute-mon tracks the status of every game over the last 28 days and is considered essential for production challenger deployments. Alert on two conditions at minimum: games the monitor flags as resolving against your chain, and the challenger’s account balance falling below your Step 2 top-up threshold.

​
Step 7: Verify the challenger is defending

Give the challenger a few minutes against live games, then confirm each layer:
  • Startup health: logs show successful connection to all four endpoints and the prestate loading without warnings; the challenger refuses to play games whose prestate it lacks, and says so in the logs.
  • Game visibility: op-challenger list-games (against your L1 RPC and game factory) returns the chain’s games; list-claims shows the claims of any in-progress game. These read-only subcommands use the same configuration as the running service, so they double as configuration checks.
  • Participation: for a game created after your challenger started, the challenger either leaves a valid proposal alone or posts counter-claims to an invalid one. On a testnet you can exercise this deliberately with the create-game subcommand and an intentionally wrong root claim.
  • The economic loop: after games your challenger won resolve and the 7-day delay passes, list-credits shows bonds owed to your challenger’s address being claimed.

​
Next steps

  • op-challenger readme: subcommand reference (create-game, move, resolve, run-trace) and devnet walkthroughs beyond configuration. In-repo document on develop, as of 2026-07-18.
  • There is no rendered flag catalogue for op-challenger; use op-challenger --help on the release you run for the authoritative flag list.
  • Honest challenger specification: the normative algorithm your challenger implements, for when you need to reason about what a correct response is.
  • Bond incentives specification: the required-bond formula behind Step 2’s budget.
  • op-dispute-mon: the monitoring service from Step 6. In-repo document on develop, as of 2026-07-18.