Surge vs Verge vs Purge vs Splurge: Compared

You’re looking at Ethereum’s four-part scaling solution. Surge cuts your transaction fees through Layer 2 blobs (2025–2026). Verge shrinks proof sizes using Verkle trees, lightening node requirements (2026–2027). Purge lets the network forget old data, reducing hardware demands (2027–2028). Splurge ditches seed phrases for flexible account controls (2028+). Each phase builds on the last, progressively unlocking cheaper, faster, and more accessible Ethereum. Stick around to discover how each transformation reshapes your experience.

Brief Overview

• Surge increases L2 throughput via proto-danksharding and blob storage, reducing fees by 90% compared to Ethereum L1.
• Verge optimizes state storage by replacing Merkle trees with Verkle trees, reducing proof sizes from 3.6 KB to 128 bytes.
• Purge implements state expiry mechanisms allowing clients to discard older data while maintaining transaction history on-chain.
• Splurge enhances user experience through decoupled signature schemes, batching, fee delegation, and intent-based execution for better flexibility.
• Timeline dependencies: Surge stabilizes first (2025–2026), followed by Verge (2026–2027), Purge (2027–2028), then Splurge (2028+).

Surge vs. Verge vs. Purge vs. Splurge: What Each Phase Does

Vitalik Buterin’s roadmap for Ethereum doesn’t follow a linear upgrade cycle—it’s a parallel effort across four distinct phases, each targeting a different constraint on the network’s scalability, efficiency, and long-term viability. Surge prioritizes Layer 2 throughput via proto-danksharding and calldata optimization. Verge restructures state storage using Verkle trees, reducing validator hardware requirements and enabling statelessness. Purge implements state expiry, eliminating accumulated historical data that bloats the chain. Splurge addresses miscellaneous improvements—account abstraction refinements, MEV mitigation, and protocol polish. These phase interdependencies aren’t sequential; they’re concurrent development priorities that compound over time. Understanding this architecture reveals Ethereum’s engineering approach: you’re not waiting for one monolithic upgrade, but rather incremental, overlapping improvements that reshape the network’s foundational constraints. Additionally, the transition to Proof of Stake has marked a significant milestone in Ethereum’s evolution, enhancing security and energy efficiency.

Why Ethereum Split Its Roadmap Into Four Separate Phases

Splitting Ethereum’s roadmap into four parallel phases wasn’t arbitrary—it was a pragmatic response to a fundamental problem: you can’t solve every constraint at once without creating bottlenecks elsewhere. By separating Surge (scaling), Verge (state efficiency), Purge (cleanup), and Splurge (UX polish), Ethereum achieves roadmap clarity while managing phase interdependencies intelligently.

Surge addresses throughput first because scaling enables the entire ecosystem. Verge follows with storage optimization—essential once transaction volume increases. Purge then removes technical debt accumulated during growth. Splurge polishes account abstraction and developer experience last, after infrastructure stabilizes.

This modular approach lets teams work in parallel without waiting for upstream completion. You get incremental improvements while avoiding monolithic upgrades that risk introducing cascading failures. Each phase builds on prior work without requiring perfect synchronization, reducing execution risk significantly.

Surge: How Layer 2 Blobs Cut Transaction Fees

The Surge phase targets raw transaction throughput—and Layer 2 rollups are where that scaling actually happens. Proto-danksharding (EIP-4844), deployed in March 2024, introduced blob storage—a cheaper data layer separate from calldata. This distinction is critical: rollups post transaction data to blobs instead of mainnet storage, cutting fees by 90% or more.

You’re not sacrificing security—blobs expire after ~18 days, but sequencers archive data permanently. This design lets rollups achieve transaction efficiency without bloating Ethereum’s validator set requirements. Additionally, the use of Optimistic Rollups enables significant scalability improvements while maintaining security through a fraud-proof system.

Verge: Replacing Merkle Trees With Verkle Trees

As Ethereum’s state grows—now exceeding 30+ GB on full nodes—validators must store increasingly large Merkle trees to verify account balances and smart contract data. Verkle trees replace this architecture with a more efficient cryptographic structure, slashing proof sizes from kilobytes to hundreds of bytes.

The Merkle tree limitations become acute as node operators struggle with storage and sync times. Verkle tree advantages include dramatically reduced state access costs and faster block validation. You’ll see proof generation shrink by 90%, meaning lighter nodes can participate in consensus verification without maintaining massive data structures. This efficiency unlocks meaningful decentralization—smaller operators can run full nodes again. Furthermore, the transition to Proof of Stake in Ethereum 2.0 enhances overall network efficiency, paving the way for improved scalability. The Verge phase targets 2026–2027 deployment, fundamentally reshaping how Ethereum stores and proves state without sacrificing security or finality guarantees.

