World Chain Specs

All numbers in the document for time windows and ETH values are not calculated. They are just put as templates with more/less appropriate order of magnitude.

Abstract

World Chain currently runs a permissioned Cannon-based fault proof system (game-type=1) with op-proposer posting output roots every 20 minutes. This WIP evaluates different proof system options to upgrade the fault proof mechanism using ZKP or TEE technologies that are compatible with OP Stack dispute games.

Motivation

The current Cannon-based system has several limitations:

• 7-day challenge window required to safely accommodate the interactive bisection game
• Large bond requirements (hundreds of ETH at mainnet scale) to deter adversarial challenges
• Multi-round interactive bisection game: ~30–40 on-chain transactions per dispute
• Game-theoretic security only — requires an honest party to be watching and able to respond within each bisection round

The goal is to upgrade to a proof system that:

• Reduces the challenge window to ~1 day
• Reduces bond requirements to 5–15 ETH
• Eliminates the multi-round interactive bisection game

Specification

ZK Options (zkVMs — compatible with OP Stack dispute games)

Option 1: OP Succinct Lite (SP1 zkVM)

OP Succinct Lite replaces the interactive bisection game with a single ZK proof generated only when a dispute occurs. The chain runs optimistically by default — no proving cost on the happy path.

Proof pipeline

L2 blocks (proposal range)
  │
  ├─ split into N sub-ranges (RANGE_SPLIT_COUNT)
  │
  ├─ parallel range proofs via Succinct Prover Network
  │    world-chain-range-ethereum ELF runs in SP1 zkVM (RISC-V)
  │    produces: compressed STARK proof per range
  │
  └─ aggregation proof
       world-chain-aggregation ELF verifies all range proofs
       produces: single Groth16/Plonk SNARK
         │
         └─ game.prove(agg_proof.bytes()) → L1 tx
              SP1_VERIFIER.verifyProof(AGGREGATION_VKEY, publicValues, proofBytes)

Program identity (keys)

• aggregation_vkey — SP1 verifying key, deterministic fingerprint of world-chain-aggregation ELF
• range_vkey_commitment — SP1 verifying key commitment for world-chain-range-ethereum ELF
• rollup_config_hash — SHA-256 of Kona RollupConfig + World-specific tropo_time + strato_time

All three MUST match between the deployed contract and the running proposer, or games are classified as foreign and will not be proven.

World-specific changes vs upstream OP Succinct

• Replace ELF imports with world-chain-proof-succinct-elfs
• Replace hash_rollup_config(...) with World hash helper (appends tropo_time and strato_time)
• Replace ETH witness generation with World witness data carrying the hardfork schedule

Dispute flow

Proposer posts output root (no proof required)
  │
  │  challenge window (~1 day)
  │
  ├─ No challenge → DEFENDER_WINS  (no proof ever needed)
  │
  └─ Challenger calls challenge() + bond
       │
       Proposer requests ZK proof from Succinct Network (minutes–hours)
       Proposer calls prove(proofBytes)
         │
         ├─ proof valid → DEFENDER_WINS
         └─ proof missing/invalid by deadline → CHALLENGER_WINS

Properties

Option 2: RISC Zero zkVM (Boundless / op-risc0)

RISC Zero’s Zeth proves the OP Stack state transition inside the RISC Zero RISC-V zkVM. Like SP1, it runs op-program (Kona) as a RISC-V ELF and produces a STARK proof compressed to a Groth16 SNARK for on-chain verification. RISC Zero offers both a managed proving network (Bonsai / Boundless) and self-hosted provers.

Key differences vs SP1

• Prover flexibility: RISC Zero supports self-hosted proving clusters, reducing dependency on an external prover network.
• Continuations: RISC Zero uses a segment/continuation model for long-running programs; SP1 uses a range-split model. Both handle the full EVM transition.
• Circuit audit maturity: SP1 has a production OP Stack integration (op-succinct); RISC Zero’s op-risc0 is at a similar stage but less field-tested on OP Stack.
• Proof system: RISC Zero uses FRI-based STARKs (Plonky2/Plonky3) internally; final on-chain proof is Groth16 or Plonk (~300k gas).
• Verifying key: imageId (SHA-256 of the guest ELF) plays the same role as SP1’s aggregation_vkey.

Properties

Option 3: Jolt zkVM (a16z)

Jolt is a RISC-V zkVM developed by a16z crypto research, based on sumcheck-based lookup arguments (Lasso + Jolt). It is currently at research/early-prototype stage and does not yet have a production OP Stack integration, but the RISC-V architecture is compatible in principle.

Key characteristics

• Novel proof system: Uses a sumcheck + multilinear polynomial approach rather than FRI-based STARKs. Potentially faster proving for certain workloads.
• No production OP Stack integration yet: No published op-jolt equivalent exists as of this writing.
• On-chain verification: Hyperplonk/HyperKZG-based verifier; on-chain gas costs not yet characterised for OP Stack use.
• Maturity: Significantly less mature than SP1 or RISC Zero. Not recommended for near-term deployment.

Properties

TEE Options

Option 4: AWS Nitro Enclaves

The L2 state transition function runs inside an AWS Nitro Enclave — a hypervisor-isolated VM partitioned from the parent EC2 instance. The Nitro Hypervisor signs an attestation document proving that a specific program (identified by PCR measurements) produced a specific output.

Attestation pipeline

