Status and roadmap

Last updated: November 2026.

Table of Contents

• Where things stand
• L1 dependencies
• The case for native rollups
• Timeline
  • Can anything ship earlier?
• Open question: upgrades with the zkEVM
• Next steps

Where things stand

• Reusing the L1 STF is largely specified in the Specification, and ethrex has merged a proof of concept of the earlier EXECUTE precompile design, already on Glamsterdam. The remaining issues are newer EIPs, such as Block-in-Blobs, and compatibility with future L1 upgrades.
• Proof-carrying transactions, proposed in the Native proof verification post in May 2026, are the main alternative to EIP-8288. The book follows EIP-8288, as explained in the introduction.
• PCS opening aggregation, prototyped in November 2026, is an early alternative to EIP-8288’s LeanSTARK scheme, with no EIP yet. L1 would fix one field and one polynomial commitment scheme, and each block would aggregate only the proofs’ openings, while an ordinary contract verifies the rest of each proof. The prototype verifies a leanVM proof in about 45,000 gas, with the precompile mocked and the opening claims free; their real price depends on the block’s aggregator, which is not built yet.
• EIP-8288 (zkzkframes) was merged as a Draft on 9 September 2026. See EIP-8288 (zkzkframes).
• The reference implementation: the NativeRollup contract runs end to end on a local EIP-8141 devnet, with real L2 blocks, mock proofs, and the EIP-8357 registry in its genesis. A public explorer shows each L2 block and message, and what is still mocked.
• EIP-8357, the EVM verification key registry, was merged as a Draft on 14 October 2026, with a reference implementation in ethereum/sys-asm#56 and tests in ethereum/execution-specs#3466. See EIP-8357.

L1 dependencies

The case for native rollups

If there is no confidence that many existing rollups will become native, is the upgrade worth it? Several teams have expressed interest, including Gnosis, Celo, Linea, Taiko, and Scroll. Even so, native rollups are worth shipping only if the feature is kept minimal, so that its low complexity justifies it even if usage turns out to be low.

Top rollups such as Arbitrum and Optimism have instead expressed interest in an extensible native program, explored in Native rollups with extensions. A more ambitious direction is to use native rollups as a form of execution sharding.

Timeline

Mandatory proofs and a zkzkframes-like feature are both hard requirements. According to the strawmap, zkzkframes can go live in 2028-2029 at the earliest. The Ethereum Foundation’s protocol priorities post places mandatory proofs in K* under the current strawmap ordering, and notes that they may move back to L* if the strawmap swaps the two forks to accelerate post-quantum consensus.

Can anything ship earlier?

Probably not. The original proposal suggested shipping native rollups through re-execution instead of ZK proofs. Re-execution, however, only supports optimistic rollups with bisection games, which still require a long challenge period for withdrawals, something all rollups are trying to move away from.

Another suggested path is to ship native rollups and generalized proof verification before mandatory proofs, as a testing ground: if something fails, only the applications that chose to take that risk fail, not all of L1. Delaying mandatory proofs is not desirable, but this remains an option if there is not enough confidence to ship them at all.

Open question: upgrades with the zkEVM

How will upgrades work with the zkEVM? Suppose a bug is found: how do nodes upgrade? Today, most patches are backwards compatible until the bug is hit in production. With the zkEVM, the verification key needs to change, and old proofs can no longer be verified. What does the runbook for this scenario look like?

Next steps

1. Make LeanSTARK dependencies work in EIP-8288: give them a place in the dependency digest, which is defined for LeanSPHINCS dependencies only, follow leanVM’s move to RISC-V until it can verify proofs of arbitrary programs, and allow more than one per mempool wrapper (see EIP-8288 open issues).
2. Bring EIP-8357 to clients and a fork: finish its review, tests, and system contract, and propose it together with EIP-8288.
3. Specify how the mandatory L1 proof binds and absorbs the EIP-8288 aggregate.
4. Find a path for L2 block data now that EIP-8142 was declined for Hegotá: EIP-8142 in a later fork, or another way to bind the data to blobs.
5. Replace the reference implementation’s mock proofs with zkVM proofs of the same program, once the execution and consensus specifications agree on what the proof commits to.
6. Research native rollups with extensions.