Ethereum’s “Strawmap”: A Radical Long-Term Vision for the World’s Most Important Smart Contract Network

Believe in something. Believe in an Ethereum strawmap.

That is the provocative invitation behind a new document released by the EF Protocol cluster within the Ethereum Foundation. Titled “Introducing strawmap, a strawman roadmap,” the proposal is neither an official decree nor a short-term release plan. Instead, it is a long-range coordination blueprint designed to stretch Ethereum Layer 1 development through the end of the decade.

Available at strawmap[.]org, the document is unapologetically dense. It is written for researchers, core developers, and governance participants already steeped in protocol discussions. For readers looking for introductory material, the canonical Ethereum roadmap at ethereum[.]org/roadmap remains the starting point. But for those with a middle-to-advanced IT background who want to understand where Ethereum could realistically be heading, the strawmap is a rare glimpse into the protocol’s deep future.

What the Strawmap Actually Is

At its core, the strawmap is an attempt to zoom out.

Ethereum upgrades are typically discussed fork by fork. The All Core Devs process and tracking tools like forkcast[.]org focus on the next upgrade or, at most, the next couple. That near-term orientation is practical, but it can obscure the broader architectural direction.

The strawmap places multiple years of Layer 1 upgrades onto a single visual timeline. It stretches through 2029 and sketches seven forks, assuming a cadence of roughly one major fork every six months. Rather than predicting what will happen, it lays out one coherent path among many possible futures.

The name “strawmap” reflects this humility. It is a portmanteau of “strawman” and “roadmap.” The “strawman” qualifier serves two purposes. First, Ethereum is radically decentralized; there can be no single official roadmap that represents every stakeholder. Second, the document is explicitly a work-in-progress. It emerged from an EF workshop in January 2026 as a discussion starter and is now shared publicly to accelerate alignment and debate.

In other words, it is not destiny. It is a coordination tool.

The Five North Stars

On the far right of the strawmap visual sit five black boxes labeled as “north stars.” These are the long-term ambitions Ethereum’s Layer 1 is steering toward.

The first is fast L1. The goal is near-instant user experience through shorter block slots and finality in seconds. For users, this means confirmations that feel closer to real-time systems rather than minute-scale blockchain waits. Achieving this requires deep changes in consensus timing and validator coordination.

The second is gigagas L1, defined as one gigagas per second, roughly translating to 10,000 transactions per second on Layer 1. The path to that performance level relies heavily on zkEVMs and real-time proving. In practical terms, Ethereum would use zero-knowledge cryptography to verify large bundles of computation efficiently, compressing execution into succinct mathematical proofs.

The third is teragas L2, targeting one gigabyte per second of data throughput, or about 10 million transactions per second on Layer 2 networks. This is made possible through data availability sampling, a technique that allows validators to verify that transaction data is available without downloading all of it. The implication is that rollups and Layer 2 systems can scale massively while anchoring security to Ethereum.

The fourth north star is post-quantum L1. This addresses a looming threat: quantum computers that could break today’s cryptographic signatures. The strawmap envisions transitioning to durable cryptography, potentially hash-based signature schemes, to ensure Ethereum remains secure in a post-quantum world.

The fifth is private L1, enabling first-class privacy with shielded ETH transfers. Unlike optional mixing tools, this would embed privacy as a native capability of Ethereum’s base layer.

Together, these five goals outline an Ethereum that is faster, massively scalable, quantum-resilient, and privacy-aware.

The Timeline: Forks Through 2029

The strawmap organizes progress as a horizontal timeline of forks, moving from left to right, with seven forks planned through the end of the decade. The cadence assumes roughly one fork every six months.

Consensus layer forks follow a star-based naming scheme with incrementing first letters, continuing the tradition of names like Altair, Bellatrix, Capella, and Deneb. Upcoming finalized names include Glamsterdam and Hegotá, while future forks such as I* and J* use placeholders. I* is pronounced “I star.”

Each fork contains a mix of consensus layer (CL), execution layer (EL), and data layer (DL) upgrades. The visual groups them in color-coded horizontal bands, making dependencies explicit. Arrows between boxes indicate hard technical dependencies or natural upgrade sequences.