L2 blocks + previous state root
  │
  └─ load into Nitro Enclave (isolated VM, no external network, no storage)
       │
       state transition function runs natively at full CPU speed
       computes: new_state_root
         │
         └─ request attestation from Nitro Hypervisor
              {
                PCR0: SHA384(enclave image),    ← program fingerprint
                PCR1: SHA384(kernel),
                PCR2: SHA384(application),
                user_data: new_state_root,       ← the output
              }
              signed with P-384 ECDSA by AWS Nitro PKI
                │
                └─ post attestation doc on-chain
                     L1 contract verifies:
                       - AWS PKI cert chain
                       - PCR0 matches expected image hash
                       - output_root extracted from user_data

Properties

Risks

• Single trust point: AWS owns both the attestation key and the infrastructure. A compromised or malicious AWS invalidates all proofs.
• Not Intel SGX: AWS Nitro uses hypervisor-based isolation, not CPU memory encryption. AWS disables Intel SGX at the BIOS level on all EC2 instances.
• Certificate expiry: AWS Nitro attestation certificates expire after 3 hours, requiring active rotation.

Option 5: Intel SGX TEE

Intel SGX (Software Guard Extensions) is a CPU-level TEE. The state transition function runs inside an SGX enclave — a private memory region that is hardware-encrypted and isolated from the OS, hypervisor, and root users. Intel’s Provisioning Certification Service (PCS) signs attestation quotes.

Note: Intel SGX is not available on AWS. It requires Azure DC-series instances, IBM Cloud bare metal, or physical Intel Skylake/Ice Lake hardware with SGX enabled in BIOS.

Attestation pipeline

L2 blocks + previous state root
  │
  └─ load into SGX enclave (CPU-encrypted memory region)
       │
       state transition function runs natively
       computes: new_state_root
         │
         └─ generate SGX quote (DCAP attestation)
              {
                MRENCLAVE: SHA256(enclave code + data),  ← program fingerprint
                MRSIGNER:  SHA256(enclave signing key),
                report_data: new_state_root,              ← the output
              }
              signed by Intel Provisioning Certification Key (PCK)
                │
                └─ post quote on-chain
                     Automata DCAP contracts verify on-chain:
                       - PCK cert chain back to Intel root CA
                       - MRENCLAVE matches expected value
                       - report_data extracted as new state root

Properties

Risks

• Intel trust: Intel owns the PCK signing key. Side-channel attacks (Spectre, Plundervolt, SGAxe, Foreshadow) have repeatedly compromised SGX enclaves.
• Not on AWS: Requires migrating proposer/sequencer infra to Azure or bare metal.
• EPC memory limits: SGX1 limits enclave memory to ~256 MB; full L2 STF may exceed this. SGX2 (EDMM) and multi-enclave sharding partially mitigate this.
• Maintenance burden: Regular TCB recovery updates required as Intel patches microcode.

Option 6: AMD SEV-SNP TEE

AMD Secure Encrypted Virtualization — Secure Nested Paging (SEV-SNP) is a CPU-level TEE that isolates full VMs (rather than individual enclaves like SGX). Memory pages are encrypted with a VM-unique key managed by the AMD Secure Processor. SEV-SNP adds memory integrity protection and a hardware-attested measurement of the entire VM image.

Attestation pipeline

L2 blocks + previous state root
  │
  └─ load into SEV-SNP VM (full VM, hardware memory-encrypted)
       │
       state transition function runs natively at full VM speed
       computes: new_state_root
         │
         └─ generate SNP attestation report
              {
                MEASUREMENT: SHA384(VM launch digest),  ← program fingerprint
                HOST_DATA: new_state_root,               ← the output
                VMPL: privilege level of requesting vCPU
              }
              signed by AMD VCEK (Versioned Chip Endorsement Key)
              cert chain: VCEK → AMD ASK → AMD ARK (root CA)
                │
                └─ post attestation report on-chain
                     L1 contract verifies:
                       - AMD cert chain
                       - MEASUREMENT matches expected VM digest
                       - HOST_DATA extracted as new state root

Properties

Risks

• AMD trust: AMD owns the VCEK signing key. Unlike SGX, AMD SEV-SNP has fewer published side-channel exploits, but the attack surface of a full VM TEE is broader than a CPU enclave.
• VCEK cert rotation: VCEK certificates are versioned per TCB level and must be refreshed after firmware updates.
• No AWS support: AWS does not expose AMD SEV-SNP to tenants (analogous to the SGX situation).
• On-chain verifier: No widely-deployed production on-chain AMD SNP verifier exists yet; would require custom development or adaptation of existing work.

Option 7: Intel TDX TEE

Intel Trust Domain Extensions (TDX) is Intel’s VM-level TEE — the conceptual successor to SGX but for full VMs rather than per-process enclaves. TDX Trust Domains (TDs) are hardware-isolated VMs with encrypted memory and CPU state. Attestation uses the same DCAP infrastructure as SGX.

Key characteristics

• Full VM isolation: No EPC memory limits; the full state transition function runs inside the VM without SGX’s ~256 MB enclave restriction.
• Same attestation infrastructure as SGX: TDX attestation quotes use the same PCK cert chain and DCAP verification flow as SGX, enabling reuse of Automata-style on-chain verifiers.
• Cloud availability: Intel TDX VMs are available on Azure (DCesv5/DCedsv5 series), Google Cloud (C3 with TDX), and Alibaba Cloud.
• MRTD measurement: The VM launch measurement (MRTD) plays the same role as SGX’s MRENCLAVE.
• Not available on AWS: Same constraint as SGX.

