Table of Contents
The Ethereum Foundation (EF) researchers published “Strawmap,” a strawman roadmap for Ethereum Layer 1 (L1) protocol upgrades. The document, available at strawmap.org, outlines a long-term technical direction for Ethereum through the end of the decade.
Worth noting that Strawmap is not an official roadmap. Instead, it is a coordination tool designed to prompt discussion among researchers, client teams, and governance participants. It presents one coherent path among many possible outcomes in a decentralized system where rough consensus emerges over time.
This article explains what Strawmap proposes, how it structures Ethereum upgrades through 2029, and how it addresses performance, cryptography, privacy, and scalability at the base layer.
Who Created Strawmap and Who Is It For?
Strawmap originated at an Ethereum Foundation workshop in January 2026. It was later released publicly by the EF Architecture team, including Justin Drake, Ansgar Dietrichs, Barnabé Monnot, and Francesco D’Amato.
The document targets advanced readers and is written for protocol researchers, client developers, and Ethereum governance participants. In essence, Strawmap is described as a living document that is expected to receive at least quarterly updates.
What Does “Strawmap” Mean?
The name combines “strawman” and “roadmap.” The “strawman” qualifier reflects two realities:
- Ethereum has no single authority that can impose a final roadmap across all stakeholders.
- The document is a work in progress, not a prediction.
The roadmap assumes human-first development. It notes that AI-assisted development and formal verification could compress timelines.
How Is the Strawmap Structured?
Strawmap presents Ethereum upgrades on a single visual timeline extending from 2026 to 2029, with longer-term items beyond 2030.
It assumes a cadence of roughly one fork every six months and outlines seven forks:
- Glamsterdam (2026)
- Hegota (2026)
- I* (2027)
- J* (2028)
- K* (2028)
- L* (2029)
- M+ (2030 and beyond)
Forks are organized across three horizontal layers:
- Consensus Layer (CL)
- Data Layer (DL)
- Execution Layer (EL)
Each fork includes “headliners,” defined as major upgrades. The All Core Devs (ACD) process generally limits each fork to a single consensus and a single execution headliner to maintain cadence. An exception is L*, which includes two consensus headliners tied to lean consensus.
Long-term Goals for Ethereum
Strawmap defines five long-term goals:
1. Fast L1
Short slots and finality in seconds.
2. Gigagas L1
1 gigagas per second throughput, roughly 10,000 transactions per second (TPS), enabled by zkEVMs and real-time proving.
3. Teragas L2
1 gigabyte per second data bandwidth, or about 10 million TPS, via data availability sampling.
4. Post-Quantum L1
Hash-based cryptography to resist quantum attacks.
5. Private L1
Shielded ETH transfers at the base layer.
These goals focus on latency, throughput, cryptographic durability, and privacy.
Proposition: Reducing Ethereum’s Slot Time and Finality
Ethereum’s current average finality time is about 16 minutes. This is calculated as 12-second slots multiplied by 32-slot epochs and approximately 2.5 epochs.
Strawmap proposes incremental slot time reductions following a √2 progression:
12s → 8s → 6s → 4s → 3s → 2s.
Vitalik Buterin described this approach in response to the roadmap:
“I expect that we'll reduce slot time in an incremental fashion, eg. I like the ‘sqrt(2) at a time’ formula (12 -> 8 -> 6 -> 4 -> 3 -> 2, though the last two steps are more speculative and depend on heavy research). He added, “Fast slots are off in their own lane at the top of the roadmap, and do not really seem to connect to anything. This is because the rest of the roadmap is pretty independent of the slot time.”
A very important document. Let's walk through this one "goal" at a time. We'll start with fast slots and fast finality.
— vitalik.eth (@VitalikButerin) February 25, 2026
I expect that we'll reduce slot time in an incremental fashion, eg. I like the "sqrt(2) at a time" formula (12 -> 8 -> 6 -> 4 -> 3 -> 2, though the last two… https://t.co/ni9wIF2BgJ
Buterin didn’t outline a specific deployment timeline in his message. However, he referred to the strawmap as an organized plan detailing a series of technical objectives related to reducing slots, redesigning finality, and implementing cryptographic enhancements.
P2P Improvements and Erasure Coding
Shorter slots require improvements to block propagation. Raul Jordan's research focuses on an optimized peer-to-peer (P2P) architecture using erasure coding.
In this design, a block is split into pieces (for example, 8 pieces, of which any 4 can reconstruct the full block). This k-of-n structure reduces bandwidth overhead while improving the 95th percentile block propagation time. According to research data cited by Buterin, this architecture can make shorter slots viable without reducing security.
Finality Trajectory
Strawmap also proposes decoupling slots from finality. The long-term goal is to use a one-round BFT algorithm known as Minimmit.
A possible finality trajectory outlined by Buterin:
- 16 minutes (today)
- 10m40s (8-second slots)
- 6m24s (one-epoch finality)
- 1m12s (8-slot epochs, 6-second slots)
- 48s (4-second slots)
- 16s (Minimmit)
- 8s (more aggressive Minimmit parameters)
These changes involve a significant redesign of the consensus.
How Does Post-Quantum Cryptography Fit Into the Plan?
Strawmap integrates post-quantum upgrades with major consensus changes. The plan includes:
- Hash-based signatures
- Migration toward STARK-friendly hash functions
- Evaluation of responses to Poseidon2 cryptographic concerns
Three responses under research include increasing round counts, reverting to Poseidon1, or using BLAKE3.
Buterin noted that slots could become quantum-resistant before finality. In that scenario, a sudden quantum breakthrough might compromise finality guarantees while allowing the chain to continue producing blocks.
What Happens in the Execution and Data Layers?
Execution Layer
Key proposals include:
- Multi-dimensional gas accounting
- Block gas limit increases
- zkEVM integration
- Canonical zero-knowledge machines (ZKM)
- Native restaking
- Non-Interactive Transactions (NIT)
- Exascale ZKVM research
The long-term target is gigagas throughput at L1.
Data Layer
The roadmap includes:
- Blob Per Operator (BPO) changes
- Data availability sampling
- Simple size decreases in specific forks
- Return to calldata in selected cases
The teragas L2 target aims to scale rollups and data throughput without weakening decentralization.
Does Strawmap Signal a Shift From Rollup-Centric Scaling?
Ethereum’s prior roadmap emphasized rollups as the primary scaling mechanism. Strawmap does not remove rollups but outlines a stronger scaling path for L1 itself.
If realized, the roadmap would increase L1 throughput to 10,000 TPS while enabling L2 throughput of 10 million TPS. That approach reduces dependence on rollups alone for scalability.
Conclusion
Ethereum’s Strawmap presents a structured view of long-term Layer 1 upgrades through 2029. It defines measurable targets: faster slots, shorter finality, higher throughput, post-quantum cryptography, and base-layer privacy. The roadmap organizes these upgrades across the consensus, data, and execution layers, with a defined fork cadence and technical dependencies.
The document does not predict outcomes but provides a technical framework for discussion and coordination. Its proposals depend on research results, governance consensus, and implementation capacity. Overall, the roadmap’s impact will depend on how the Ethereum community evaluates and adopts its components over the coming years.
Sources
- Justin Drake: Strawmap overview
- Vitalik Buterin: Public response to Strawmap
- strawmap.org: Roadmap documentation
- TheBlock: Ethereum Foundation researchers publish 'strawmap' outlining seven forks through 2029
bsc.news