Purge: Solving State Bloat Through Expiry

Even after Verkle trees shrink proof sizes, Ethereum’s state—the complete record of all account balances, contract code, and storage slots—continues accumulating data that never gets deleted. The Purge phase tackles this directly through state expiry and data pruning mechanisms.

State management becomes critical as nodes store terabytes of historical data. Purge introduces automatic expiration for inactive accounts and storage slots, allowing clients to discard data older than a set period without breaking consensus.

You don’t lose transaction history—that remains on-chain. Instead, you prune dormant state, reducing full node hardware requirements significantly. This improves decentralization by lowering barriers to running infrastructure.

Data pruning lets operators reclaim disk space while maintaining security guarantees, making Ethereum more accessible to individual node runners and strengthening network resilience.

Splurge: Account Abstraction and Protocol Polish

Account abstraction doesn’t rebuild Ethereum’s transaction model—it unbundles it. You gain account flexibility by decoupling signature schemes from transaction validation logic. Instead of hardcoding ECDSA verification, you define custom authentication rules within smart contracts. This means you can use multi-sig wallets, social recovery, or biometric-tied accounts without protocol changes.

Splurge prioritizes user experience through batching, fee delegation, and intent-based execution. You submit what you want to accomplish; relayers handle gas payment and ordering. The Pectra upgrade (EIP-7702) introduced account code authorization, letting you temporarily grant smart contract capabilities to EOAs without permanent migration.

You’re no longer locked into Ethereum’s default account model. The protocol polish here means removing arbitrary constraints that existed only for simplicity, not security or function. This evolution in account management parallels the enhanced transaction throughput capacity seen in the Ethereum 20 upgrade, allowing for more efficient interactions within the network.

When Each Phase Ships: Timeline and Dependencies

Shipping timelines for Surge, Verge, Purge, and Splurge don’t operate in isolation—each phase depends on the previous one’s infrastructure maturity and real-world validation. You’re looking at a multi-year rollout where Layer 2 scaling (Surge) must stabilize before state optimization (Verge) can safely deploy. Purge’s state expiry won’t launch until Verkle trees prove reliable under production load. Additionally, the transition to Proof-of-Stake is expected to influence the network’s efficiency and scalability, impacting the deployment of future phases.

Development priorities shift as each phase matures, reshaping the Ethereum roadmap and technical implications for validators and applications.

Why Surge Doesn’t Require Verge (But Verge Needs Surge)

Surge and Verge occupy different layers of Ethereum’s scaling hierarchy, which is why you can deploy aggressive Layer 2 fee reduction without waiting for Verkle tree infrastructure.

Surge efficiency targets rollup throughput directly through proto-danksharding (EIP-4844) and subsequent blob enhancements. You’re compressing calldata costs, not restructuring state trees. That independence means Layer 2s like Arbitrum and Optimism capture immediate benefits.

Verge dependency runs the opposite direction. Verkle trees require Surge‘s scaling foundations to justify their complexity. You can’t efficiently prune state without first proving Layer 2s absorb transaction volume. The roadmap stacks intentionally:

• Surge deploys first: blob scalability, immediate Layer 2 gains
• Verge follows: Verkle implementation, stateless validator support
• Purge cleans up: expired state removal, pruned history

This sequencing protects validator hardware and reduces risk during rollout, ultimately enhancing network integrity as validators are incentivized to maintain a secure environment.

How Verkle Trees Compress Proofs and Lower Hardware Barriers

Once Surge absorbs most transaction load onto Layer 2s, Ethereum’s mainnet state won’t need to grow as aggressively—and that’s where Verkle trees enter. These cryptographic structures replace Merkle trees by dramatically compressing proof sizes from ~3.6 KB to ~128 bytes per account access. You’ll validate the same state transitions with far smaller data payloads, reducing bandwidth requirements for node operators significantly.

Verkle tree advantages include lower hardware barriers—running a full node becomes feasible on modest machines. Proof compression eliminates the bottleneck that currently forces operators toward centralized providers. By shrinking witness data, Verkle enables stateless clients that verify blocks without storing gigabytes of historical state, strengthening decentralization across Ethereum’s validator ecosystem and preparing the network for Verge’s state expiry phase.

State Expiry and Its Risks: What Purge Changes for Users