Properties

Risks

• Intel trust: Same Intel PKI trust assumption as SGX.
• Newer / less battle-tested: TDX is more recent than SGX; fewer published attacks but also less third-party review.
• Not on AWS: Infra migration required.

Comparison

Dispute Game & Trust Model

Speed, Cost, and World Chain Fit

Backwards Compatibility

Introducing a new game-type=42 is additive. The existing Cannon challenger (game-type=1) (with Optimism upgrade 19 Cannon Kona challenger game-type=8) continues to operate in parallel and MUST NOT be decommissioned until the ZK game type is deployed, funded, and producing verified games on devnet.

Security Considerations

ZK Options (SP1, RISC Zero, Jolt)

• The verifying key (aggregation_vkey for SP1, imageId for RISC Zero) deployed in the contract MUST exactly match the values used by the running proposer. A mismatch causes the proposer to classify games as foreign and refuse to prove them, leaving valid proposals vulnerable to challenger wins.
• The CHALLENGER_BOND MUST be set high enough to make spam challenges economically irrational (recommended: at least 10× the cost to generate one proof).
• The tropo_time and strato_time hardfork timestamps MUST be finalised before deploying contracts — the rollup_config_hash is derived from these values and cannot be changed post-deployment without redeployment.
• Proof generation relies on an external prover network (Succinct / Bonsai). Availability risk should be mitigated via MAX_PROVE_DURATION being set conservatively and a fallback mock-mode tested on devnet. Self-hosted proving for RISC Zero mitigates this.

TEE Options (AWS Nitro, Intel SGX, AMD SEV-SNP, Intel TDX)

• All TEE options introduce a trust dependency on the hardware vendor’s PKI. Compromise of the vendor’s attestation key allows forging arbitrary state roots.
• TEE enclaves and VMs have a history of side-channel vulnerabilities. Any production deployment requires a thorough security audit and an ongoing TCB update process.
• AWS Nitro certificates expire after 3 hours and must be actively rotated.
• Intel SGX’s EPC memory limit (~256 MB) may be insufficient for the full L2 state transition function without sharding.

Threshold Multi-Proof / Multi-Attestation System

The single-prover options above each provide a significant improvement over the current Cannon-based system, but they each carry a single point of failure — whether that is a cryptographic bug in one zkVM, a hardware vendor’s PKI, or a prover-network outage. This section describes a threshold multi-proof architecture that layers two or more of the proof systems described above into an N-of-M pool, so that no single system’s failure or compromise is sufficient to accept a fraudulent state root or to halt the chain.

Overview

                      ┌─────────────────────────────────────────────────┐
                      │            ProofAggregator (L1)                  │
                      │                                                   │
  SP1 prover ─────────┤→ submitProof(gameId, PROVER_SP1, proofBytes)     │
  RISC Zero prover ───┤→ submitProof(gameId, PROVER_RISCZ, proofBytes)   │
  SGX prover ─────────┤→ submitAttestation(gameId, PROVER_SGX, quote)    │
                      │                                                   │
                      │  validCount = sum of accepted submissions         │
                      │                                                   │
                      │  validCount ≥ ⌈2N/3⌉  → ACCEPT  (happy path)    │
                      │  ⌈N/3⌉ ≤ validCount < ⌈2N/3⌉ → COUNCIL REVIEW  │
                      │  validCount < ⌊N/3⌋  → REJECT                   │
                      └─────────────────────────────────────────────────┘

With the reference configuration of N = 3 provers (SP1 + RISC Zero + Intel SGX), the thresholds are:

8.1 Happy Path — 2/3 Threshold

When at least 2 of 3 provers submit valid proofs/attestations for the same output root within the challenge window, the ProofAggregator automatically marks the game as DEFENDER_WINS and no human intervention is required. The sequencer can then proceed with state root finalisation.

Why 2/3? A threshold strictly greater than half is a standard requirement for Byzantine fault tolerance: an attacker controlling fewer than 1/3 of the pool cannot unilaterally cause acceptance of a fraudulent root. Requiring a simple majority (1/2) would mean that compromising just one additional prover beyond 50 % is sufficient; the 2/3 threshold requires compromising two independent systems simultaneously, which is substantially harder.

Economic security: An attacker attempting to submit a fraudulent state root must:

1. Break the soundness of at least two zkVM proof systems (SP1 + RISC Zero), or
2. Break one zkVM system and exploit the SGX hardware attestation chain, or
3. Compromise the Security Council without triggering a timely response.

Each of these requires defeating fundamentally different security assumptions (cryptographic soundness vs hardware vendor PKI vs human governance), making simultaneous compromise extremely unlikely.

8.2 Security Council Fallback — Between 1/3 and 2/3

If exactly 1 of 3 provers submits a valid proof within the challenge window, the ProofAggregator enters a council review period (recommended: 72 hours) rather than auto-rejecting.

This situation is expected to occur legitimately when:

• One prover network (e.g. Succinct) is temporarily offline or degraded.
• One zkVM has a known bug that is actively being patched.
• One TEE platform has an expired TCB update pending from the hardware vendor.
• A new prover is being added to the pool and has not yet generated its first proof.

In each of these cases, auto-rejection would halt chain progress unnecessarily. The Security Council exists to distinguish a liveness failure (one prover is down) from a safety failure (two provers are producing conflicting results).

