Ethereum developers have scheduled the Glamsterdam network upgrade to go live on the Sepolia testnet on Oct. 6, 2026, at 13:53:36 UTC, corresponding to epoch 353,024 and slot 11,296,768. The release follows the earlier Fusaka upgrade and is presented as the next step in Ethereum’s layer-1 scaling roadmap.

The announcement only fixes the Sepolia rollout for now. Activation dates for the Hoodi test network and for Ethereum mainnet have not yet been decided, and the Ethereum Foundation said those timings will be announced later by client teams.

What Glamsterdam changes

Glamsterdam combines the Amsterdam execution-layer changes with the Gloas consensus-layer changes. Its main technical features are enshrined proposer-builder separation, or ePBS, and block-level access lists, or BALs, which are designed to change how blocks are built and checked in order to support higher L1 throughput.

Under EIP-7732, proposer-builder separation is moved into Ethereum’s consensus protocol. A proposer includes a builder’s commitment to an execution payload, and the builder then reveals that payload. The protocol also handles payment to the proposer, a change intended to reduce reliance on trusted middleware between proposers and builders.

The same proposal separates consensus validation from execution validation, giving validators more time to verify execution payloads. A payload timeliness committee is tasked with attesting whether the builder revealed its payload and whether the related blob data was available on time.

Parallel validation and gas repricing

Block-level access lists arrive through EIP-7928. These enforced lists record which accounts and storage locations were accessed during a block, along with post-transaction state changes. According to the announcement, that should let clients read state from disk in parallel, validate transactions in parallel, and calculate state roots more efficiently.

Glamsterdam also revises gas accounting to better match resource usage and state growth. EIP-8037 raises and separately meters the cost of creating state, while EIP-8038 updates the cost of state access. Other scheduled changes affect intrinsic transaction gas, calldata, access lists, and block gas accounting.

Ethereum said application developers should test contracts and gas estimation against the new rules. Contracts that depend on fixed gas stipends, hardcoded gas limits, or assumptions about remaining gas may need updates.

Additional EIPs and operator requirements

Beyond the headline changes, the upgrade package includes ETH transfer logs, a slot-number opcode, a larger maximum contract size, a deterministic factory contract, and new stack-manipulation instructions. On the consensus side, Glamsterdam also adds forward-compatible data structures, excludes slashed validators from proposing, and increases exit and consolidation churn.

The specification tracker for the upgrade is EIP-7773, which lists 18 scheduled EIPs in total, including EIP-8246 to remove SELFDESTRUCT burn and EIP-8282 for builder execution requests. Supporting networking and informational EIPs are listed separately in the announcement.

Node operators must update both execution-layer and consensus-layer clients before Sepolia activation. The Ethereum Foundation said only releases whose notes explicitly confirm support for the scheduled Sepolia fork should be used.

Client releases and the next steps

The announcement lists Sepolia-ready consensus clients including Lodestar 1.49.0, Prysm 7.2.0, and Teku 26.9.1. For execution clients, the listed releases are Besu 26.9.0, Erigon 3.7.0, go-ethereum 1.17.6, Nethermind 2.0.0, and Reth 2.7.0.

Ethereum also highlighted a Prysm-specific setting: version 7.2.0 supports the Sepolia fork but defaults to a 60 million gas limit after activation. Validators that want to propose with a 200 million gas limit must configure that explicitly through version 2 proposer settings or the keymanager API, because the suggested-gas-limit flag no longer applies after Gloas.

The Ethereum Bug Bounty Program is now active for Glamsterdam specifications and EIPs, while client implementations become eligible once their releases are added to the published client tables. Compatibility guidance for builder and validator tooling is still to come, and operators using external block-building infrastructure have been told to review any Glamsterdam-specific upgrade instructions before the Sepolia fork.

Source: blog.ethereum.org