TL;DR
- The Ethereum Foundation published a technical roadmap targeting ten million transactions per second.
- Seven protocol upgrades are projected through 2029 at one fork every six months.
- Quantum-resistant cryptography and native privacy transfers appear as long-term protocol objectives.
Building a roadmap for a decentralized protocol exposes a contradiction that few technology projects ever have to confront directly. Any document claiming to represent the consensus of thousands of independent participants carries an implicit lie in its title. The Ethereum Foundation chose to resolve that contradiction through precise naming.
The document published at strawmap.org doesn’t claim official status — it announces itself as a strawmap, a portmanteau of “strawman” and “roadmap” that signals from the first word that debate is the point, not compliance.
The document traces its origins to an internal workshop the Foundation held in January 2026, where researchers and developers worked to visualize how separate protocol improvement proposals connect and depend on each other across multi-year timelines.
A tool built for internal discussion became a public document through a deliberate choice the Foundation describes as proactive transparency. The team published it knowing that some projections will prove wrong, that feedback will reshape the contents, and that the map will look different a year from now than it does today. Publishing an imperfect document early serves coordination better than waiting for a perfect one that never arrives.
The strawmap lays out seven protocol upgrades projected through the end of the decade, built around a rough cadence of one fork every six months. Three color-coded horizontal layers — consensus, data, and execution — organize the proposals visually, with arrows marking hard technical dependencies between upgrades.
The naming scheme for upcoming forks follows an alphabetical progression: Glamsterdam and Hegotá carry confirmed names, while later forks use placeholder labels like I* and J*, pronounced literally as “I star” and “J star.” Each fork limits itself to one headline upgrade per layer to preserve the pace of the release schedule — a constraint the modern All Core Devs process enforces deliberately.
Five Targets That Define Where Ethereum Is Headed
The first north star addresses transaction confirmation speed at the base layer. Shorter slot times and finality measured in seconds rather than minutes would change the operational experience of the protocol at a fundamental level. Users who currently treat a transaction as irreversible only after several minutes of waiting would interact with a protocol that settles in a timeframe closer to a card payment than a wire transfer.
The second north star targets one gigagas per second of processing capacity on the main chain — roughly equivalent to 10,000 transactions per second. Reaching that number requires integrating zero-knowledge Ethereum virtual machines alongside real-time proof generation systems.
Of all five objectives, this one carries the heaviest dependency on research still actively in progress. The cryptographic infrastructure needed to verify computation at that speed at low cost doesn’t fully exist yet, which makes this target the most technically ambitious item on the map.
The third north star scales the capacity target toward the secondary layers built on top of Ethereum, aiming for one teragas per second — ten million transactions per second. The mechanism proposed to reach that level involves data availability sampling, a technique that lets network participants verify that information exists and remains accessible without downloading it entirely.
At that capacity, Ethereum’s extended network would support application-level throughput comparable to major global payment processors, without the centralized infrastructure those processors require.
The fourth north star addresses the long-term durability of the crypto foundations underpinning private keys and digital signatures. Sufficiently powerful quantum computers would break the mathematical problems that current Ethereum security relies on, potentially exposing wallets and invalidating signature schemes across the network.
Migrating toward hash-based crypto schemes — which resist quantum attacks through a different mathematical structure — requires deep changes to how the protocol handles identity and transaction authorization at every layer.
The fifth north star treats privacy as a native property of the base protocol rather than an optional feature available only through specialized applications. Shielded ETH transfers built directly into the protocol would allow users to transact without broadcasting every detail of their financial activity to anyone running a block explorer. In the current design, privacy requires deliberate effort and specialized tooling. Under the fifth north star, it becomes a default.
The document acknowledges its own boundaries with unusual directness. Within the roughly 100-person EF Protocol cluster that produced the strawmap, competing views on timelines, priorities, and sequencing already exist.
Beyond that group, the research community, independent client teams, and application developers hold a still broader range of positions. The strawmap doesn’t resolve those tensions — it maps the terrain with enough resolution to make future conversations more productive than they would be without a shared visual reference point.
One variable the Ethereum Foundation included in its planning that rarely appears in serious technical roadmaps deserves attention: the potential impact of AI-assisted development and automated formal verification on projected timelines. The current draft assumes human-first development processes. If the tools that accelerate code generation, formal verification, and security auditing mature at the pace some researchers expect, the seven-fork schedule through 2029 could compress in ways that no conventional planning process can quantify today. The Foundation flagged that possibility without pretending to know what it means in practice.
The four-person Architecture team maintaining the document — Ansgar Dietrichs, Barnabé Monnot, Francesco D’Amato, and Justin Drake — opened direct channels for public feedback and committed to quarterly updates, with each revision date recorded on the document itself. Treating a planning document as a living instrument updated on a fixed cadence separates it from the typical roadmap that gets published once and quietly ignored as reality diverges from its projections.
In an industry where roadmaps frequently serve marketing purposes while bearing little relationship to actual development priorities, the strawmap makes the opposite bet: technical density over accessibility, explicit acknowledgment of uncertainty over false confidence, and an open invitation for anyone with well-formed arguments to push back against what the document proposes.
The most valuable output of that approach won’t be the map itself. It will be the quality of the disagreements the map generates among the people building Ethereum from dozens of different directions at once.
