Update — October 22, 2026: The October 26 Hoodi testnet activation for the Glamsterdam network upgrade has been officially postponed, including the previously scheduled gas-limit increase to 200 million. The initial deployment schedule and activation instructions have been superseded, and node operators are advised to consult updated guidance for future network schedules.
Following its successful activation on the Sepolia testnet earlier this month on October 6, the anticipated Glamsterdam network upgrade had been scheduled to deploy on the Hoodi testnet. The comprehensive upgrade represents a major step forward in Ethereum’s Layer 1 scaling roadmap, introducing enshrined proposer-builder separation, block-level access lists, and critical adjustments to gas pricing designed to more accurately reflect the true costs of execution and state growth.
The Glamsterdam upgrade was originally slated to activate on the Hoodi network at epoch 132,352, corresponding to slot 4,235,264, which was expected to occur on October 26, 2026, at 17:42:48 UTC. Alongside this activation, Hoodi’s gas limit was set to rise to 200 million, mirroring the parameters established during the Sepolia deployment. However, with the postponement, the new timeline remains under review, and a final mainnet activation date has not yet been determined by core developers and client teams.
As part of the ongoing preparation process, Hoodi-compatible client versions are systematically integrated into release tables as they pass validation checks. Node operators are repeatedly reminded that successful participation in network upgrades requires updating both their execution layer and consensus layer clients well ahead of activation epochs.
Glamsterdam Overview
Glamsterdam represents a unified hard fork that combines the Amsterdam execution layer upgrade with the Gloas consensus layer upgrade. The core focus of the combined upgrade centers on headlining structural changes, specifically enshrined proposer-builder separation and block-level access lists. Together, these modifications fundamentally alter how blocks are produced, broadcast, and validated across the network, providing a robust foundation for enhanced Layer 1 throughput without compromising decentralization.
Enshrined Proposer-Builder Separation
One of the most consequential changes introduced in the upgrade is enshrined proposer-builder separation, tracked under EIP-7732. This protocol-level adjustment brings the long-discussed separation between block proposers and specialized block builders directly into Ethereum’s consensus mechanism. Under this new framework, a block proposer includes a builder’s cryptographic commitment to an execution payload, and the builder subsequently reveals that payload to the network.
Crucially, the protocol automatically handles payments from builders to proposers, significantly reducing the network’s reliance on trusted third-party middleware for the exchange of blocks. Furthermore, the architecture decouples consensus validation from execution validation. This separation grants validator nodes additional time to thoroughly validate execution payloads before attesting to them. A dedicated payload timeliness committee verifies whether the builder successfully revealed its payload and whether the corresponding blob data was available within the required time window. Validator operators and engineering teams maintaining builder infrastructure are strongly encouraged to review the new duties and interfaces ahead of future deployment dates.
Block-Level Access Lists
Complementing proposer-builder separation, EIP-7732 introduces enforced block-level access lists, known as BALs. These lists systematically record the specific accounts and storage locations accessed over the course of an entire block, alongside all post-transaction state changes. By providing explicit visibility into state dependencies before execution, BALs allow client software to read state data from disk in parallel, validate transactions simultaneously, and compute state roots with substantially greater efficiency.
The synergy between enshrined proposer-builder separation and block-level access lists creates a powerful framework for scaling execution capacity. By streamlining state access and parallelizing validation workloads, the network can safely handle heavier transaction volumes while keeping hardware requirements and block validation times practical for independent node operators.
Gas Pricing and State Growth
To ensure the long-term health of the network, Glamsterdam also implements significant adjustments to gas accounting, aligning transaction fees more closely with actual resource consumption. EIP-8037 increases and separately meters the computational cost associated with creating new state, while EIP-8038 updates general state-access costs. Additional adjustments cover intrinsic transaction gas, calldata processing, access lists, and overarching block gas accounting structures.
Application developers are urged to rigorously test their smart contracts and gas estimation logic against the revised rules. Contracts that depend on fixed gas stipends, hardcoded gas limits, or assumptions regarding remaining gas availability may encounter failures under the new pricing model. Developers should consult dedicated impact guides to search for affected contracts and verify compatibility before the upgrade reaches public testnets and mainnet.
Developer and Validator Improvements
Beyond its headline scaling features, Glamsterdam introduces several developer-friendly enhancements and consensus-level refinements. The upgrade incorporates native ETH transfer logs, a dedicated slot-number opcode, an increased maximum contract size limit, a deterministic factory contract, and new stack-manipulation instructions designed to optimize smart contract deployment and execution.
On the consensus side, modifications include forward-compatible data structures, rules to exclude slashed validators from proposing new blocks, and an increased exit and consolidation churn limit to improve validator set management. These changes are tracked collectively under EIP-7773, which outlines the comprehensive list of included execution and consensus specifications, alongside supporting networking and informational enhancements.
Glamsterdam Security
Security remains a top priority throughout the testing and deployment lifecycle. The Ethereum Bug Bounty Program is fully active for all Glamsterdam specifications and associated EIPs. Client implementations become eligible for bug bounty rewards as soon as their respective releases are officially published and verified. Security researchers and auditors are encouraged to review the official bug bounty documentation for details regarding reward multipliers, submission guidelines, and reporting requirements.
Glamsterdam Activation
The agreed deployment schedule reflects a coordinated effort among client teams to test protocol changes thoroughly across public test networks before considering mainnet deployment. While Sepolia successfully adopted the upgrade on October 6, 2026, the subsequent Hoodi testnet activation originally scheduled for October 26 has been temporarily delayed. The mainnet activation timeline will be formally decided and announced by client developers once testnet stability is fully assured.
Client Releases
Maintaining a secure and synchronized network requires node operators to run up-to-date, compatible client software. Hoodi-compatible client releases for both consensus and execution layers are published alongside tooling updates, such as compatible versions of Commit-Boost. Operators relying on external block-building infrastructure or specialized validator tooling must review vendor-specific upgrade instructions to ensure seamless compatibility with the new ePBS duties and gas limit configurations.
Frequently Asked Questions
Ethereum network upgrades operate through an explicit opt-in model coordinated by client developers, protocol researchers, and node operators. Because nodes enforcing the old rules cannot follow the upgraded chain after activation, timely software updates across the ecosystem are essential for maintaining consensus.
For ordinary Ethereum mainnet users and ETH holders, no direct action is required for testnet announcements, as mainnet upgrades follow separate, dedicated schedules. Similarly, non-staking node operators and validators on testnets must update both their execution and consensus layer clients—ensuring both beacon nodes and validator clients are current—before the activation threshold is reached. Application and tooling developers should utilize the testing period to evaluate how repricing rules, new opcodes, and modified client interfaces impact their smart contracts and infrastructure.
Execution layer upgrades draw their names from past Devcon and Devconnect host cities, while consensus layer upgrades take their names from stars. Glamsterdam appropriately merges Gloas with Amsterdam, commemorating the location of the 2022 Devconnect event.
Ethereum & Smart Contracts
Ethereum & Smart Contracts
Ethereum & Smart Contracts