Security Council Composition

The Security Council is an on-chain multisig (e.g. SafeMultisig) controlled by a set of trusted entities.

A 3-of-5 or 4-of-7 approval threshold within the council is recommended. Larger councils reduce coup risk at the cost of slower response time; the 72-hour review window should be calibrated to the council’s expected decision latency.

Council Decision Time-lock

Council approval does not take effect immediately. A 24-hour time-lock is enforced on-chain between a council vote and state root finalisation. This gives the broader community a window to:

• Observe the pending council action.
• Issue an emergency veto if the council is acting maliciously or under duress.
• Coordinate a client-level soft-fork if necessary.

The time-lock contract should allow a guardian (a separate cold-key multisig) to cancel a pending council action within the lock period.

Council Governance

• Council seats are held for fixed terms (e.g. 12 months) and are renewable.
• Seat changes require an on-chain governance vote (World ID-gated or token-gated, per the chain’s governance model at the time of deployment).
• Council members are expected to publish public rationale for any approval or rejection decision in the council review period. Decisions are permanently recorded on-chain.
• If the council fails to reach a quorum within the review window, the disputed game defaults to rejection to preserve safety.

We already have a Security Council that can be used.

8.3 Automatic Rejection — < 1/3 Valid

If zero provers agree on the proposed state root, the output is immediately and automatically rejected. This is the expected outcome when:

• The proposer has submitted a fraudulent root.
• The proposer’s client software has a critical bug that produces an incorrect output.
• A re-org has occurred and the root no longer corresponds to the canonical chain.

No council intervention is permitted in this state. Automatic rejection prevents the council from being used as a mechanism to push through fraudulent state roots even if the council is fully compromised.

8.4 N-of-M Proof Pool Design

The proof pool is defined by an ordered list of (proverId, verifierAddress, weight) tuples stored in the ProofAggregator contract. The recommended initial pool:

Each prover submits its result independently. The ProofAggregator verifies each submission against its registered verifier contract before incrementing validCount. Submissions arriving after the challenge window are discarded.

Combining zkVM and TEE provers is intentional. The two categories have orthogonal trust assumptions: breaking a zkVM proof requires finding a mathematical soundness flaw, while breaking a TEE attestation requires compromising vendor PKI or hardware. An attacker capable of doing one is unlikely to be capable of doing both.

8.5 Liveness vs Safety Tradeoff

The 2/3 threshold means the system tolerates up to 1 prover failure without losing liveness, and requires an attacker to compromise at least 2 independent systems to achieve a safety failure. This matches the standard BFT fault-tolerance guarantee (tolerate ⌊(N−1)/3⌋ = 1 Byzantine fault for N = 3).

* We can also halt chain.

8.6 Comparison with Taiko’s Multi-Prover Model

Taiko’s TEE Prover and multi-prover architecture is the closest published analogue to what is described here. Key differences:

Taiko’s model requires SGX as a mandatory slot, meaning SGX is a hard dependency. The World Chain model treats SGX as one of three equal participants; if the SGX slot is eventually replaced by a newer TEE (e.g. Intel TDX or AMD SEV-SNP), the pool can be updated via governance without changing the threshold logic.

8.7 On-Chain Contract Design Sketch

ProofAggregator

/// @notice Collects proofs/attestations from the registered prover pool,
///         checks the threshold, and gates DisputeGame resolution.
contract ProofAggregator {

    // -- Configuration --

    struct Prover {
        address verifier;   // IProofVerifier — verify(gameId, proof) → bool
        bool    active;
    }

    Prover[]  public provers;           // ordered pool; index = proverId
    uint256   public threshold;         // min valid count to auto-accept (e.g. 2)
    uint256   public councilThreshold;  // min valid count to allow council review (e.g. 1)
    uint256   public reviewWindow;      // seconds council has to vote (e.g. 72 hours)
    uint256   public timeLockDelay;     // seconds between council approval and execution (e.g. 24 hours)

    ISecurityCouncil public council;

    // -- State per game --

    struct GameState {
        uint128 validCount;
        uint128 submittedMask;  // bitmask of which provers have submitted
        Status  status;         // Pending | Accepted | CouncilReview | Rejected
        uint64  reviewDeadline;
    }

    mapping(bytes32 gameId => GameState) public games;

    // -- Events --

    event ProofSubmitted(bytes32 indexed gameId, uint256 proverId, bool valid);
    event ThresholdReached(bytes32 indexed gameId, uint256 validCount);
    event CouncilReviewOpened(bytes32 indexed gameId, uint64 deadline);
    event CouncilApproved(bytes32 indexed gameId, uint64 executionTime);
    event GameRejected(bytes32 indexed gameId, uint256 validCount);

    // -- Submission --

    /// @notice Called by each prover's off-chain agent.
    function submitProof(bytes32 gameId, uint256 proverId, bytes calldata proof) external {
        GameState storage g = games[gameId];
        require(g.status == Status.Pending, "game not pending");
        require(!_hasBit(g.submittedMask, proverId), "already submitted");

        g.submittedMask = uint128(_setBit(g.submittedMask, proverId));

        bool valid = provers[proverId].verifier != address(0)
            && IProofVerifier(provers[proverId].verifier).verify(gameId, proof);

        if (valid) g.validCount++;

        emit ProofSubmitted(gameId, proverId, valid);
        _evaluate(gameId, g);
    }

    // -- Internal threshold evaluation --

    function _evaluate(bytes32 gameId, GameState storage g) internal {
        uint256 total = _activeProverCount();
        if (g.validCount >= _twoThirds(total)) {
            g.status = Status.Accepted;
            emit ThresholdReached(gameId, g.validCount);
        } else if (_allSubmitted(g, total) || block.timestamp >= g.reviewDeadline) {
            // All submissions received or window closed — check council threshold
            if (g.validCount > total / 3) {
                g.status = Status.CouncilReview;
                g.reviewDeadline = uint64(block.timestamp + reviewWindow);
                emit CouncilReviewOpened(gameId, g.reviewDeadline);
            } else {
                g.status = Status.Rejected;
                emit GameRejected(gameId, g.validCount);
            }
        }
    }

    // -- Council approval --

    /// @notice Called by the SecurityCouncil contract after quorum is reached.
    function councilApprove(bytes32 gameId) external onlyCouncil {
        GameState storage g = games[gameId];
        require(g.status == Status.CouncilReview, "not in review");
        require(block.timestamp <= g.reviewDeadline, "review window expired");
        // Time-lock: emit event; actual execution happens after timeLockDelay
        emit CouncilApproved(gameId, uint64(block.timestamp + timeLockDelay));
        // Execution is handled by a separate TimelockController.execute() call.
    }
}