Importantly, the timeline should not be mistaken for a rigid schedule. It assumes “human-first” development. The authors acknowledge that AI-assisted development and formal verification could compress timelines dramatically. Conversely, technical complexity or governance friction could delay them.

The document encourages healthy skepticism about dates while still committing to a directional plan.

Headliners and the Modern Fork Discipline

Ethereum’s upgrade process has matured significantly. To maintain a rapid fork cadence, the All Core Devs process typically limits each fork to one major consensus headliner and one major execution headliner.

Headliners are the most ambitious, high-impact changes in a given fork. In the Glamsterdam fork, for example, the consensus headliner is ePBS, or enshrined Proposer-Builder Separation, while the execution headliner is BALs.

This discipline is designed to prevent forks from becoming overloaded and slipping indefinitely. The strawmap preserves that philosophy while showing how successive headliners build toward the north stars.

An exceptional case appears in the L* fork, which features two headliners tied to a larger “lean consensus” transition. That alignment is described almost as a fateful coincidence within the draft.

For readers with IT backgrounds, the takeaway is that Ethereum is trying to balance ambition with operational realism. It is not simply stacking features; it is sequencing them under constraints.

The Technological Pieces That Must Land

To reach its north stars, several technological pillars must be delivered.

Shorter slots and faster finality require optimizing validator communication and reducing latency in the consensus mechanism. This likely involves reworking how attestations propagate and how blocks are confirmed, without sacrificing decentralization.

Gigagas L1 hinges on zkEVM integration and real-time proving. Zero-knowledge virtual machines allow Ethereum transactions to be executed off-chain and proven on-chain with succinct proofs. Real-time proving remains a significant engineering challenge, as generating cryptographic proofs fast enough for live systems demands specialized hardware and optimized circuits.

Teragas L2 depends on robust data availability sampling. This technique allows nodes to probabilistically verify that full transaction data exists somewhere in the network. It underpins rollup scalability, ensuring that Layer 2 systems can process millions of transactions per second without overloading Layer 1 validators.

Post-quantum security will require replacing or augmenting existing signature schemes like ECDSA and BLS with quantum-resistant alternatives. Hash-based signatures are one candidate, but they introduce trade-offs in key size and performance.

Private L1 functionality demands cryptographic primitives such as zero-knowledge proofs and shielded transaction pools, integrated natively into the protocol rather than bolted on as external tools.

Each of these is a non-trivial R&D domain in its own right. The strawmap brings them together into a single architectural narrative.

Why This Matters Now

Ethereum is no longer an experimental network. It secures hundreds of billions of dollars in digital assets and underpins large segments of decentralized finance and tokenized infrastructure. Its scaling debate has shifted from “if” to “how fast and how coherently.”

The strawmap’s real contribution is not in promising specific features. It reframes Ethereum’s evolution as a multi-year, layered engineering project with explicit dependencies and trade-offs.

It also signals proactive transparency from the EF Protocol cluster. By publishing an internal discussion artifact, the authors invite scrutiny and iteration. The document will evolve quarterly, with revision dates clearly noted. Feedback is actively encouraged, with named maintainers reachable via open channels.

A Coordination Tool, Not a Crystal Ball

Perhaps the most important thing to understand is what the strawmap is not.

It is not a prediction. It is not a binding commitment. It is not an official proclamation from all Ethereum stakeholders. In a decentralized ecosystem, such unanimity is impossible.

Instead, the strawmap is an accelerationist coordination tool. It sketches one reasonably coherent path among millions of potential outcomes. By doing so, it helps researchers, client teams, rollup developers, and governance participants align around shared long-term objectives.

For readers with a middle IT background, the message is clear. Ethereum is aiming for:

• Near-instant confirmations on Layer 1
• Order-of-magnitude throughput increases on both L1 and L2
• Built-in quantum resilience
• Native privacy capabilities

All within a structured fork cadence extending through 2029.

Whether every element lands exactly as drawn is secondary. The more significant development is that Ethereum’s core contributors are thinking in systems, not patches.

Believe in something. Believe in an Ethereum strawmap.