Chapter 01

What changed in the September update

Ethereum's latest protocol priorities update presents a network moving through two time horizons at once. Glamsterdam is approaching mainnet while the following upgrade, Hegotá, is being scoped. At the same time, protocol teams are treating post-quantum security, formal verification and a more durable base layer as active engineering tracks rather than distant research topics.

The important story is not a single feature. It is the way the roadmap connects capacity, usability and resilience. Earlier in 2026, the Ethereum Foundation grouped its work under three broad goals: scaling the network, improving user experience and hardening the base layer. The September update keeps that structure but gives a clearer picture of the work moving from research toward delivery.

Chapter 02

Glamsterdam and the upgrade pipeline

Ethereum upgrades are bundles of separately reviewed proposals, client implementations, tests and coordination work. A name such as Glamsterdam is therefore a container for a long public process, not a product launch controlled by one company. Before mainnet activation, changes move through specification, implementation, dedicated test networks and broader testing.

That process matters to users even when they never run a validator. Changes to execution, data availability or account behavior can affect wallets, exchanges, rollups and developer tools. Operators need time to update clients. Application teams need to test assumptions. Researchers need enough visibility to challenge the design before the network depends on it.

Hegotá being scoped before Glamsterdam arrives also shows how the pipeline overlaps. Future-upgrade research starts while nearer-term code is being stabilized. That overlap can make roadmap discussions look confusing, because an idea being studied for one fork may be deferred, revised or split across later forks. Readers should separate accepted specifications from proposals still under debate.

Chapter 03

Scaling is becoming more multidimensional

Ethereum's recent scaling strategy cannot be described by the base-layer gas limit alone. Rollups execute activity away from the base chain and publish data or proofs back to Ethereum. Blob capacity, data availability, proof systems, execution performance and node requirements all influence the result users experience.

More capacity is useful only if the system remains verifiable by a broad set of participants. Raising one limit can increase hardware, bandwidth or state-growth pressure elsewhere. This is why roadmap updates repeatedly discuss performance and sustainability together. The objective is not simply to process more activity for one week; it is to do so without quietly narrowing the group capable of checking the chain.

Chapter 04

Resilience is moving to the foreground

The September priorities place visible emphasis on post-quantum preparedness and formal verification. Quantum computers capable of threatening widely used cryptography are not a present consumer reality, but migrating a global protocol cannot be improvised after a breakthrough. Inventorying cryptographic dependencies, designing alternatives and planning safe transitions are forms of risk management.

Formal verification addresses a different class of risk. It uses mathematical techniques to test whether software or specifications satisfy defined properties. It cannot prove that every operational decision is correct, and it does not eliminate implementation bugs by magic. It can, however, make critical assumptions explicit and help teams reason more rigorously about high-value components.

For readers, these priorities are a reminder that network security is broader than a count of validators or the value staked. Client diversity, specification quality, test coverage, incident response and the ability to evolve cryptography all contribute to resilience.

Chapter 05

What users should watch next

The next useful signals are concrete ones: finalized upgrade scope, client releases, testnet results, activation dates and published post-mortems when testing reveals problems. Token-price reaction is not a substitute for any of them. Neither is a roadmap graphic without links to specifications and implementation status.

Wallet and application users should follow announcements from the software they actually use, especially around upgrade windows. Node operators should consult their client team's release instructions. Developers should test against the relevant networks instead of assuming backward compatibility.

Ethereum's 2026 roadmap is ambitious, but its most credible feature is procedural. Public specifications, multiple client teams and staged testing create opportunities to find mistakes before mainnet. The work is unfinished by design. The right way to follow it is to distinguish research, accepted scope, test deployment and live activation—and to update the story as evidence moves from one stage to the next.

Chapter 06

The Verge, The Purge, and The Splurge: technical milestones

Ethereum's ongoing technical roadmap focuses on achieving long-term sustainability through progressive protocol enhancements designed to reduce node hardware requirements and improve transaction throughput. Key phases include:

  • The Verge: Transitioning the state commitment scheme from traditional hexary Merkle Patricia trees to Verkle trees (and potentially binary state trees). This transition enables stateless clients, allowing verifying nodes to validate incoming blocks using compact cryptographic witness proofs without storing the entire multi-hundred-gigabyte Ethereum state on local NVMe solid-state drives.
  • The Purge: Implementing history expiry under standards such as EIP-4444. Under this framework, full execution nodes are relieved of the mandatory requirement to store and serve historical block and transaction data older than one calendar year over the peer-to-peer gossip protocol. Historical data archival is offloaded to decentralized storage networks, torrent protocols, and portal networks, drastically lowering the ongoing storage expansion burden for home node validators.
  • The Splurge: Addressing specialized optimizations including native Account Abstraction (ERC-4337 and related protocol upgrades), verifiable delay functions, and post-quantum cryptographic resilience across cryptographic signatures.

Chapter 07

Protocol governance: client diversity and core dev consensus processes

Ethereum's operational resilience depends heavily on the maintenance of broad client diversity across both execution and consensus layers. If any single software client achieves a supermajority exceeding 66.6% (two-thirds) of active network stake, a critical consensus bug in that client can finalize an invalid chain, triggering catastrophic inactivity leaks and slashing penalties for node operators running the affected software.

Major software clients securing Ethereum include: - Execution Clients: Geth, Nethermind, Besu, Erigon, and Reth. - Consensus Clients: Prysm, Lighthouse, Teku, Lodestar, and Grandine.

Protocol changes proceed through the formal Ethereum Improvement Proposal (EIP) lifecycle, managed through bi-weekly AllCoreDevs (ACD) consensus calls. Upgrades require multi-client implementation consensus, rigorous fuzzing across public testnets (such as Sepolia and Holesky), and unanimous readiness confirmations across independent core engineering teams before mainnet activation slots are scheduled. This consensus-driven governance model prioritizes software correctness and backward compatibility over rapid, centralized feature deployment.