Ethereum developers announced that the Glamsterdam upgrade will activate on the Sepolia testnet on October 6 at 13:53:36 UTC (21:53:36 Beijing time), corresponding to epoch 353,024 and slot 11,296,768. Glamsterdam combines execution-layer Amsterdam and consensus-layer Gloas changes and introduces enshrined proposer-builder separation (ePBS), block-level access lists, and a suite of gas metering adjustments intended to improve Layer-1 throughput and make gas costs better reflect execution and state-growth expenses. Key EIPs cited include EIP-7732 for ePBS, EIP-7928 for block-level access lists, EIP-8037 to raise and separately measure state-creation costs, and EIP-8038 to change state-access costs.
Sepolia node operators must update both execution and consensus clients before activation. The Foundation and client teams listed compatible execution releases such as go-ethereum 1.17.6, Besu 26.9.0, Nethermind 2.0.0, Erigon 3.7.0 and Reth 2.7.0, and consensus implementations including Lodestar 1.49.0, Prysm 7.2.0 and Teku 26.9.1. Prysm 7.2.0 defaults to a 60 million gas limit after activation; validators who intend to propose blocks with a 200 million gas limit must configure proposer controls accordingly. Earlier devnet testing, including a temporary Platåberget testnet, surfaced consensus finality and EIP-8037 issues that prompted continued testing and client fixes.
Developers warned that contracts, wallets, indexers and gas estimators relying on fixed gas stipends or hardcoded limits may need modification. The Foundation has opened its bug bounty program to Glamsterdam specifications and EIPs to capture issues before any mainnet rollout. Hoodi remains a tentative next public testnet target (notes mention October 27 as a possible date), but a mainnet activation date is not scheduled; Ethereum.org lists Glamsterdam in Q4 2026 as unconfirmed. After Glamsterdam, the roadmap points toward Hegotá in 2027, which Ethereum co-founder Vitalik Buterin said could be the network’s last “normal” fork before a shift toward recursive STARKs, automated formal verification and quantum‑safe cryptography.