Integration with DisputeGame

The DisputeGame.resolve() function is gated by a call to ProofAggregator.gameStatus(gameId). The game can only be resolved as DEFENDER_WINS if the aggregator returns Status.Accepted (or Status.CouncilApproved after the time-lock has elapsed). Any other status results in CHALLENGER_WINS or a revert while the game is still in review.

DisputeGame.resolve()
  │
  └─ require(aggregator.gameStatus(id) == Accepted || CouncilApproved, "proof threshold not met")
       │
       ├─ Accepted → DEFENDER_WINS immediately
       └─ CouncilApproved → DEFENDER_WINS only if timeLock.elapsed(id)

8.8 Upgrade Path and Pool Governance

The proof pool is designed to evolve over time:

• Adding a new prover: Governance vote → ProofAggregator.addProver(verifier) → pool size N increases → threshold recalculated. A 3-of-4 configuration (threshold = 3) would give stronger safety guarantees.
• Removing a deprecated prover: Governance vote → ProofAggregator.deactivateProver(id) → pool size decreases. A minimum pool size of 2 should be enforced.
• Replacing a verifier contract: e.g. upgrading from Groth16 to a newer SP1 verifier — update the verifier address for the relevant prover slot after governance approval.
• Changing the threshold: Requires a governance vote and an on-chain parameter update. Any threshold change takes effect only after a 7-day delay.

The pool configuration (provers[], threshold, councilThreshold) is stored in an upgradeable proxy, allowing future governance to adapt the system without redeploying the full aggregator.

8.9 Summary

9. Economic Escalation Game

The multi-proof architecture in Section 8 establishes what counts as a valid proof. This section describes how economic incentives govern the challenge/response lifecycle — specifically, a bond escalation mechanism that makes griefing attacks progressively more expensive while ensuring honest parties are always compensated for participating in disputes.

9.1 Core Concept

The escalation game replaces the OP Stack’s fixed-bond model with a dynamic bidding mechanism. Both the challenger and the defender can raise their bond at any point during the challenge window. A higher bid signals confidence and forces the opposing party to match or forfeit. The winner receives their own bond back plus the loser’s bond (minus a small protocol fee).

This creates a game-theoretic equilibrium:

• Honest defenders always match escalations because their expected value of winning exceeds the cost of matching.
• Frivolous challengers face escalating capital at risk with no economic upside on a valid root.
• Griefing attackers must keep outbidding an honest defender, losing their full cumulative stake each time they fail.

9.2 Mechanism Design

9.2.1 Initial Bonds

• The challenger posts an initial bond to open a dispute. This bond is locked in escrow and signals the challenger’s confidence in their claim.
• The defender (proposer) must post a matching or exceeding bond to formally respond. Failing to respond within the initial response window constitutes a concession.
• Asymmetric entry costs apply: the challenger pays more to open a dispute than to respond to an escalation, deterring spam while keeping honest response cheap.

9.2.2 Escalation Rounds

Either party may raise their bond at any point during the active challenge window. The opponent then has a fixed escalation response window (24 hours per round) to match the new bond level. Failure to match within that window constitutes a forfeit for that round — the forfeiting party concedes the dispute.

There is no limit on the number of rounds, but a bond cap (see Section 9.6) ensures costs remain bounded.

9.2.3 Winner-Takes-All Resolution

When the dispute resolves (either by proof outcome, bond forfeit, or challenge window expiry), the winning party receives:

payout = winner_bond + loser_bond × (1 − protocol_fee_rate)

The protocol_fee_rate portion of the loser’s bond is transferred to the protocol treasury / prover incentive fund (see Section 9.7).

9.3 Anti-Griefing Properties

The escalation model provides three layers of protection against griefing:

1. Raising is expensive. An attacker attempting to grief an honest proposer must continually match or exceed the defender’s escalations. Each round increases the attacker’s capital at risk without any economic upside, since the honest prover will eventually produce a valid ZK proof and win.

2. Honest parties have economic certainty. Because the multi-proof system (Section 8) produces a deterministic proof outcome, an honest defender knows with certainty they will win. Their expected value of matching any escalation is strictly positive; their dominant strategy is always to match.

