The rhyming names are the most quoted and least understood part of Ethereum's roadmap. People recite them like eras — first the Merge, then the Surge, and so on down the list — which gets the structure exactly backwards. They're not phases. They're six parallel workstreams, each owned by different researchers, each moving at its own speed, all shipping through the same hard-fork pipeline whenever a given piece happens to be ready.
Notice, too, that the popular phrase has a gap. Say it out loud — Merge, Surge, Verge, Purge, Splurge — and you've skipped one. There are six tracks, and the missing one, the Scourge, arguably deals with the hardest problem on the list. That omission tells you something about how casually these names get repeated versus how rarely anyone looks at what's inside them.
The previous post covered what the roadmap is — a research agenda, not a schedule. This one walks through the tracks themselves: what each is for, what's shipped, and what's still theoretical.
The Merge is the only track most people can name a shipping date for: September 2022, the Paris fork, when Ethereum swapped proof of work for proof of stake without stopping the chain. Because that event was so visible, the track reads as finished. It isn't.
The Merge track covers the consensus layer generally, and its remaining agenda is substantial. The headline item is single-slot finality — today, finality takes about fifteen minutes (two epochs); the goal is to finalize each block in its own twelve-second slot. There's also work on lowering the 32 ETH validator minimum and, on the long horizon, making signatures quantum-resistant. None of this has a date. All of it lives under the name people think retired in 2022.
The Surge is where most of the visible action has been. Its premise comes from the rollup-centric pivot: L1 doesn't scale execution, rollups do, and L1's job is to make publishing rollup data cheap. The often-cited target is 100,000 transactions per second across the rollup ecosystem — a number worth treating as a direction, not a promise.
The sequence here is unusually legible because part of it already shipped. EIP-4844 went live in March 2024 and gave rollups blob space, cutting their costs by an order of magnitude or more. The next step is PeerDAS — data availability sampling over the existing peer-to-peer network, which would let blob counts rise past the current ceiling without forcing every node to download everything. It's in active development, no confirmed mainnet date. The end state is full Danksharding: two-dimensional sampling, an order of magnitude more blobs, multi-year horizon.
The forgotten track. The Scourge addresses MEV — the value extractable by whoever orders transactions — and the centralization pressure it creates. This is less glamorous than scaling and harder to declare victory on, which is probably why it fell out of the rhyme.
The problem, compressed: MEV rewards specialization. Today most blocks are assembled by a handful of professional builders and routed to validators through an out-of-protocol marketplace (mev-boost). That works, but it means block construction is already concentrated, and concentrated builders can censor transactions. The Scourge's response is to enshrine the separation — proposer-builder separation at the protocol level (ePBS) — and to give validators inclusion lists: a mechanism forcing transactions into blocks even when the builder would rather omit them. Both are in the research-to-specification stage. If you want a single track to watch as a measure of whether Ethereum takes its own neutrality seriously, honestly, it's this one.
The Verge aims at statelessness: letting a node verify Ethereum without storing the full state. Today, validating requires hundreds of gigabytes. The Verge's end state is verification on a phone — receive a block, receive a compact proof, check it, done.
For years the announced path was Verkle trees, a replacement for Ethereum's Merkle Patricia trie with much smaller proofs. That plan is now genuinely uncertain — there's serious discussion of skipping Verkle trees entirely in favor of hash-based structures friendlier to zero-knowledge proofs, since ZK proving improved faster than expected while Verkle work sat in the queue. A roadmap track replacing its own flagship approach mid-flight is a good reminder of what these tracks are: research agendas, not commitments.
The Purge is the housekeeping track, and it's more consequential than it sounds. Two kinds of deletion. History expiry (EIP-4444) lets nodes drop chain history older than roughly a year, shifting old data to external providers — this became live-adjacent when EIP-4844 established the precedent that data can be protocol-relevant without being stored forever. State expiry, the harder version, would archive untouched accounts and storage so state stops growing without bound. Alongside both, there's a running effort to remove dead weight: old transaction types, the SELFDESTRUCT opcode's messier behaviors, edge cases every client must implement but almost nothing uses.
The Purge rarely headlines a fork. It shows up as one or two EIPs at a time, quietly making every other track's job easier.
The Splurge is the explicit catch-all — "fix everything else," in the roadmap's own framing. Its biggest resident is account abstraction: ERC-4337 running as infrastructure since 2023, and EIP-7702 shipping in Pectra (May 2025) to let ordinary wallets behave like smart contracts. Also in here: EIP-1559 retroactively (it predates the diagram), deeper fee-market research, and cryptographic upgrades like verifiable delay functions for better randomness.
A catch-all track sounds unserious until you notice the Splurge has shipped more user-visible change than the Verge, Purge, and Scourge combined. Parallel tracks, different speeds.
All six tracks share one delivery pipeline: the EIP process, bundled into hard forks every twelve to eighteen months, implemented by five-plus independent client teams. That's the binding constraint — a fork can only carry a handful of items, so tracks compete for slots. The second constraint is the standing rule that home validators stay viable on consumer hardware; it caps blob counts (Surge), motivates statelessness (Verge), and forces state growth onto the agenda (Purge). The tracks aren't independent problems. They're one problem — keep the chain verifiable by individuals while scaling it — cut six ways.
As of mid-2026: PeerDAS is the nearest large item, in active development without a confirmed date. The Verge's Verkle-versus-hash-trees question is genuinely open. Scourge items — ePBS and inclusion lists — are moving through specification, which is further than MEV work has ever gotten before. And there are longer-horizon proposals to redesign the consensus layer wholesale, which would fold several Merge-track goals (single-slot finality, smaller validators, quantum resistance) into one program.
Forks continuing to draw items from multiple tracks at once. PeerDAS reaching mainnet without degrading home validators. An inclusion-list or ePBS EIP getting scheduled into a fork — the Scourge producing shipped code would be the strongest signal, because it's the track that's never shipped any.
A track being abandoned without a successor — not swapped for a better approach, but dropped — would signal the agenda shrinking to match delivery capacity. The deeper invalidation is inherited from the rollup-centric premise: if activity migrates to integrated L1 competitors faster than the Surge improves the data layer, the track structure survives but stops mattering. Renames, mergers, and replaced approaches (Verkle trees, possibly) are not invalidation. The diagram gets redrawn annually; that's the format working.
Now: The Merge's headline event shipped; EIP-4844 is live; EIP-7702 is live. The checkable fact is which track each shipped EIP belongs to.
Next: PeerDAS, and the Scourge's move from research to specification. Watch fork agendas.
Later: Full Danksharding, statelessness, single-slot finality, quantum resistance. Direction stated, timelines unknown.
This post maps the six tracks and their status. It doesn't argue that any track's completion implies anything about ETH as an asset, and it doesn't predict fork dates — the pipeline that ships this work has never run on a clock. The static explanation lives here; tracking which items actually move is ongoing work, and it lives elsewhere.




