Ethereum Glamsterdam: What the 2026 Execution Layer Upgrade Changes

Ethereum’s Glamsterdam upgrade is the network’s next hard fork after Fusaka, bundling changes to both the execution layer (Amsterdam) and the consensus layer (Gloas). The upgrade’s two headline proposals tackle problems that have constrained Ethereum throughput for years: sequential transaction execution and off-chain dependency in block production. Together, they set the stage for a gas limit increase from roughly 60 million to a target of 200 million per block.

This article breaks down the confirmed EIPs, explains how they change block production and validation, and examines what Glamsterdam means for rollups, node operators, and the broader Ethereum roadmap.

Why Glamsterdam Exists

The Pectra upgrade in May 2025 addressed validator economics and wallet UX. Fusaka, which activated on December 3, 2025, delivered PeerDAS for data availability sampling. But Ethereum still processes transactions one at a time within each block, and block production still relies on off-chain middleware that the protocol does not govern.

Glamsterdam targets these two structural bottlenecks. EIP-7928 enables parallel execution by providing validators with a map of each transaction’s state access. EIP-7732 brings proposer-builder separation into the protocol itself, removing the need for trusted relay infrastructure like MEV-Boost.

The Two Headline EIPs

EIP-7928: Block-Level Access Lists

Today, Ethereum clients execute every transaction in a block sequentially. A client cannot safely parallelize because it does not know in advance which storage slots or account balances a transaction will read or write. EIP-7928 solves this by attaching a Block-Level Access List (BAL) to each block: a structured record of every address and storage key touched during execution, along with post-execution values.

Block builders produce the BAL after executing transactions locally. Validators receiving the block can then use the list to partition transactions into independent groups and execute them in parallel. The BAL also enables parallel disk I/O, since validators know exactly which state entries to prefetch.

Strict validity: If a BAL is inaccurate or incomplete, the entire block is invalid. Missing an accessed storage key or including a spurious entry causes rejection. This makes the access list a hard commitment, not a hint.

Early benchmarks on Geth showed approximately 30% improvement in live sync performance using a reduced version of the BAL (without balance diffs or post-values). The full specification is expected to yield larger gains in block validation time, which is the critical bottleneck for raising the gas limit.

Beyond parallelism, BALs enable a second benefit: execution-less validation. ZK clients and light clients could verify blocks by checking the access list against a state proof without re-executing every transaction. This opens a path toward stateless Ethereum that Vitalik Buterin has described as part of The Verge roadmap phase.

EIP-7732: Enshrined Proposer-Builder Separation

Ethereum already separates proposers (validators who propose blocks) from builders (entities that construct block contents for MEV extraction). But this separation currently happens off-chain through middleware like MEV-Boost, maintained by Flashbots. An estimated 80 to 90 percent of Ethereum blocks are produced through this off-chain pipeline, making relay infrastructure a systemic dependency.

EIP-7732 brings this separation into the protocol with a commit-reveal mechanism. Proposers commit to a builder’s block header and broadcast it quickly. The builder then reveals the full execution payload within a defined window. A new Payload Timeliness Committee (PTC) monitors whether the builder delivers on time and votes on payload availability.

The result: validators no longer need to trust relays to deliver blocks honestly. The protocol itself enforces the exchange. Builders who fail to reveal payloads forfeit their bid, and proposers receive compensation regardless.

FOCIL waits for Hegotá: Fork-choice enforced Inclusion Lists (FOCIL, EIP-7805) were considered for Glamsterdam but deferred to the following upgrade, Hegotá. Shipping ePBS and FOCIL simultaneously was deemed too complex. The Base engineering team publicly warned that coupling them could delay the entire upgrade beyond 2026.

Additional EIPs in the Upgrade

Glamsterdam includes several smaller proposals alongside its two headliners. The EIP-7773 meta specification tracks the official inclusion list. Based on the most recent published scope, the following EIPs are scheduled:

The scope has shifted during development. EIP-7773 remains in Draft status, and several proposals (including EIP-7904 for opcode repricing and EIP-7954 for raising the maximum contract size) have been considered but not consistently confirmed across sources. Developers should monitor the Ethereum Magicians meta thread for the latest inclusion decisions.

Glamsterdam vs Pectra: What Changed Between Upgrades

The Pectra upgrade (May 7, 2025) focused on validator economics, wallet UX, and rollup data throughput. Glamsterdam shifts focus to execution infrastructure and block production mechanics. The two upgrades serve different parts of the stack:

Where Pectra was broad (touching staking, wallets, and data availability), Glamsterdam is deep: two large structural changes to how blocks are built and validated, supported by targeted gas repricing.

Impact on L2 Rollups

Rollups that settle to Ethereum benefit from Glamsterdam in several ways. The rollup fee war has pushed L2s to compete on data posting costs. Glamsterdam does not directly increase blob count (that may come in Hegotá or later), but its gas limit changes affect the broader fee environment.

• A higher gas limit (targeting 200M) increases total L1 block space, reducing competition for calldata and potentially lowering base fees via the EIP-1559 mechanism
• EIP-8037’s repricing of state creation separates the cost of permanent storage from temporary computation, making state-heavy rollup settlement transactions more predictable
• Faster block validation through parallel execution may support shorter slot times in future upgrades, improving rollup confirmation latency
• ePBS reduces the systemic risk of relay failures that could delay block inclusion for rollup batches