3. Bond escalation caps prevent runaway costs. A configurable maximum bond cap (see Section 9.6) bounds the maximum capital at risk for any participant, ensuring that no single dispute can drain an honest party’s reserves entirely.

9.4 Interaction with the Multi-Proof System (Section 8)

The economic game runs in parallel with the proof submission lifecycle:

• Early termination: If the ProofAggregator reaches the 2/3 acceptance threshold before the challenge window closes, the escalation game terminates immediately. No further escalation rounds are permitted; the winner is determined by the proof outcome.
• Disagreement signal: If exactly 1-of-3 provers has submitted a valid proof when the escalation game is active, the current bond level is used as a priority signal to the Security Council — a higher bond level indicates that one or both parties have high conviction, which the council should weight accordingly when triaging its review queue.
• Proof-independent forfeit: A party that forfeits the economic game (by failing to match within the response window) loses the dispute regardless of the eventual proof outcome. This ensures the economic and proof-based systems are independently enforceable.

Challenge window opens
  │
  ├─ ProofAggregator: 2/3 threshold reached → escalation game terminates early
  │                                            winner = proof outcome
  │
  ├─ Escalation: one party fails to match within response window
  │              → that party forfeits (proof outcome irrelevant)
  │
  └─ Challenge window closes with no forfeit
       → winner determined by ProofAggregator status
            ├─ Accepted (2/3) → DEFENDER_WINS
            ├─ CouncilReview (1/3) → council decides; bond level informs priority
            └─ Rejected (0) → CHALLENGER_WINS

9.5 Game Theory Analysis

Nash Equilibrium

Let B_d be the defender’s current bond and B_c the challenger’s. The honest defender’s expected payoff from matching any escalation to B_c' is:

E[payoff] = B_d + B_c' × (1 − fee) > 0   (because they win with certainty)

Since the honest defender’s win probability approaches 1 (they can produce a valid ZK proof), they will always match. The unique Nash equilibrium is therefore:

The honest defender matches every escalation; a rational attacker, anticipating this, never escalates.

In practice, an attacker with deep pockets might still try to exhaust the defender’s liquidity. The bond cap (Section 9.6) and the yield-bearing escrow design (Section 9.8) mitigate this.

Attacker’s Cost

Under the recommended Option B + E design, the costs diverge between the escalating attacker and the responding honest party:

attacker_cumulative_stake  = B_initial × 2.0^N   (escalating party: 2.0× per round)
honest_defender_stake      = B_initial × 1.5^N   (responding party: 1.5× per round)

With an initial defender bond of 0.1 ETH and a 32 ETH cap, the honest defender exhausts the cap at approximately ⌊log_{1.5}(320)⌋ = 13 rounds, while the attacker (using 2.0× increments) exhausts the cap at approximately ⌊log_{2.0}(320)⌋ = 8 rounds. The attacker forfeits their entire cumulative stake on loss, and because their costs compound faster, the honest party maintains a structural capital advantage in any prolonged escalation.

Comparison to the OP Stack Fixed-Bond Model

9.6 Bond Asymmetry Design Options

The single most consequential parameter choice in the escalation game is the entry-bond asymmetry between the challenger (the party making an extraordinary claim against an existing output root) and the defender (the proposer responding to that claim). Five distinct design options are presented below, each with trade-offs.

Option A: Symmetric Bonds (Equal Entry)

Both challenger and defender post the same initial bond to open or respond to a dispute.

Pros:

• Simple, fair, and requires no special-casing in the contract.
• The escalation mechanic alone handles anti-spam — a frivolous challenger still faces escalating capital at risk with no upside.
• Easy to reason about on-chain; reduces audit surface.

Cons:

• May deter low-capital honest challengers who cannot afford the same bond as a well-resourced proposer/sequencer.
• Does not account for the asymmetry of risk: the challenger is the initiating (riskier) party making the extraordinary claim.

Option B: Challenger Pays More (Initiator Premium)

The challenger must post a higher bond than the defender to open a dispute (e.g. 1.5× the required defender response bond).

Pros:

• Raises the cost of spam and griefing — the challenger is the party making the extraordinary claim, so a higher barrier is economically justified.
• Honest challengers are still protected by the winner-takes-all payout; their expected value remains positive when they are correct.
• Natural deterrent against frivolous disputes without banning challengers with lower capital (they can still participate, just at a higher initial cost).

Cons:

• Higher barrier to entry could deter undercapitalized honest watchers, reducing decentralization of the challenger network.
• Wealthier attackers can still afford the higher entry bond, so it raises the floor but does not eliminate deep-pocket attacks.
• May discourage challenger networks or watchdog services from operating at scale.

Option C: Challenger Pays Less (Watcher Incentive)

The challenger posts a smaller bond (e.g. 50% of the defender’s bond) to lower the barrier for honest watchers.

Pros:

• Encourages a broad, decentralized watcher network by minimizing capital requirements for honest challengers.
• Reduces the economic burden on parties who are already spending resources monitoring the chain.

Cons:

• Enables cheap spam — low-cost entry means attackers can flood the system with frivolous disputes.
• The defender (sequencer) must repeatedly respond and lock up capital for each dispute, even if most are meritless.
• The asymmetry can be deliberately exploited: an attacker need only risk a small bond to force the defender to tie up large capital.

Option D: Time-Asymmetric Response Windows

