Ethereum’s Glamsterdam Upgrade

Ethereum’s next major planned upgrade, Glamsterdam, is shaping up to be one of the most important protocol changes on the 2026 roadmap. While recent upgrades were easier to explain through blobs, rollups, or immediate user cost changes, Glamsterdam is more infrastructural. It changes how Ethereum prepares, builds, and validates blocks.

The official ethereum.org roadmap page frames Glamsterdam around Layer 1 scaling, parallelization, capacity expansion, and sustainability. That is the cleanest summary of why it matters: Ethereum wants to handle more activity on the base layer without turning node operation into an arms race. [Ethereum.org roadmap]

One quick decoding note before we go deeper: EIP means Ethereum Improvement Proposal. It is just Ethereum’s name for a formal upgrade proposal. So when you see a number like EIP-7981, that does not mean users are expected to memorize it. It just means “one specific change being considered inside the broader upgrade.”

At the same time, the current scope is still evolving. The meta EIP for the upgrade, EIP-7773, is in Draft status as of June 17, 2026. That means Glamsterdam is very real, but anyone speaking about it as if every feature and every activation detail is already final is getting ahead of the process. [EIP-7773]

The official roadmap page adds a useful operational angle: ePBS is intended to expand the tight propagation and validation window from roughly 2 seconds to about 9 seconds. That gives Ethereum more room to safely handle larger and more complex blocks if the rest of the stack can keep up. [Ethereum.org roadmap]

The payoff, if it works, is straightforward: more efficient block production, better room for higher throughput, and less reliance on external builder infrastructure. The cost is complexity. And Ethereum is being unusually explicit that this complexity is real.

These bars are illustrative, not measured performance numbers. They simply show the three workstreams BALs are meant to unlock based on the EIP’s stated design goals.

As of June 17, 2026, EIP-7773 lists ten proposals as Scheduled for Inclusion: EIP-7708, EIP-7732, EIP-7778, EIP-7843, EIP-7928, EIP-7954, EIP-7976, EIP-7981, EIP-8024, and EIP-8037. That is already a useful fact-check, because some older summaries omit EIP-7708 from the scheduled set. [EIP-7773]

But that raw list is not the best way to understand the upgrade. In practice, you can group the current scheduled items into three buckets: big architecture changes like ePBS and BALs, developer or EVM quality-of-life changes like new opcodes and contract-size adjustments, and gas repricing items that change how certain actions are charged. That framing is much more useful than memorizing proposal numbers.

This distinction matters. It means some of the most exciting narratives around Glamsterdam are directionally fair but too confident in their details. The cleaner way to say it is that the upgrade has a very visible center of gravity, but the outer rings of scope are still being refined in public.

And to your earlier example: EIP-7981 is not a “headline feature” a normal user needs to study. It is one of the gas repricing changes inside the broader package. That is exactly why grouping these items by purpose is more useful than listing naked proposal numbers.

Ethereum.org explicitly says Glamsterdam will likely help lower fees for everyday users over time, partly because the roadmap pairs ePBS and BALs with future capacity growth and partly because it discusses intrinsic gas reduction through EIP-2780. [Ethereum.org roadmap]

But here is the important scope check: EIP-2780 is currently Considered for Inclusion, not Scheduled for Inclusion, in EIP-7773. So the safest interpretation is not “Glamsterdam definitely flips a cheaper-fee switch on day one.” The safer reading is that Glamsterdam is supposed to make future capacity increases more realistic, and that can help fee pressure if the scoped proposals actually make it through testing and activation. [EIP-7773]

Checkpoint #9 reinforces this cautious framing. It says implementation is well underway but also notes that both ePBS and gas repricing work are more complex than they first looked. That is exactly the kind of sentence users should want to hear from protocol engineers. It means they are not pretending a deep upgrade is easy just because the market wants a clean headline. [Checkpoint #9]

The most useful timeline takeaway from the primary sources is simple: there is no fixed public mainnet date yet, and the process still depends on stabilizing multi-client devnets. That makes Glamsterdam very important, but not yet date-certain. [Checkpoint #9, ACDT #82]

• ePBS liveness risk: EIP-7732 explicitly discusses the free option problem and the possibility that builders may withhold a payload if incentives change. [EIP-7732]
• Client coordination: Checkpoint #9 says every part of the stack has to reason about partial blocks and two-party coordination, which is why ePBS is harder than expected. [Checkpoint #9]
• Scope discipline: fee-relevant and networking proposals are still split between Scheduled and Considered, so scope management remains part of the engineering risk. [EIP-7773]
• Infrastructure adaptation: even if frontend apps do not change much, RPC providers, node operators, validators, explorers, and indexers still have real migration work.

None of that means Glamsterdam is in trouble. It means Ethereum is treating a foundational upgrade like a foundational upgrade. That is exactly what careful protocol work is supposed to look like.

Glamsterdam matters because it targets Ethereum’s base-layer constraints directly. ePBS changes how blocks are proposed and validated. BALs change how the network can prepare and parallelize execution-related work. The surrounding scope includes gas repricing and capacity-related items that are meant to make higher throughput safer over time.

• It is one of Ethereum’s most important planned 2026 upgrades.
• Its center of gravity is clearly L1 scaling, ePBS, and BALs.
• Its exact final scope is still public and still moving.
• Its timing depends on successful devnets, testnets, and client readiness rather than a fixed launch promise.

If you want the shortest honest version, it is this: Glamsterdam is a serious scaling upgrade, not a simple fee patch. And that is exactly why it deserves close attention in 2026.