Search for projects by name or address
Native rollups turn L2 blocks into proof-carrying transactions on L1. Ethereum verifies that every block follows its 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 recognized by L1, so upgrades can propagate without a separate rollup upgrade or governance vote.
Operators still generate proofs, but Ethereum's consensus-layer proof infrastructure verifies them. 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 against Ethereum's own execution program, submits the proof to L1, and lets its settlement contract advance the chain.
The operator executes an L2 block and proves Ethereum's stateless payload-validation program with one or more supported zkVM backends.
A new L1 transaction type commits to the L2 data in blobs, the proof backends and program identity, and a hash of the proof’s public values.
Raw proofs travel in ephemeral sidecars. Ethereum clients validate them through a program-agnostic proof engine, while recursive aggregation keeps verification efficient at scale.
The rollup contract confirms that Ethereum verified the right program and block data, then accepts the new L2 state root.
Native rollups are one use of a broader proposal: let any smart contract consume proofs already verified by Ethereum's consensus infrastructure.
The proof engine can verify arbitrary guest programs, making the primitive useful to custom-VM rollups and other ZK applications too.
A transaction can require distinct zkVM backends to prove the same statement, without a rollup deploying its own proof router.
zkVM verification fixes can ship in Ethereum client releases 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 - centralized sequencing with fast preconfirmations, 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 a program-agnostic proof architecture. Future dates are targets, not Ethereum fork commitments.
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 moreThe ethrex / LambdaClass team demonstrates EIP-8079 via L1 re-execution. It validates the contract and messaging model, but is a prototype rather than the target ZK architecture.
Learn moreA program-agnostic design replaces EXECUTE in the ZK path with proof-carrying transactions and consensus-layer verification reusable by any ZK application.
Learn moreAn L1 inbox lets users bypass the sequencer by submitting signed L2 transactions that the rollup enforces through FOCIL-style inclusion lists.
Learn moreAlign the specification and a client implementation with the latest execution and consensus work, including ePBS, block-level access lists, FOCIL, and stateless validation.
Turn the research proposal into an EIP and run a CL+EL devnet with proof-carrying transactions and the ZK version of the native-rollup specification.
Specify how proof-carrying transactions bind L2 transactions and block access lists to data made available through EIP-8142.
Define recursive aggregation, proof propagation, pricing, and resource limits so L1 can efficiently cover many proof-carrying transactions.
Native rollups are not part of any scheduled Ethereum hard fork. EIP-8079 remains a draft, the EIP-8025 feature is experimental, and proof-carrying transactions are still a research proposal.
Native proof verification depends on several unfinished L1 components and unresolved protocol choices.
A new L1 transaction type that carries program and backend identities plus a public-values commitment, exposed through dedicated EVM opcodes.
Generalize the EIP-8025-style consensus infrastructure so clients can verify arbitrary guest programs, not only L1 execution proofs.
Recursive aggregation folds proof sidecars into an L1 block proof, avoiding one additional validator-side verification for every rollup update.
EIP-8142-style Blocks-in-Blobs must bind L2 transactions and block access lists to data that Ethereum makes available.
Proof propagation needs pricing, size bounds, backend diversity rules, and protection against excessive builder and client workloads.
Custom guest programs need identifiers that survive zkVM patches. Native EVM rollups avoid this issue by always referring to the execution program recognized by Ethereum.
Explore native proof verification, the technical book, the original EXECUTE research, and implementation work.
The program-agnostic proposal for proof-carrying transactions, multi-proofs, and consensus-layer verification.
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.
The open technical notebook covering native execution, settlement contracts, messaging, fees, and proof design.
The living specification, design notes, proof examples, and forced-inclusion prototypes behind this page.
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 experimental consensus-layer proof infrastructure that native proof verification proposes to generalize.
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 behind a feature flag.
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).
