Summary

The Ethereum Foundation’s Platform team (announced 2026) frames L1 and L2s as complementary layers in an integrated ecosystem: L1 provides neutral settlement, data availability, and shared finality; L2s provide execution differentiation, lower fees, and specialized features. The goal is “native rollups” — L2s that inherit L1 security without custom proving infrastructure. MEV design decisions at each layer affect the overall stack.

The Two-Layer Vision

L1’s Role

  • Neutral settlement: all L2s settle to L1; L1 is the canonical source of truth
  • Data availability: blob storage for L2 transaction data (post-EIP-4844)
  • Shared finality: L1 finality (~12.8 min, or ~13s with FCR) applies to all L2s settling to L1
  • Credible neutrality: L1 doesn’t favor any particular L2 or application

L2’s Role

  • Execution differentiation: custom block times (sub-second on some chains), custom EVM extensions, specialized sequencers
  • Fee compression: off-chain execution + on-chain data is cheaper than full on-chain execution
  • Application-specific features: custom fee tokens, privacy layers, permissioned execution, specialized MEV rules (Timeboost/Kairos on Arbitrum)

The Tension

L2s want to differentiate aggressively; L1 wants all L2s to be good Ethereum citizens (censorship-resistant, using standard tooling, contributing to L1 security budget). The EF Platform team’s job: reduce friction between these goals.

Current Problems

EVM Fragmentation

  • Each L2 runs a slightly different EVM version
  • OP chains lagged on EOF; Arbitrum has STYLUS (Rust/WASM contracts)
  • dApps must maintain separate deployments, audit multiple versions
  • Smart contract exploits on one L2 don’t alert developers on others

Cross-Chain UX Friction

  • Users hold ETH on 5 different chains; moving between them requires bridges
  • Bridge times: 10–20 minutes (optimistic), seconds (ZK), but always multiple steps
  • No atomic cross-chain composability (EEZ is the proposed fix)

L2 Security Dependency

  • L2s depend on L1 sequencers (often a single company) for transaction ordering
  • Sequencer downtime → L2 unavailable (even though funds are safe on L1)
  • Decentralization of L2 sequencers is ongoing (Arbitrum BOLD, Optimism Superchain)

Native Rollups

The long-term goal: L2s become native rollups where:

  1. The L2’s execution is the same code as the L1’s execution client
  2. The L1 validator set produces validity proofs for L2 execution as part of regular work
  3. No custom proving infrastructure needed; L1 validators are the provers
  4. L2 inherits L1’s security without a separate trust assumption

Why this works: post-zkEVM, L1 validators already verify proofs for L1 execution. The same mechanism extended to L2 execution requires only proving the L2’s state transition — using the L1’s own EVM.

State of progress (2026):

  • Optimism’s Superchain is the closest in spirit (shared infrastructure, L1-aligned governance)
  • Arbitrum’s Stylus shows willingness to diverge (custom execution environments)
  • Polygon’s AggLayer aims for shared liquidity across ZK chains (similar goal, different approach)
  • EF Platform team coordinating toward a standard native rollup spec

MEV at Different Layers

The relationship between L1 and L2 creates interesting MEV dynamics:

L2 Sequencer MEV

  • L2 sequencers control transaction ordering within the L2
  • Current approaches: FCFS (First Come First Served), auction-based (Timeboost), randomized
  • Sequencer revenue from MEV is not shared with L1 validators

Cross-Layer MEV (Sandwich L1→L2)

  • A transaction that spans L1 and L2 (e.g., bridge + swap) can be sandwiched at either layer
  • L2 sequencer controls L2 ordering; L1 builder controls L1 ordering
  • Atomic cross-chain MEV requires coordination between L1 builder and L2 sequencer (currently impossible; EEZ would enable it)

Timeboost and Kairos (Arbitrum Case Study)

Arbitrum’s custom MEV solution on L2:

Timeboost v1: ahead-of-time auction for ordering priority

  • Protocol MEV capture: fell from 63% → 15% after adoption
  • Cause: winner-takes-all advance auction created weak competition equilibrium

Kairos redesign: hybrid advance + real-time auction

  • Partially restored protocol MEV capture
  • Lesson: L2s can experiment with novel MEV designs; L1’s PBS model is not the only option

This is an example of “L2 for differentiation” — Arbitrum can experiment with MEV rule changes that would be too risky to deploy on L1.

L1 Security Budget and L2

A concern for the long run: as L2s capture more transaction fees (leaving less on L1), L1’s security budget decreases:

  • L1 security = validator rewards = transaction fees + ETH issuance
  • If all activity moves to L2s, L1 fees collapse
  • Validators have less incentive to stake; less security

Current mitigation:

  • L2s pay L1 for blob data (blob fees)
  • ePBS and MEV Boost maintain healthy L1 MEV revenue
  • EIP-1559 burn creates deflationary pressure even with lower fees

Long-term concern (open): if blob fees approach zero (as Fusaka’s scaling suggests), L1 revenue becomes primarily from base issuance and EVM execution — a thinner buffer.

Geographic Implications for L2

  • L2 sequencers are even more geographically concentrated than L1 validators (single-company sequencers in US/EU)
  • L2 transactions from Asia/LatAm must reach US/EU sequencers → additional latency
  • L2 decentralization (multiple sequencers) partly addresses this but adds consensus overhead

Key Sources

  • How L1 and L2s Can Build the Strongest Possible Ethereum (EF Platform, 2026) — native rollups; settlement hub; L1-L2 relationship framing
  • When Ahead-of-Time Allocation Fails: The Transition to Kairos (2026) — Timeboost case study; protocol capture; Kairos redesign