Bonds are symmetric in size, but the defender receives a longer response window at each escalation round (e.g. challenger must respond in 12 hours, defender gets 24 hours). Rationale: the defender is a reactive party, not a proactive one.

Pros:

• Protects honest defenders from being timed out by a challenger who escalates just before a deadline.
• No capital asymmetry is needed — fairness is achieved through time rather than cost.
• Relatively simple to implement: only the responseWindow logic branches on which party is responding.

Cons:

• Slower overall dispute resolution — a single escalation chain now takes longer to resolve at each round.
• A malicious defender can use the extra response time to delay finality without conceding.
• Does not address spam at the point of entry; a low-bond challenger can still open many cheap disputes.

Option E: Progressive Escalation Multiplier (Asymmetric Escalation Cost)

Both parties start with the same initial bond, but each escalation round requires a higher multiplier from the escalating party than from the responding party (e.g. the party that raises must increase by 2×, while the party responding need only match by 1.5×).

Pros:

• Makes aggressive escalation increasingly expensive for the attacking party while keeping honest responses comparatively cheaper.
• An honest defender who is confident in their root can always match at a lower incremental cost than the cost of the attack.
• Naturally terminates runaway escalation: the escalating party’s capital grows faster than the responding party’s, so rational attackers abandon escalation early.

Cons:

• More complex to implement and audit; the asymmetric multiplier introduces additional contract state and branching logic.
• The multiplier ratio (2× escalate vs 1.5× respond) needs careful calibration — too large a gap may over-penalize honest challengers who legitimately want to escalate.
• May confuse participants who expect symmetric rules; requires clear documentation in the dispute interface.

Comparison Table

9.7 Protocol Fee

A 3% fee on the loser’s bond is deducted before paying out the winner. These funds are routed to a designated protocol treasury address that serves a dual purpose:

1. Prover incentive fund: Partially reimburses ZK prover costs (prover network fees from Succinct / Bonsai) incurred during the dispute.
2. Protocol reserves: Builds a reserve that can be used to cover prover costs on the happy path if a validity-proof model is adopted in future.

The fee rate is a governance-controlled parameter, stored in the EscalationGame contract and bounded between 1% and 10%.

9.8 Capital Efficiency (Optional)

Locking large bonds in a smart contract carries significant opportunity cost. Two mechanisms reduce this burden for honest participants:

Yield-Bearing Escrow (Optional)

Bonds held in escrow are deposited into a yield-bearing position (e.g. an ERC-4626 vault backed by wstETH or aETH) rather than held as raw ETH. The depositor retains the yield during the lock period; only the principal is at risk. This approach:

• Reduces the effective cost of bonding for honest parties (yield offsets lock cost).
• Does not change the slashing semantics — only the principal is forfeit on loss.
• Requires the escrow contract to wrap/unwrap positions atomically when bonds are posted or released.

Asymmetric Bond Ratios (Optional)

The challenger pays the full bond to open a dispute but only 50% of the current bond level to respond to a subsequent escalation initiated by the defender. The inverse applies to the defender. This asymmetry:

• Increases the cost of opening frivolous disputes.
• Keeps the marginal cost of honest response lower than the marginal cost of escalation.
• Preserves the winner-takes-all payout (the loser forfeits the full amount they posted).

9.9 On-Chain Contract Design Sketch

EscalationGame Contract

