Fault-proof dispute games: Best Epic bonds & fraud

Why dispute games exist

Optimistic rollups assume the posted state root is correct unless proven otherwise. This assumption slashes costs and boosts throughput. It also creates a new duty: someone must be able to prove a lie. A well-designed dispute game guarantees that a single honest challenger can overturn a bad claim and get paid for it, even if most participants are lazy or malicious.

Picture a sequencer that sneaks in an invalid transfer. A watchtower catches it. The watchtower challenges, posts a bond, and forces a step-by-step replay that pinpoints the first invalid instruction. If the sequencer cheated, it loses its bond and the state root is rolled back. If the watchtower was wrong or trolling, it pays the price instead.

The core pieces: bonds, fraud proofs, timeouts

These three levers send the core incentives and liveness guarantees in the right direction. Tune them poorly and you invite spam, griefing, or censorship. Tune them well and the system feels boring—in a good way.

Bonds

Bonds are posted by proposers (who claim a state) and challengers (who dispute it). They compensate verifiers for work and punish liars. Bonds can be tiered: a higher “proposal bond” for posting a claim and smaller “challenge bonds” per round to prevent frivolous splits. Dynamic bonds that scale with calldata size or gas limits are common because larger disputes cost more to verify.

Fraud proofs

A fraud proof shows that a specific transition is invalid. In multi-round games, the parties bisect the disputed execution trace until the interval is small enough to evaluate on-chain. In single-round designs, the challenger supplies all necessary context in one go to prove a fault. Either way, the goal is simple: reach an objective on-chain check that leaves no room for opinion.

Timeouts

Every turn has a clock. If a party fails to respond in time—post a sub-claim, provide a witness, or execute a step—they lose by default. Timeouts prevent griefing attacks where an adversary tries to stall challenges until users give up or funds get stuck.

How a dispute game unfolds

The sequence below shows a typical interactive dispute game for an optimistic rollup. The numbers and naming vary by protocol, but the dance is familiar.

1. A proposer posts a state root for a batch, locking a proposal bond.
2. A challenger flags the root and posts a challenge bond. The game begins.
3. Both sides commit to execution traces (hashes of steps). The protocol enforces a bisection: split the trace region in two and choose the half that contains the first divergence.
4. Repeat the split until the interval is one instruction (or a tiny step) that can be executed on-chain.
5. The on-chain VM executes that single step with canonical inputs. If the step violates the rules, the proposer loses; if it’s valid, the challenger loses.
6. Bonds settle. The chain reverts or finalizes the batch accordingly, and rewards the honest side.

In a small scenario, imagine a token transfer with insufficient balance. The challenger shows the exact point where the balance check fails. The contract runs that one instruction with the stored pre-state. The mismatch is undeniable, so the lie is caught and penalized.

Dispute game designs at a glance

Different rollups pick different shapes for their games. The table below sketches common patterns without getting tied to one chain’s evolving parameters.

Choice depends on priorities. If L1 gas is expensive and latency is acceptable, interactive bisection shines. If quick resolution is paramount, single-round proofs reduce wall-clock time at the cost of a big one-time submission.

Setting bond parameters that actually work

Good bonds make cheating unprofitable and spam unattractive. Poor bonds create perverse incentives where griefers waste verifier time or proposers gamble on thin margins.

• Scale with cost: Tie bond size to estimated verification cost (trace length, witness size, or gas caps) so challengers don’t eat losses proving big faults.
• Pay for work: Route slashed bonds to those who did on-chain work or posted the earliest valid challenge, not just a burn address.
• Cooldowns and partial slashing: Use partial penalties for minor rule breaches (e.g., format errors) and full slashing for proven lies, paired with short cooldowns to deter serial spam.
• Escrow structure: Keep bonds escrowed in the dispute contract to prevent re-entrancy or under-collateralized claims.

Small example: if verifying a worst-case step costs 0.02 ETH in gas, a 0.1–0.2 ETH challenge bond leaves margin for two attempts and still punishes frivolous calls. Too low, and spammers can launch dozens of cheap, time-wasting challenges.

Timeouts, finality, and liveness

Timeouts gatekeep progress. They should be long enough for global participants to react and short enough that funds don’t sit in limbo. Per-round timers avoid hostage situations where a single round drags on for days, while global windows set a firm outer bound for withdrawals.

Two practical tips stand out. First, pair timeouts with forced-inclusion mechanisms so blocked L2 transactions can still be posted to L1. Second, document the worst-case resolution time end to end—the sum of challenge window plus per-round timers—so bridges and apps can display realistic withdrawal estimates.

Engineering the fraud proof path

Fraud proofs are only as reliable as their deterministic environment. Making replays match bit-for-bit is the unglamorous work that actually secures funds.

• Determinism: Fix compiler versions, precompiles, and gas schedules. Even a tiny rounding difference can flip a verdict.
• Canonical inputs: Hash and commit to calldata, timestamps, and L1 block metadata used by the L2 VM so challengers replay the exact same view.
• Witness minimization: In single-round proofs, compress witnesses and prune state to the minimal Merkle branches needed for the faulty step.
• Multiple provers: Encourage diversity—independent clients, different hardware, and separate operators—to avoid single points of failure.
• Monitoring UX: Provide clear events and indexing so watchdogs can auto-react within timeout windows.

A tiny scenario: an operator upgrades a precompile that changes gas cost. Without version pinning in the dispute VM, an honest challenger replays the step with the “old” schedule and loses—a silent consensus split. Version locks prevent this.

Common edge cases and how games handle them

Dispute games must remain safe under stress, not just in happy paths. A few recurring edge cases deserve explicit treatment.

1. Censorship on L2: If sequencers ignore challenges, challengers post to L1. Contracts should accept L1-submitted moves and keep the clock ticking.
2. Data withholding: Require data availability commitments (e.g., call data on L1 or DA layers) so challengers can reconstruct traces without trusting any operator.
3. Multiple simultaneous challenges: Allow parallel threads but enforce a canonical outcome—first resolved game decides; others auto-settle to avoid double work.
4. Invalid-finalization attempts: Block withdrawals until either the global challenge window closes or all active disputes settle.
5. DoS via bisection branching: Cap the branching factor; require the challenger to choose one interval per round to keep costs logarithmic.

These safeguards keep the guarantees crisp: a single honest participant can force the truth on-chain, within bounded time and cost.

What users and integrators should watch

You don’t need to build a dispute game to benefit from its guarantees. Yet a short checklist helps you judge safety before you bridge real funds.

• Published, live fault proofs: Are they active on mainnet or “coming soon”?
• Clear challenge window: Is the withdrawal estimate explained with worst-case math?
• Open monitoring: Can independent actors run provers and watchtowers?
• Diversity: Are there multiple clients and provers, or one canonical binary?
• Incentives: Who receives slashed bonds—verifiers or treasury?

If the answers look healthy, the dispute game likely does its job: make lying expensive, make truth cheap to prove, and keep progress moving even when adversaries push back.