Native Rollup (Enshrined Rollup)

What Is a Native Rollup?

A native rollup (also called an enshrined rollup) is a rollup whose proof verification is built directly into the base layer protocol rather than relying on a smart contract deployed on L1. In today's rollup landscape, projects like Optimism, Arbitrum, zkSync, and Starknet all deploy verifier contracts on Ethereum that validate state transitions. A native rollup replaces those contracts with protocol-level logic that L1 validators execute as part of consensus itself.

The concept was formalized by Ethereum researcher Justin Drake in January 2025, who proposed an EXECUTE precompile that allows Ethereum to re-execute rollup computations natively. This led to EIP-8079, co-authored with L2BEAT's Luca Donno in November 2025, which formalizes the precompile design. The proposal remains in draft status and is not part of any scheduled Ethereum hard fork.

The motivation is straightforward: EVM-equivalent rollups currently invest significant resources building and maintaining complex proof systems just to replicate what Ethereum already provides on L1. Native rollups let the protocol do the work instead.

How It Works

Today's rollups verify state transitions through smart contracts deployed on Ethereum. These contracts accept either fraud proofs (for optimistic rollups) or validity proofs (for ZK rollups). The contracts are upgradeable, governed by multi-sig wallets or governance tokens, and represent a trust assumption outside of Ethereum's own consensus.

Native rollups replace this entire verification layer with a protocol-level function. The process works as follows:

1. The rollup submits its transaction batch and resulting state root to Ethereum L1, just as current rollups do
2. Instead of a smart contract checking the proof, L1 validators invoke the EXECUTE precompile to re-execute the rollup's state transitions using Ethereum's own execution engine
3. The precompile compares the re-executed state root against the submitted one
4. If the roots match, the rollup's state transition is accepted as valid by the protocol; if they diverge, the batch is rejected

Because the verification uses Ethereum's own execution layer, native rollups inherit the full security of L1 consensus. There is no verifier contract to exploit, no admin key to compromise, and no governance vote that can alter the verification rules independently.

The EXECUTE Precompile

The centerpiece of the native rollup design is the EXECUTE precompile: a hardcoded function in the EVM that verifies EVM state transitions. Unlike a regular smart contract, a precompile runs at the protocol level and cannot be upgraded or paused by any external party.

EIP-8079 specifies the precompile alongside fee accounting and an anchoring mechanism for L1-to-L2 messaging. In simplified terms, the call signature looks like:

// Conceptual interface for the EXECUTE precompile
EXECUTE(
  pre_state_root,   // Rollup state before the batch
  post_state_root,  // Claimed state after the batch
  transactions,     // The batch of rollup transactions
  block_context     // L1 block data for anchoring
) -> bool           // True if re-execution confirms the post_state_root

The initial design uses re-execution (L1 validators literally replay the rollup transactions). Future iterations plan to incorporate zero-knowledge proofs so that verification can scale beyond what re-execution alone supports. Drake has described the re-execution path as a "stepping stone" toward a fully ZK-proven native rollup architecture.

Native Rollups vs. Smart Contract Rollups

The distinction between native and smart-contract-based rollups centers on where verification logic lives:

Native Rollups vs. Based Rollups

These terms are often confused but address different aspects of rollup design. A based rollup uses L1 validators for transaction sequencing (ordering), replacing a centralized sequencer. A native rollup uses the L1 protocol for proof verification, replacing verifier contracts. The two concepts answer different questions:

• Based rollups answer: who orders transactions? (L1 validators instead of a centralized sequencer)
• Native rollups answer: who verifies state transitions? (L1 protocol instead of a smart contract)

A rollup could be based without being native (using L1 sequencing but verifying via a contract), native without being based (using a centralized sequencer but verifying via the protocol), or both. The combination of based sequencing and native verification would create a rollup that is maximally aligned with L1 in both dimensions.

Use Cases

Governance-Minimized Rollups

The strongest use case for native rollups is eliminating governance risk from L2 infrastructure. Today, most rollup verifier contracts have upgrade mechanisms controlled by multi-sig wallets or governance tokens. A compromised multi-sig could alter the verification logic and steal user funds. Native rollups remove this attack surface entirely: verification logic can only change through the L1's own consensus process.

Eliminating Prover Infrastructure

ZK rollups invest heavily in prover networks: specialized hardware and software that generate validity proofs for each batch. These systems are expensive to build, maintain, and audit. Native rollups using re-execution remove the need for this infrastructure, since L1 validators handle verification directly. This lowers the barrier for launching an EVM-equivalent rollup significantly.

Shared Security Without Trust Assumptions

Current rollups inherit Ethereum's shared security only insofar as their verifier contracts are correct and their governance is honest. Native rollups inherit L1 security unconditionally: if Ethereum is secure, the rollup's verification is secure. This makes the security model identical to any other L1 operation like an ETH transfer or a base layer contract call.

Standardized L1-to-L2 Messaging

EIP-8079 includes an anchoring mechanism for deposits and withdrawals between L1 and the native rollup. This standardized messaging layer could simplify cross-rollup interoperability and reduce the fragmentation currently caused by each rollup implementing its own bridge contracts with different trust assumptions. A March 2026 prototype using the Ethrex execution client demonstrated L1-to-L2 deposits and withdrawal verification through state proofs.

Risks and Considerations

L1 Protocol Complexity

Embedding rollup verification into the protocol adds complexity to Ethereum's consensus layer. Every L1 validator must be capable of re-executing rollup transactions, increasing computational requirements. Protocol bugs become harder to isolate: a flaw in the EXECUTE precompile could affect L1 consensus itself, not just the rollup.

Slow Upgrade Cycle

Changes to native rollup verification require an Ethereum hard fork through the EIP process. This contrasts sharply with smart contract rollups, where teams can ship fixes and improvements through their own governance in days or weeks. For a fast-moving ecosystem where rollup designs evolve rapidly, this rigidity could become a bottleneck. Bug fixes, optimizations, and new features all depend on the broader Ethereum upgrade timeline.

Reduced Rollup Diversity

The EXECUTE precompile is designed for EVM-equivalent rollups. Rollups with custom execution environments (Starknet's Cairo VM, Fuel's FuelVM) would not benefit from native verification unless the protocol added precompiles for their specific VMs. This could create a two-tier system where EVM-equivalent rollups enjoy stronger security guarantees than non-EVM rollups.

Re-execution Scalability

The initial re-execution approach requires L1 validators to replay every rollup transaction. As rollup throughput grows, this could become a bottleneck for validators. The planned transition to ZK-proven verification addresses this concern, but it depends on advances in proof aggregation and zero-knowledge proof efficiency that have not yet been deployed at scale.

Early Stage of Development

As of late 2026, native rollups remain a research proposal. EIP-8079 is in draft status with test cases, reference implementation, and security considerations all marked as to-be-determined. No mainnet timeline exists. The design may change substantially before adoption, and there is no guarantee it will be included in any Ethereum upgrade. For a deeper analysis of how rollup economics and security models compare, see the rollup vs. state channel scaling tradeoffs research article and the rollup economics deep dive.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.