/// @notice Manages the economic escalation game for a single DisputeGame instance.
///         Deployed per game or as a shared singleton with per-game state.
contract EscalationGame {

    // -- Types --

    enum GameStatus { Open, Active, Escalated, Resolved, Forfeited }

    struct EscalationState {
        address  challenger;
        address  defender;
        uint256  challengerBond;   // current bond posted by challenger
        uint256  defenderBond;     // current bond posted by defender
        uint256  roundDeadline;    // timestamp by which the responding party must match
        address  pendingResponder; // party that must respond (match or forfeit)
        GameStatus status;
    }

    // -- State --

    mapping(bytes32 gameId => EscalationState) public games;

    IProofAggregator public aggregator;
    IVault           public escrowVault;   // ERC-4626 yield-bearing vault
    address          public treasury;
    uint256          public protocolFeeRate;   // e.g. 300 = 3%
    uint256          public maxBondCap;        // e.g. 32 ether
    uint256          public minEscalationMultiplier; // e.g. 150 = 1.5×, in bps (10000 = 1×)
    uint256          public responseWindow;    // seconds per escalation round (e.g. 86400)

    // -- Events --

    event ChallengeOpened(bytes32 indexed gameId, address challenger, uint256 bond);
    event DefenderResponded(bytes32 indexed gameId, address defender, uint256 bond);
    event BondEscalated(bytes32 indexed gameId, address escalator, uint256 newBond);
    event PartyForfeited(bytes32 indexed gameId, address forfeiter, uint256 bondLost);
    event GameResolved(bytes32 indexed gameId, address winner, uint256 payout);

    // -- Actions --

    /// @notice Challenger calls this to open a new dispute.
    /// @param gameId  The ID of the associated DisputeGame.
    /// @param bond    ETH bond amount (must equal msg.value).
    function openChallenge(bytes32 gameId, uint256 bond) external payable {
        require(msg.value == bond, "bond mismatch");
        require(bond >= MIN_INITIAL_BOND, "bond too low");
        EscalationState storage s = games[gameId];
        require(s.status == GameStatus(0), "already opened"); // default is Open

        _depositToVault(gameId, msg.sender, bond);

        s.challenger    = msg.sender;
        s.challengerBond = bond;
        s.roundDeadline = block.timestamp + responseWindow;
        s.pendingResponder = address(0); // defender must respond
        s.status        = GameStatus.Open;

        emit ChallengeOpened(gameId, msg.sender, bond);
    }

    /// @notice Defender calls this to respond to an open challenge.
    function respond(bytes32 gameId, uint256 bond) external payable {
        EscalationState storage s = games[gameId];
        require(s.status == GameStatus.Open, "not open");
        require(block.timestamp <= s.roundDeadline, "response window expired");
        require(bond >= s.challengerBond, "must match or exceed challenger bond");
        require(msg.value == bond, "bond mismatch");

        _depositToVault(gameId, msg.sender, bond);

        s.defender    = msg.sender;
        s.defenderBond = bond;
        s.status      = GameStatus.Active;

        emit DefenderResponded(gameId, msg.sender, bond);
    }

    /// @notice Either party escalates by raising their bond.
    /// @param newBond  New total bond (must be ≥ 1.5× the current highest bond).
    function escalate(bytes32 gameId, uint256 newBond) external payable {
        EscalationState storage s = games[gameId];
        require(s.status == GameStatus.Active || s.status == GameStatus.Escalated,
                "cannot escalate");
        require(msg.sender == s.challenger || msg.sender == s.defender,
                "not a party");

        uint256 currentMax = s.challengerBond > s.defenderBond
            ? s.challengerBond : s.defenderBond;
        uint256 minNew = currentMax * minEscalationMultiplier / 10000;
        require(newBond >= minNew, "escalation too small");
        require(newBond <= maxBondCap, "exceeds bond cap");

        uint256 existing = (msg.sender == s.challenger)
            ? s.challengerBond : s.defenderBond;
        uint256 topUp = newBond - existing;
        require(msg.value == topUp, "incorrect top-up");

        _depositToVault(gameId, msg.sender, topUp);

        if (msg.sender == s.challenger) {
            s.challengerBond  = newBond;
            s.pendingResponder = s.defender;
        } else {
            s.defenderBond    = newBond;
            s.pendingResponder = s.challenger;
        }

        s.roundDeadline = block.timestamp + responseWindow;
        s.status        = GameStatus.Escalated;

        emit BondEscalated(gameId, msg.sender, newBond);
    }

    /// @notice Called when a party fails to match within the response window.
    function concede(bytes32 gameId) external {
        EscalationState storage s = games[gameId];
        require(s.status == GameStatus.Active || s.status == GameStatus.Escalated,
                "not active");
        require(block.timestamp > s.roundDeadline, "window still open");

        // The pending responder has forfeited.
        address loser = s.pendingResponder != address(0)
            ? s.pendingResponder
            : s.defender; // defender never responded

        _settleGame(gameId, s, loser);
        emit PartyForfeited(gameId, loser, _bondOf(s, loser));
    }

    /// @notice Called after ProofAggregator has reached a final status.
    function resolve(bytes32 gameId) external {
        EscalationState storage s = games[gameId];
        require(s.status != GameStatus.Resolved && s.status != GameStatus.Forfeited,
                "already settled");

        IProofAggregator.Status ps = aggregator.gameStatus(gameId);
        require(
            ps == IProofAggregator.Status.Accepted ||
            ps == IProofAggregator.Status.Rejected,
            "proof not finalised"
        );

        address loser = (ps == IProofAggregator.Status.Accepted)
            ? s.challenger  // defender wins
            : s.defender;   // challenger wins

        _settleGame(gameId, s, loser);
    }

    // -- Internal --

    function _settleGame(bytes32 gameId, EscalationState storage s, address loser) internal {
        address winner = (loser == s.challenger) ? s.defender : s.challenger;

        uint256 loserBond  = _bondOf(s, loser);
        uint256 winnerBond = _bondOf(s, winner);
        uint256 fee        = loserBond * protocolFeeRate / 10000;
        uint256 payout     = winnerBond + loserBond - fee;

        s.status = GameStatus.Resolved;

        _withdrawFromVault(gameId, winner, payout);
        _withdrawFromVault(gameId, treasury, fee);

        emit GameResolved(gameId, winner, payout);
    }

    function _bondOf(EscalationState storage s, address party) internal view returns (uint256) {
        if (party == s.challenger) return s.challengerBond;
        if (party == s.defender)   return s.defenderBond;
        return 0;
    }
}

State Machine

                  openChallenge()
                       │
                    [ Open ]
                       │  respond() within responseWindow
                       │
                    [ Active ]
                       │
             ┌─────────┴─────────┐
       escalate()           concede() / resolve()
             │                   │
         [ Escalated ]       [ Forfeited / Resolved ]
             │
    match within responseWindow?
             │
      ┌──────┴──────┐
    Yes             No
      │              │
  [ Active ]    [ Forfeited ]
      │
  resolve() (proof finalised)
      │
  [ Resolved ]

Integration Points

• DisputeGame: EscalationGame is called by DisputeGame.challenge() to lock the challenger’s bond and start the timer.
• ProofAggregator (Section 8): EscalationGame.resolve() reads ProofAggregator.gameStatus() to determine the winner once proofs are finalised.
• DisputeGame.resolve(): Requires EscalationGame to be in Resolved or Forfeited state before finalising the dispute outcome on-chain. This ensures the economic and proof-based layers are both settled before state root finalisation.

9.10 Summary