What Is the Merge, Surge, Verge, Purge, Splurge?

Ethereum's rhyming roadmap names get recited as eras. They're six parallel workstreams — including one the popular phrase skips entirely. What each track is for, what's shipped, and what's still theoretical.
Lewis Jackson
CEO and Founder

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 — Consensus

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 — Scaling Through Data

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 Scourge — MEV and Censorship

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 — Verifying Without State

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 — Deleting Protocol Debt

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 — Everything Else

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.

Where the Constraints Live

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.

What's Changing

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.

What Would Confirm This Direction

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.

What Would Invalidate or Change It

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.

Timing Perspective

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.

Boundary Statement

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.

Related Posts

See All
Crypto Research
New XRP-Focused Research Defining the “Velocity Threshold” for Global Settlement and Liquidity
A lot of people looking at my recent research have asked the same question: “Surely Ripple already understands all of this. So what does that mean for XRP?” That question is completely valid — and it turns out it’s the right question to ask. This research breaks down why XRP is unlikely to be the internal settlement asset of CBDC shared ledgers or unified bank platforms, and why that doesn’t mean XRP is irrelevant. Instead, it explains where XRP realistically fits in the system banks are actually building: at the seams, where different rulebooks, platforms, and networks still need to connect. Using liquidity math, system design, and real-world settlement mechanics, this piece explains: why most value settles inside venues, not through bridges why XRP’s role is narrower but more precise than most narratives suggest how velocity (refresh interval) determines whether XRP creates scarcity or just throughput and why Ripple’s strategy makes more sense once you stop assuming XRP must be “the core of everything” This isn’t a bullish or bearish take — it’s a structural one. If you want to understand XRP beyond hype and price targets, this is the question you need to grapple with.
Read Now
Crypto Research
The Jackson Liquidity Framework - Announcement
Lewis Jackson Ventures announces the release of the Jackson Liquidity Framework — the first quantitative, regulator-aligned model for liquidity sizing in AMM-based settlement systems, CBDC corridors, and tokenised financial infrastructures. Developed using advanced stochastic simulations and grounded in Basel III and PFMI principles, the framework provides a missing methodology for determining how much liquidity prefunded AMM pools actually require under real-world flow conditions.
Read Now
Crypto Research
Banks, Stablecoins, and Tokenized Assets
In Episode 011 of The Macro, crypto analyst Lewis Jackson unpacks a pivotal week in global finance — one marked by record growth in tokenized assets, expanding stablecoin adoption across emerging markets, and major institutions deepening their blockchain commitments. This research brief summarises Jackson’s key findings, from tokenized deposits to institutional RWA chains and AI-driven compliance, and explains how these developments signal a maturing, multi-rail settlement architecture spanning Ethereum, XRPL, stablecoin networks, and new interoperability layers.Taken together, this episode marks a structural shift toward programmable finance, instant settlement, and tokenized real-world assets at global scale.
Read Now

Related Posts

See All
No items found.
Lewsletter

Weekly notes on what I’m seeing

A personal letter I send straight to your inbox —reflections on crypto, wealth, time and life.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.