• Inactive accounts become recoverable only via explicit reactivation transactions, introducing friction for legacy contracts or dormant wallets.
• Node operators reduce hardware demands by pruning expired state, lowering barriers to running full nodes.
• Smart contracts relying on historical state access face increased operational costs and complexity.

User experience changes are direct: you’ll encounter new gas costs when reawakening old accounts. Multi-signature wallets or governance contracts dormant for years require fresh transactions before functioning. These trade-offs reduce Ethereum’s storage bloat while creating new operational overhead you must anticipate and budget for. Furthermore, understanding key management practices becomes crucial for users reactivating old accounts to ensure their assets remain secure.

Account Abstraction in Splurge: The End of Seed Phrases

While Purge shrinks Ethereum’s storage footprint, Splurge tackles a more fundamental problem: the seed phrase itself has become a liability. Account abstraction decouples your identity from a single private key, replacing the vulnerability of twelve-word mnemonics with programmable wallet logic. You’ll authenticate through multiple factors—biometrics, hardware keys, social recovery—rather than memorizing or storing a phrase hackers target relentlessly. Splurge implements EIP-7702 smart account capabilities natively, letting you deploy custom authorization rules without sacrificing security. Your wallet becomes intelligent: it can enforce spending limits, require multi-signature approval, or rotate credentials without resetting everything. This shift moves custody from “don’t lose the seed” to “design your own security model,” fundamentally changing how you interact with blockchain assets. Furthermore, this innovation in wallet management aligns with Ethereum’s robust security measures, ensuring that your assets remain safeguarded against threats.

What the Four Phases Mean for Stakers, Developers, and Users

Each phase of Ethereum’s roadmap—Surge, Verge, Purge, and Splurge—reshapes what you can do with the network and how you participate in it.

Surge implications lower your Layer 2 transaction costs dramatically through blob storage and proto-danksharding. Verge benefits arrive as Verkle trees compress state data, letting you run a full node on consumer hardware without multi-terabyte storage. Purge challenges require careful transition planning—state expiry will prune historical data, reducing bloat but demanding protocol updates to indexing and archival services. Splurge enhancements give you account abstraction and smart wallet capabilities, eliminating seed phrase dependency.

• Stakers gain simplified validator management through higher stake caps.
• Developers access lean infrastructure and efficient state proofs.
• Users enjoy cheaper transactions and safer account recovery. Additionally, the layered architecture promotes enhanced scalability, ensuring that all participants benefit from a more efficient network.

Frequently Asked Questions

Will Ethereum Require a Hard Fork for Each of the Four Phases?

You’ll see hard forks during phase transitions, though not necessarily for every milestone. Surge and Verge will likely need coordinated network upgrades, while Purge and Splurge may bundle changes. Each hard fork requires validator consensus—your node updates matter for network security.

How Do Verkle Trees Reduce Validator Hardware Requirements Compared to Merkle Trees?

You’ll reduce your validator hardware requirements significantly because Verkle trees compress state proofs from 32 bytes to just 31 bytes per proof, enabling validator efficiency through hardware optimization. You’ll run nodes on standard equipment without sacrificing security.

Can Users Opt Out of State Expiry, or Is It Mandatory Network-Wide?

You can’t opt out—state expiry’s mandatory network-wide once deployed. Over 34 million ETH staked means validators collectively enforce it. Your node must comply with the protocol’s state expiry options; user consent isn’t negotiable, but you’re safeguarded by transparent consensus rules.

Does Account Abstraction in Splurge Eliminate the Need for Hardware Wallets?

No. Account abstraction won’t eliminate hardware wallets—they’ll remain your strongest account security option. Splurge improves wallet convenience and user experience, but you shouldn’t abandon hardware-backed transaction safety for softer custodial methods.

Which Phase Will Have the Largest Immediate Impact on Transaction Costs and Speed?

The Surge hits your wallet like a pressure relief valve—it’s tackling transaction efficiency head-on. You’ll see immediate cost implications and speed optimization through proto-danksharding blobs and Layer 2 rollups, making it the phase with the largest immediate effects on transaction costs and speed.

Summarizing

You’re watching Ethereum transform from a monolith into a living organism. Surge builds the circulatory system for scalability, Verge strengthens its skeleton with Verkle trees, Purge sheds the weight of accumulated history, and Splurge polishes every remaining edge. Together, they don’t just improve Ethereum—they evolve it. You’re witnessing metamorphosis, not mere upgrades. Each phase feeds the next, creating something fundamentally more efficient and resilient than before.