For ZK rollups in particular, BALs unlock a path toward proving block execution without full re-execution. A ZK prover that can verify state transitions against an access list (instead of replaying every opcode) could dramatically reduce proving time and cost.

What Validators and Node Operators Must Do

Glamsterdam requires updates to both execution and consensus layer clients. Validators running outdated software after the fork activation block will fall off the canonical chain.

• Update execution clients (Geth, Nethermind, Besu, Erigon, Reth) to Glamsterdam-compatible releases
• Update consensus clients (Prysm, Lighthouse, Teku, Nimbus, Lodestar) for EIP-7732 and EIP-7688 support
• Review block builder integrations: ePBS changes how proposers interact with builders, potentially obsoleting MEV-Boost configurations
• Monitor disk I/O and memory: parallel execution with BALs may shift hardware bottlenecks from CPU to storage throughput
• Test on Sepolia (activated October 6, 2026) before mainnet goes live

Ordinary ETH holders and users of wallets, dApps, and L2s do not need to take any action. The upgrade is transparent to end users.

Testnet and Mainnet Timeline

Glamsterdam was originally targeted for H1 2026 but slipped due to the complexity of ePBS implementation. The current timeline:

• Devnet testing began in early 2026, with multiple iterations (Devnet-4, Devnet-5, through Devnet-9) addressing stability issues
• Sepolia testnet activation: October 6, 2026, at 13:53 UTC
• Hoodi testnet: tentatively targeted for late October 2026, though confirmation of successful activation is pending
• Mainnet: no confirmed date as of mid-November 2026. Core developers are targeting Q4 2026, with December mentioned as a possibility. The mainnet date depends on clean testnet runs and client diversity readiness across all implementations

Ethereum Upgrade Cadence: Glamsterdam in Context

Since The Merge in September 2022, Ethereum has maintained a roughly biannual hard fork cadence. Each upgrade addresses a different part of Vitalik Buterin’s five-phase roadmap:

Glamsterdam sits at the intersection of The Surge (scaling throughput via parallel execution and higher gas limits) and The Scourge (reducing MEV-related centralization via ePBS). The Verge (stateless clients via Verkle Trees) and The Purge (state expiry) remain in later phases.

Open Risks and Unknowns

State Growth at 200M Gas

A 200 million gas limit without guardrails could push Ethereum state growth past 380 GiB per year, making it increasingly expensive to run a full node. EIP-8037 mitigates this by raising the cost of creating new state entries, but the balance between throughput and decentralization remains an active debate.

BAL Size and Overhead

Developers have raised concerns about the size and verbosity of block-level access lists. Complex blocks with many cross-contract interactions produce large BALs. If the overhead of transmitting and verifying the list outweighs the gains from parallel execution, the net benefit shrinks. Edge cases around opcodes like PREVRANDAO (which depends on the beacon chain state) also complicate completeness guarantees.

ePBS Builder Incentive Shifts

Enshrining PBS changes the economic relationship between proposers and builders. Builders who currently rely on off-chain reputation and relay relationships will compete in a protocol-defined auction. This could reduce barriers for new builders but may also concentrate power among builders with the lowest latency, mirroring concerns about MEV centralization that ePBS was designed to address.

Relay Deprecation Uncertainty

Even with ePBS, the transition away from MEV-Boost relays will not be instant. Validators may continue running relays alongside the protocol mechanism during a transition period. The coexistence of both systems adds operational complexity and could create edge cases in block production timing.

How This Compares to Bitcoin’s Approach

Ethereum’s biannual hard fork cadence stands in contrast to Bitcoin’s conservative upgrade philosophy. Bitcoin’s last consensus change, Taproot, activated in November 2021. No subsequent soft fork has reached activation, though proposals like OP_CAT and CTV remain under discussion.

This difference reflects fundamental design philosophies. Ethereum optimizes for feature velocity: shipping execution improvements, protocol-level MEV mitigation, and scaling changes on a regular cadence. Bitcoin prioritizes ossification: minimizing consensus-layer changes to preserve security guarantees.

For developers building across ecosystems, the distinction matters. Ethereum L2s benefit from frequent L1 improvements but must adapt to breaking changes. Bitcoin L2s like Spark operate on a stable base layer, building scalability through off-chain protocols rather than consensus changes. Understanding both models helps developers choose the right foundation for their use case.

What to Watch Next

With Sepolia live and Hoodi testing underway, Glamsterdam’s mainnet activation depends on clean testnet performance and client readiness. Developers building on Ethereum should:

• Follow the All Core Developers call notes for mainnet date announcements
• Test smart contracts against Sepolia to identify any behavioral changes from gas repricing (EIP-2780, EIP-7778) or the new SLOTNUM opcode (EIP-7843)
• Evaluate whether ePBS changes affect your block building or MEV strategy
• Monitor the L2 fee dynamics post-activation, especially if you operate a rollup sequencer

For developers exploring Bitcoin-native scaling as a complement to Ethereum, the Spark SDK documentation provides integration guides for building on a stable base layer with instant settlement and self-custody guarantees.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.