Ethereum Glamsterdam Upgrade Gains Momentum, with Mainnet Activation Targeted for H1 2026
Ethereum Glamsterdam Upgrade Gains Momentum, with Mainnet Activation Targeted for H1 2026
Ethereum’s next major network upgrade, Glamsterdam, is moving from “research-heavy” into “implementation-heavy” mode. According to the Ethereum Foundation’s recent Soldøgn Interop recap, core contributors aligned on several upgrade-defining milestones: a post-upgrade 200M gas limit floor, a stable external builder workflow for ePBS, and finalized EIP-8037 repricing parameters. These are not minor tweaks—they are foundational building blocks for scaling Ethereum Layer 1 while keeping the network verifiable by everyday node operators. You can read the full engineering context in the Ethereum Foundation’s write-up, “Soldøgn Interop Recap”. Soldøgn Interop Recap (Ethereum Foundation Blog)
At a roadmap level, Ethereum still lists Glamsterdam as “In development” for H1 2026. While a June 2026 window is frequently discussed in the ecosystem, the exact mainnet fork date depends on hardening work, multi-client testing, and final parameter confirmation in public core developer calls. Ethereum roadmap (ethereum.org)
Why Glamsterdam matters: scaling L1 without abandoning decentralization
Ethereum’s scaling strategy has been increasingly clear since 2024: keep Layer 1 as the most credible settlement and data availability layer, while letting Layer 2 rollups handle most high-frequency execution. Glamsterdam reinforces that direction by upgrading how Ethereum:
- builds blocks (via enshrined Proposer-Builder Separation, ePBS),
- executes workloads (via Block-Level Access Lists, enabling safer parallelism),
- and prices state growth (via EIP-8037 gas repricing).
ethereum.org frames Glamsterdam as a major step toward L1 scalability through block building and execution redesign. Glamsterdam overview (ethereum.org)
This is also why many observers describe Glamsterdam as one of Ethereum’s most consequential performance-oriented upgrades since The Merge—not because it changes consensus again, but because it changes the system’s throughput envelope and node sustainability assumptions at the same time. Ethereum roadmap (ethereum.org)
The headline capacity shift: from ~60M gas today to 200M post-upgrade
After Fusaka (activated December 3, 2025), ethereum.org notes Ethereum’s default gas limit moved to ~60M (from ~45M), alongside other DoS-hardening measures. Ethereum roadmap – Fusaka section (ethereum.org)
Glamsterdam’s current engineering target is much more aggressive. The Ethereum Foundation’s Soldøgn recap describes alignment on a 200M post-Glamsterdam gas limit floor—a 3.33× increase in block gas capacity compared with ~60M. Soldøgn Interop Recap (Ethereum Foundation Blog)
Does 200M gas automatically mean 10,000 TPS?
Not directly. Gas limit ≠ TPS.
- TPS depends heavily on transaction mix (simple transfers vs. complex DeFi), L1 execution time, and network propagation constraints.
- That said, the “up to ~10,000 TPS” figure is best read as a theoretical upper bound under highly optimized conditions (and often discussed alongside parallel execution assumptions), not a guaranteed steady-state outcome on day one.
A more practical takeaway for users: more gas headroom generally reduces congestion, which can make fees less spiky and improve confirmation reliability—especially during peak activity.
ePBS: making block building a first-class protocol feature
One of Glamsterdam’s core features is enshrined Proposer-Builder Separation (ePBS), standardized in EIP-7732. In simplified terms, ePBS integrates a proposer/builder workflow into consensus so validators can safely rely on specialized builders without depending on “out-of-protocol” coordination. EIP-7732: Enshrined Proposer-Builder Separation (eips.ethereum.org)
During Soldøgn, teams emphasized that ePBS is not just an MEV topic—it’s also a scaling lever. By structuring the slot with clearer deadlines and responsibilities, ePBS can increase execution “headroom” and make higher gas limits more realistic. Soldøgn Interop Recap (Ethereum Foundation Blog)
Why it matters to everyday users:
- More predictable block construction and better-designed failure handling can improve overall network robustness.
- Over time, deeper protocol-level PBS may reduce some forms of MEV-driven instability, although MEV does not disappear and outcomes depend on final design choices.
EIP-8037: scaling throughput while pricing state growth responsibly
If Ethereum increases block capacity without addressing state growth incentives, node requirements can balloon. Glamsterdam’s design explicitly acknowledges this risk.
EIP-8037 (State Creation Gas Cost Increase) is a key part of the solution: it raises and refines the cost of operations that create long-lived state, aiming to keep state growth aligned with real resource costs. EIP-8037: State Creation Gas Cost Increase (eips.ethereum.org)
The Ethereum Foundation’s Soldøgn recap highlights that final repricing numbers for EIP-8037 were locked in during the interop week, and frames repricings as essential to making a 200M gas limit target credible. Soldøgn Interop Recap (Ethereum Foundation Blog)
What this means for builders and DeFi teams:
- Some contracts and transaction patterns may become more expensive if they are state-write-heavy.
- Teams should proactively benchmark on devnets and review opcodes and storage patterns that could be affected by repricing.
Verkle Trees, pruning, and “expunging” old data: keeping nodes viable
Glamsterdam is often discussed alongside two closely related sustainability tracks:
-
Verkle Trees and statelessness direction
Verkle Trees are widely viewed as a major enabling technology for smaller proofs and more “stateless” client designs. For a technical introduction, EF researcher Guillaume Ballet’s Devcon talk deck remains a strong reference. Stateless Ethereum: How Verkle Trees make Ethereum lean and mean (Devcon archive PDF) -
History expiry and longer-term state expiry concepts
Ethereum has already shipped concrete progress on pruning historical block data through EIP-4444. The Ethereum Foundation notes that execution clients support partial history expiry and explains why most users don’t need full historical blocks locally, while archive providers can serve specialized queries. Partial history expiry announcement (Ethereum Foundation Blog)
EIP-4444: Bound Historical Data in Execution Clients (eips.ethereum.org)
Meanwhile, longer-term state expiry designs (often described informally as “state expunging”) explore the idea of segmenting state over roughly year-long periods so clients are not forced to retain very old state indefinitely—an approach explicitly tied to Verkle-based designs. State expiry draft (notes.ethereum.org)
The important nuance: history expiry is already real and deployed in clients; full state expiry is still an evolving design space. Glamsterdam’s scaling push makes these sustainability mechanisms more urgent, but final scope and activation details depend on testing and governance.
Fee behavior: lower volatility via capacity + better pricing, not magic
Ethereum’s fee market (post EIP-1559) is designed to algorithmically adjust base fees as blocks fill. EIP-1559: Fee market change (eips.ethereum.org)
Glamsterdam’s impact on fees is likely to be indirect but meaningful:
- More block capacity can reduce congestion peaks, which is what typically causes abrupt base fee jumps.
- Gas repricing (including EIP-8037) makes the fee market better reflect real long-term burdens, which helps prevent “cheap state” from turning higher throughput into unsustainable node requirements.
For users, this tends to translate into a simpler expectation: fewer fee shocks during high demand, though fees will still move with market conditions.
Layer 2 impact: cheaper settlement and intensified rollup competition
Ethereum’s roadmap continues to emphasize rollups as the main path to low-cost execution at scale. Layer 2 networks overview (ethereum.org)
If Glamsterdam successfully raises L1 throughput and improves execution predictability, rollups may benefit in multiple ways:
- Lower congestion for L1 transactions that rollups depend on (proving, upgrading, bridges, forced exits).
- Better economics for publishing and settling data, depending on how demand shifts between execution gas and blob markets over time.
This is why market discussions often predict significant rollup fee compression and renewed competition among major ecosystems such as Arbitrum, Optimism, and Base—especially in user-facing products where a few cents of fee difference changes conversion rates. (Exact percentages vary widely by workload and market conditions, so treat any single number as scenario-based rather than guaranteed.)
Strategically, Glamsterdam strengthens the long-running thesis:
- L1 = high-security settlement and neutrality layer
- L2 = high-frequency execution layer
Timeline reality check: H1 2026 target, but dates depend on devnets and client hardening
Ethereum’s public roadmap places Glamsterdam in H1 2026, but the network has not announced a final fork epoch for mainnet yet. Ethereum roadmap (ethereum.org)
Core developers have also been explicit that the path to mainnet goes through iterative devnets, stabilization, security review, and then testnet readiness. The Ethereum Foundation’s Checkpoint #9 (Apr 2026) explains that ePBS and other headliner components are still complex, and outlines the “devnet → testnet → announce mainnet fork date” process. Checkpoint #9: Apr 2026 (Ethereum Foundation Blog)
And even after Soldøgn’s progress, final values (including
