Fraud Detection
Cocoon's rollup operates optimistically by default: the sequencer posts state roots, and the network assumes they are correct unless challenged. Fraud proofs are the enforcement mechanism — any observer can challenge an incorrect state root and, through a bisection protocol, force on-chain verification of the exact point of disagreement.
Fraud proofs are the security foundation of the optimistic execution model. They make it economically irrational for a sequencer to post invalid state roots, because any invalid transition can be detected and proven on-chain within the challenge window.
When Fraud Proofs Apply
A sequencer posts batches of transactions and a claimed post-state root to L1. Any full node that has re-executed those transactions can compare its local QMTree root against the posted root. A mismatch means the sequencer is either incorrect or dishonest. The fraud proof protocol resolves this dispute on-chain without trusting either party.
The protocol terminates with either:
The challenger proving a specific EVM instruction was executed incorrectly (sequencer is slashed)
The challenger failing to sustain the challenge within time limits (challenger forfeits bond)
Three-Level Bisection Protocol
Disagreement could exist at the level of a block, a transaction within a block, or a single opcode within a transaction. Identifying the exact point of disagreement via brute-force on-chain re-execution is infeasible. Bisection narrows the search space efficiently.
Level 1: Block Bisection
The challenger and sequencer perform binary search over the QMTree roots of the disputed block range. At each step, the sequencer must post the QMTree root for the midpoint block. The challenger checks this root against its own computation. The round continues until a single divergent block is identified.
For a dispute over a 1024-block range, this takes approximately 10 rounds. Each round has a 1-hour response window.
Level 2: Transaction Bisection
Once a divergent block is identified, the protocol drills into the block's transactions. Each QMTree leaf contains four independently inspectable components:
preStateHash — if this diverges, the previous transaction (or block) introduced the error
stateChangeHash — if this diverges but preStateHash agrees, the execution of this transaction produced wrong state changes
transitionHash — if stateChangeHash agrees, the execution trace diverges (wrong opcodes or intermediate values)
previousLeafHash — chain integrity check
This component-level comparison identifies the type of divergence and narrows the scope for Level 3.
Level 3: Instruction Bisection
Within the identified transaction, the opcode trace is bisected. The trace is a sequence of (opcode, stack, memory, gas) tuples committed by the transitionHash. Binary search over this sequence finds the single instruction where the sequencer's execution diverges from the challenger's.
That single instruction is then re-executed on-chain by the MIPS/RISC-V single-step verifier contract. The contract is deterministic: given the pre-instruction state (stack, memory, storage), it computes the post-state and compares it to the sequencer's claimed post-state.
Challenge Window and Timing
Challenge window
7 days from batch posting
Response window per round
1 hour
Worst-case total dispute time
~20 hours (across all bisection rounds)
Minimum rounds (Level 1)
~10 for large ranges
The 7-day challenge window provides ample time for any observer running a full node to detect and initiate challenges. The 1-hour per-round response requirement prevents challenges from being used as indefinite delay tactics.
A sequencer that fails to respond within a round's window automatically forfeits — the challenger wins without needing to complete the bisection. This prevents a malicious sequencer from exhausting challengers through inaction.
Hybrid Model: Fraud Proofs and ZK
Fraud proofs are the fallback. When a ZK proof is available and verified, the challenge window closes immediately — there is nothing to dispute if the ZK proof guarantees correct execution.
In practice: ZK proofs are generated asynchronously. For most batches, a ZK proof will be available before the 7-day window expires, providing ZK-equivalent security. For periods where the prover is lagging, the fraud proof mechanism ensures the optimistic model remains sound.
This hybrid model means Cocoon does not depend on ZK proof availability for security — fraud proofs provide a reliable floor, while ZK proofs provide faster finality when available.
Security Considerations
Slashing for frivolous challenges — challengers must post a bond when filing a challenge. A challenge that fails (because the sequencer was correct) results in the bond being slashed. This discourages spam challenges that could delay batch finalization.
Data availability requirement — the fraud proof protocol requires that all transaction data is available on-chain (or via a DA layer accessible to all parties). A sequencer that withholds transaction data cannot be challenged on instruction-level execution — the protocol treats data withholding as a forfeit condition.
QMTree dependency — the entire bisection protocol depends on QMTree commitments being included in posted batches. The transitionHash in each leaf is what makes instruction-level bisection possible. Batches without valid QMTree commitments are rejected by the L1 rollup contract.
Key Contracts
BisectionGame
Manages active challenges, tracks bisection state per dispute
SingleStepVerifier
On-chain single-instruction EVM re-execution (Level 3 endpoint)
ChallengeManager
Bond management, challenge initiation, timeout enforcement
RollupContract
Accepts batches, enforces challenge window, calls settlement
Last updated