The phrase "Ethereum roadmap" suggests something it isn't. A roadmap, in the corporate sense, is a schedule: features, dates, owners, a product manager somewhere keeping score. Ethereum has none of that. What it has is a research agenda — a set of parallel workstreams, published as a diagram that Vitalik Buterin updates roughly once a year, describing where protocol research is pointed. No dates. No binding commitments. No authority that could enforce either.
This gap between the word and the thing causes real confusion. People read the roadmap as a promise, then treat every delay as a failure. It's more accurate to read it as a map of intentions — useful for understanding what Ethereum is trying to become, nearly useless for predicting when. Understanding how items actually move from that diagram to running code is the part worth knowing, because that's where you can check the roadmap against reality.
The Organizing Decision: Rollup-Centric Scaling
Everything on the current roadmap descends from one decision, made publicly in October 2020: Ethereum stopped trying to scale execution on the base layer. Instead of making L1 process more transactions, the plan became to let rollups handle execution and turn L1 into the security and data layer underneath them. The base chain's job shifted from "run everyone's transactions" to "make rollup data cheap to publish and easy to verify."
That's the premise. Every major item since — blob transactions, data availability sampling, statelessness — is a consequence of it. If you're evaluating whether the roadmap is on track, you're really evaluating whether that premise is holding: are rollups actually absorbing the activity, and is L1 actually getting better at serving them? Why Ethereum couldn't just scale L1 directly is its own post.
How the Roadmap Is Structured
The diagram organizes work into six named tracks, each with a rhyming name that started as a joke and stuck: the Merge, the Surge, the Scourge, the Verge, the Purge, and the Splurge. The next post in this series walks through each one properly; the short version is that they cover consensus (Merge — the proof-of-stake transition shipped in 2022, with finality improvements still ongoing), scaling via data availability (Surge — EIP-4844 live, full Danksharding later), MEV and censorship resistance (Scourge), stateless verification (Verge — the Verkle tree work), pruning old data and dead protocol weight (Purge), and a catch-all for everything else, including account abstraction (Splurge).
The detail people miss: these tracks run in parallel, not in sequence. The names look like phases, and commentary regularly presents them that way — "Ethereum is now in the Surge era." That's wrong. Work on all six proceeds simultaneously, at different speeds, by different research teams. The Merge shipped while Surge research was already years deep. Pieces of the Splurge went live before most of the Verge existed as code.
How Anything Actually Ships
The roadmap has no delivery mechanism of its own. Changes reach mainnet through exactly one channel: the EIP process, bundled into named hard forks that all client teams implement together. Paris delivered the Merge in September 2022. Dencun delivered blob transactions in March 2024. Pectra, in May 2025, delivered EIP-7702's account abstraction piece alongside staking changes — items from two different tracks in one fork.
That's the actual rhythm of the roadmap: a fork roughly every twelve to eighteen months, each carrying a handful of EIPs drawn from whichever tracks happen to have production-ready work. The diagram describes direction; the fork process describes delivery. When people ask "when will X ship," the honest answer is: when its EIP is specified, implemented in every major client, tested, and scheduled into a fork — a pipeline that has never run on a predictable clock. Admittedly, "it ships when it ships" is unsatisfying. It's also the truth, and the roadmap's authors have mostly stopped pretending otherwise.
Worth stating plainly: Vitalik's diagram is influential, not authoritative. Client teams and the AllCoreDevs process decide what gets scheduled. There's no vote, no foundation decree — the diagram persists because the people doing the work keep finding it a useful shared reference, which is a softer kind of authority than most people assume.
Where the Constraints Live
The binding constraint is coordination, not invention. Most roadmap items exist as research or prototypes years before they ship; what takes time is getting five-plus independent client teams to implement the same spec, test it against each other, and agree it won't break a network settling real value. That's a soft constraint, but it dominates every timeline.
The second constraint is a self-imposed hard one: home validators must stay viable. Blob counts, state size, bandwidth requirements — all of them are capped by what consumer hardware on a residential connection can handle. Several roadmap items (data availability sampling in particular) exist specifically to relax this constraint without abandoning it.
The third is research uncertainty. Roadmap items get replaced while still on the roadmap. The Verge is the live example: Verkle trees were the announced path to statelessness for years, and there's now serious discussion of leapfrogging them entirely in favor of hash-based structures friendlier to zero-knowledge proofs. The diagram gets redrawn around results like that.
What's Changing
As of mid-2026, the nearest large item is PeerDAS — the data availability sampling step that would let blob counts rise past the current 6-blob ceiling. It's in active development with no confirmed mainnet date. Beyond that, the visible motion is mostly reprioritization: gas limit increases returning modest L1 scaling to the agenda after years of rollup-only orthodoxy, the Verkle-versus-hash-trees question in the Verge, and longer-horizon proposals to redesign the consensus layer wholesale. None of these changes the destination much. They change the route, which is what the roadmap actually specifies.
What Would Confirm This Direction
PeerDAS reaching mainnet and blob capacity rising without degrading home validators. Fork cadence holding at one every twelve to eighteen months with items drawn from the published tracks. Rollups continuing to absorb the majority of user activity — the premise the whole structure rests on.
What Would Invalidate or Change It
The deepest invalidation would be the rollup-centric premise failing: activity migrating to integrated L1 competitors faster than Ethereum's data layer improves, making the Surge's destination irrelevant. Short of that — a multi-year stall in fork delivery, or a client-team split over roadmap direction that produces a contentious fork, would each break the "influential but not authoritative" equilibrium described above. Track-level replacements (Verkle trees swapped out, say) are not invalidation; that's the process working as designed.
Timing Perspective
Now: Pectra is live. The checkable facts are which EIPs shipped in which fork, and whether they map to the published tracks — they do.
Next: The PeerDAS fork, whenever it's scheduled. Watch fork agendas, not the diagram.
Later: Full Danksharding, statelessness, single-slot finality. Direction agreed, timelines genuinely unknown — multi-year at minimum.
Boundary Statement
This post explains what the roadmap is and how it functions as a coordination artifact. It doesn't walk through the six tracks in detail — that's the next post — and it isn't an argument that roadmap progress translates to ETH value; infrastructure improving and an asset appreciating are separate claims, and only the first is covered here.
