
ENDGAME: How we use ZK to secure MegaETH
At the core of every optimistic rollup lies a critical assumption: that submitted state proposals are valid unless proven otherwise. This assumption, however, only holds true if the rollup is backed by a robust fraud proof mechanism. Without one, the chain becomes insecure the moment an invalid state goes unchallenged or can have its settlement process stalled by malicious challenges.
The Burden of Proving Fraud
To secure this assumption, an optimistic L2 must support a fraud proof mechanism (also called a dispute resolution protocol) that allows validators (the challenger) to challenge potentially incorrect state proposals submitted by the sequencer (the proposer). These mechanisms must ensure two critical properties:
- Incorrect state proposals are always caught, and
- Incorrect challenges never prevail.
Under the hood, this mechanism has two core components:
- A challenge subprotocol, which handles disputes over a single state proposal.
- A tournament mechanism, which is responsible for sorting through potentially many competing state proposals for the same block to determine the uniquely correct one.
Each state proposal is a claim about the result of executing a set of transactions. It has three parts:
- The initial state is the most recently finalized L2 state on Ethereum.
- The payload is the sequence of L2 transactions since that point.
- The final state is what the proposer claims results from executing that payload.
Thus, a single proposal effectively says:
"Given this initial state and this list of transactions (the payload), I claim the final state should be X."
Visualized:

An overview of the components which make up a state proposal and challenge
It's the job of the challenge subprotocol to test that assertion. If it's false, the challenge must succeed and the proposal must be rejected.
Interactive Fault Proofs (Bisection Game)
The classic approach, used in most optimistic systems today, sees the challenger and the proposer engage in a back-and-forth interactive protocol.
Once a dispute has been made, both parties bisect the transcript (step-by-step intermediate results of the computation claimed by the proposer) breaking it into halves, narrowing down where the error lies. This continues recursively until the parties isolate a single faulty computation step (such as the incorrect execution of a transaction). Once identified, this step is replayed on Ethereum to determine whether fraud occurred.

The classic bisection games which take place during the challenge of an optimistic settlement
This system has several problems:
- Latency: Each interaction requires a transaction on Ethereum. A single dispute can take hours or even days, especially under network congestion or censorship.
- Heavy proposer involvement: Even if the proposer is honest and the challenge is baseless, the proposer still has to participate in every step of the dispute, doing non-trivial work.
- Griefing risk: Dishonest challengers can force honest proposers to waste time and gas defending correct states, over and over again.
In practice, interactive proofs are expensive, fragile under load, and prone to abuse.
Non-Interactive Fraud Proofs (ZK Challenge Model)
MegaETH will take a different approach, requiring the challenger to simply compute a single succinct zero-knowledge proof showing that the claimed final state is invalid. Specifically, the proof demonstrates that executing the payload from the initial state does not result in the final state claimed by the proposer. This will be done using the RISC Zero zkVM, following the OP Kailua hybrid architecture for non-interactive fraud proofs.
This proof is submitted to Ethereum in a single transaction, and the onchain verifier contract confirms its validity. The proposer does no work, cannot interfere with the process and plays no role in the dispute.

The ZK Fraud Proofs process being pioneered by MegaETH
Generating the proof is non-trivial — it requires running the disputed computation inside a zkVM, which is estimated to take 100 billion cycles and cost in the order of $100 in the worst case [1]. But this cost is incurred only when fraud is proven, and by design, borne by the dishonest party. This removes the capital burden from honest challengers and eliminates the griefing risk common in bisection-based systems.
ZK for Fraud, not Validity
In crypto, “zero-knowledge” is often treated as shorthand exclusively for ZK rollups — systems that use ZK proofs to verify state transitions before posting them onchain. But that framing captures only one side of what ZK can enable.
MegaETH uses ZK not to prove correctness, but to prove fraud. This lets us retain the optimistic rollup model — with its efficiency and scalability — while adding a trust-minimized, non-interactive mechanism to detect and challenge invalid state transitions.
We refer to this hybrid approach as ZK fraud proofs, and it enables a fundamentally different trust model.
Same Detection Window, Radically Shorter Time-to-Finality
Out of an abundance of caution, MegaETH will retain the 7-day challenge window typical of optimistic chains, meaning that any participant will have a full week to raise a dispute against a proposed state root. It is what happens after a challenge is raised, that differs dramatically.
In the interactive model a challenge submitted on day 7 might take a few more days to resolve, which freezes the chain's finality on Ethereum until the dispute plays out. During that time, protocols remain in limbo and the chains liveness is compromised.
With a ZK fraud proof, the entire dispute is resolved in ~1 hour. The challenger generates the proof, submits it to the L1, and the result is final.
This protects the chain from a dangerous attack vector: malicious challengers repeatedly initiating bogus disputes to stall finalization.
Secured by EigenDA
To ensure the integrity of the fraud proof process, challengers must have easy, reliable access to the raw block data needed to recreate disputed computations. That's why we pair our ZK fraud model with a EigenDA—a decentralized, high-throughput data-availability layer.
This allows the process to be distilled to its most secure and efficient form:
- The sequencer publishes block data to EigenDA, and commits only a small reference to Ethereum. EigenDA's cryptographic guarantees ensure that a proof can always be produced and that the sequencer cannot 'withhold' data to evade detection.
- Any watcher can retrieve the block data, reconstruct the full block and run it through the zkVM.
- If fraud is detected, the watcher generates a succinct ZK fraud proof, submits it to the verifier contract on Ethereum, the sequencer is slashed and its invalid proposal rejected.
A Cryptographically Sound, Scalable Trust Model
MegaETH replaces tedious interactive fraud games with succinct, non-interactive ZK fraud proofs. This removes griefing risk, slashes finality time, and ensures disputes are resolved in an efficient and scalable manner.
With RiscZero enabling provable computation and EigenDA ensuring access to raw data, every proposal becomes re-constructable, provable, and challengeable by anyone at any scale.
[1] “Withdrawal Delay.” The Kailua Book, risc0.github.io/kailua/. Accessed 22 July 2025.
Published: 07/23/2025