Search for projects and tokens by name or address
Native rollups post each L2 block to L1 in a frame transaction whose proof Ethereum verifies itself. Every block follows Ethereum's own EVM rules, while the rollup stays free to customize sequencing, messaging, and chain policy.
A native rollup proves the same EVM state transition program that Ethereum accepts for itself. Instead of being pinned to one EVM version, it follows the version L1 records at each fork in the EIP-8357 registry, so upgrades propagate without a separate rollup upgrade or governance vote.
Operators still generate proofs, but Ethereum aggregates and verifies them with each block. Rollups no longer need to independently deploy and govern verifier contracts, adapters, proof routers, and circuit upgrades for EVM execution.
A native rollup proves its blocks with Ethereum's own execution program, declares each proof in an L1 transaction, and lets its rollup contract advance the chain.
The operator executes an L2 block and proves it with Ethereum's stateless validation program, the same program that proves L1's own blocks.
An EIP-8141 frame transaction carries the block data in blobs, declares the proof as an EIP-8288 dependency, and calls the rollup contract.
Proofs travel through the mempool and never enter the block. Mempool nodes and the builder aggregate them recursively into one proof per block, which validators verify.
The rollup contract rebuilds what the proof must commit to, checks the program against the EIP-8357 registry, and accepts the new L2 state root.
EIP-8288 lets any EIP-8141 frame transaction depend on proofs that Ethereum verifies. Native rollups are the minimal case: they use Ethereum's own EVM program.
A frame transaction can depend on a proof of any program, under that program's verification key, making the primitive useful to custom-VM rollups and other ZK applications too.
Proofs never enter the block. Mempool nodes and the builder fold them into one recursive proof per block, which validators verify.
Verifier fixes ship with Ethereum upgrades instead of every project separately upgrading onchain verifier contracts.
Native rollups keep the parts that make a chain distinctive configurable through smart contracts, while execution stays identical to Ethereum.
Define sequencing policy in the rollup contract: a centralized sequencer whose preconfirmations are backed by a slashable bond, based sequencing, or a staked network.
The programmable settlement contract lets a rollup keep its own configuration, such as a DAO-controlled fee recipient or opinionated gas limits, around L1's shared execution rules.
Choose a token other than ETH for transaction fees. Ethereum-native messaging can bridge it from L1 and make it available as the gas token on L2.
Instead of automatically burning the base fee, direct it to a rollup treasury, sequencer, or another funding mechanism.
The research has moved from the original EXECUTE proposal to proofs declared through EIP-8288 and checked against the EIP-8357 registry. What comes next depends on L1, so it has no dates.
Justin Drake publishes “Native rollups - superpowers from L1 execution” on ethresear.ch, introducing the EXECUTE precompile that lets a rollup reuse Ethereum's own execution for verification.
Learn moreL2BEAT publishes an open research book covering governance risk, bug risk, native execution, messaging, fees, and the evolving proof design.
Learn moreThe original re-execution path is formalized around the EXECUTE precompile, together with fee accounting and an anchoring mechanism for L1→L2 messaging.
Learn moreProof-carrying transactions: a program-agnostic design that replaces EXECUTE in the ZK path with a new transaction type and consensus-layer proof verification. It is now the main alternative to EIP-8288.
Learn moreAn L1 inbox lets users bypass the sequencer by submitting signed L2 transactions that the rollup enforces through FOCIL-style inclusion lists.
Learn moreThe ethrex / LambdaClass team merges a proof of concept of EIP-8079 via L1 re-execution. It validates the contract and messaging model, but is a prototype rather than the target ZK architecture.
Learn moreProofs that EIP-8141 frame transactions declare as dependencies, aggregated recursively in the mempool and by the builder, are merged as a Draft EIP. The book adopts them as the proof path for native rollups.
Learn moreThe specification follows Glamsterdam's block-level access lists and stateless validation program, and posts blocks with Hegotá's EIP-8141 frame transactions.
Learn moreAn L1 contract that records the verification key of Ethereum’s EVM program at each fork, so native rollups follow L1 upgrades without their own governance, is merged as a Draft EIP.
Learn moreThe specification’s rollup contract runs end to end on a local EIP-8141 devnet, with mock proofs signed by a trusted key, and a public explorer that rebuilds every L2 block from L1.
Learn moreEach L1 feature the devnet stands in for replaces its mock as it lands upstream. The EIP-8357 registry is already in its genesis; real proofs, EIP-8288, and Block-in-Blobs come next.
EIP-8288 defines its block digest only for signature dependencies, and leanVM aggregates proofs of one fixed program. Native rollups need to declare proofs of any program as LeanSTARK dependencies, more than one per mempool wrapper.
Learn moreFinish the registry’s tests and system contract, and propose it together with EIP-8288, so the fork that brings proof dependencies also brings the EVM program’s keys.
Learn moreSpecify how Ethereum’s mandatory block proof binds and absorbs the EIP-8288 aggregate, so validators verify a single proof without downloading full payloads.
The specification binds L2 data to blobs through EIP-8142, which was declined for Hegotá. Native rollups need a path: EIP-8142 in a later fork, or another way to bind the data.
Learn moreReplace the signed mock proofs with zkVM proofs of the same program, once the execution and consensus specifications agree on what the proof commits to.
Research an extensible native program, which Arbitrum and Optimism have shown interest in: a rollup that follows Ethereum’s EVM through the EIP-8357 registry and maintains only its own precompiles, opcodes, or transaction types.
Native rollups are not part of any scheduled Ethereum hard fork. EIP-8288 and EIP-8357 are drafts, optional execution proofs (EIP-8025) are proposed for Hegotá, and the mandatory proofs native rollups need are expected in K* at the earliest.
Native rollups depend on several unfinished L1 components and open protocol questions.
One L1 block proof that validators verify instead of re-executing, and that also covers the rollups’ proofs. Expected in K* at the earliest under the current strawmap.
The transaction envelope that carries an L2 block and declares its proof. Scheduled for Hegotá.
Proofs declared by frame transactions and aggregated recursively in the mempool and by the builder. A Draft, with open questions on mempool proving costs and on how the aggregate enters the block proof.
Records which verification key is Ethereum’s EVM program at each fork, so rollups follow L1 upgrades without their own governance. A Draft EIP, not yet in a fork.
The zkVM shared by L1 and EIP-8288 must prove the stateless validation program and verify proofs of any program under its key. leanVM is moving to RISC-V toward this.
Block-in-Blobs (EIP-8142) binds L2 transactions and block access lists to data that Ethereum makes available. It was declined for Hegotá.
Explore the technical book, the live devnet, EIP-8288 and EIP-8357, the original EXECUTE research, and implementation work.
The open technical notebook covering native execution, settlement contracts, messaging, fees, and proof design.
A native rollup running on a local EIP-8141 devnet, with an explorer that shows what is real and what is still mocked.
The frame mode through which a transaction declares the proofs it depends on, aggregated recursively in the mempool and by the builder.
The L1 registry of the EVM program’s verification keys, which lets native rollups follow L1 upgrades.
The book’s source, the native rollup contract, the devnet and its explorer, and the forced-inclusion prototype.
How an L1 inbox can give EVM rollups forced transactions without changing their execution rules or introducing a custom transaction type.
The working forced-inbox implementation, including transaction validation, queueing, pruning, settlement, and gas tests.
Proof-carrying transactions, the main alternative to EIP-8288: a new transaction type with consensus-layer proof verification.
The January 2025 founding post that introduced native rollups through the EXECUTE precompile.
The original draft EIP for native rollups, centered on the re-execution precompile design.
The consensus-layer infrastructure for execution proofs, on the way to the mandatory proofs native rollups need.
The draft mechanism for keeping execution payload data available when validity is checked with ZK proofs.
The Phase-1 proof-of-concept implementing EIP-8079 via re-execution.
A session on the broader primitive that lets L1 verify proofs for native rollups and arbitrary guest programs.
L2BEAT's talk on scaling Ethereum through native rollups.
A short introduction to the original native rollups and EXECUTE proposal.
L2BEAT's Luca Donno on scaling Ethereum — including native rollups (TOKEN2049 Singapore 2025).
