The scheduled October 26 activation of the Glamsterdam network upgrade on the Hoodi testnet has been officially postponed, according to a developer update released on October 22, 2026. The delay also puts a temporary hold on Hoodi’s planned gas-limit increase to 200 million. As a result, the deployment schedule and activation instructions previously issued have been superseded, prompting core developers and client teams to advise network operators to consult updated guidance for future timelines.
The postponement follows the upgrade’s successful activation on the Sepolia testnet earlier in the month on October 6. Prior to the delay, the Glamsterdam network upgrade was slated to go live on Hoodi at epoch 132,352, or slot 4,235,264, corresponding to October 26, 2026, at 17:42:48 UTC. At that exact epoch, Hoodi’s gas limit was set to rise to 200M to align with network scaling metrics tested on Sepolia. While testnet preparations continue to evolve, an official mainnet activation date for Glamsterdam has not yet been decided by the core developer community.
Node operators have been instructed to monitor upcoming client release announcements carefully. Once revised schedules are finalized, operators of both execution and consensus layer clients will need to update their software before any new activation timestamp takes effect to ensure compatibility with the upgraded network rules.
Glamsterdam Overview
The Glamsterdam network upgrade represents a major milestone in Ethereum’s Layer 1 scaling roadmap, combining the Amsterdam execution layer upgrade with the Gloas consensus layer upgrade. Its headlining features focus on transforming how blocks are produced, validated, and processed to achieve significantly greater throughput on the base layer without compromising decentralization or increasing undue burdens on node operators.
At the core of these changes are enshrined proposer-builder separation and block-level access lists. These structural adjustments alter the underlying mechanics of transaction execution and network validation, providing a robust foundation for future capacity expansions while keeping block validation practical for the broader node-operating community.
Enshrined Proposer-Builder Separation
Following the integration principles outlined in EIP-7732, Glamsterdam brings the separation between block proposers and builders directly into Ethereum’s consensus protocol. Under this enshrined model, a block proposer includes a builder’s commitment to an execution payload, and the builder subsequently reveals that payload according to protocol rules. The protocol itself handles the payment mechanism to the proposer, effectively reducing the network’s reliance on trusted external middleware for the exchange of blocks between proposers and builders.
This architectural shift also cleanly separates consensus validation from execution validation, granting validators additional time to process and verify execution payloads safely. Furthermore, a dedicated payload timeliness committee will attest to whether the builder successfully revealed its payload and whether the corresponding blob data was made available on time. Validator operators and engineering teams maintaining builder infrastructure are strongly encouraged to review the new duties and protocol interfaces ahead of the rescheduled activation.
Block-Level Access Lists
In tandem with proposer-builder separation, EIP-7928 introduces enforced block-level access lists to the protocol. These lists comprehensively record the accounts and storage locations accessed over the course of a block, alongside the resulting post-transaction state changes. By embedding these access lists directly into the block structure, client software gains the ability to read state data from disk in parallel, validate transactions simultaneously, and compute state roots with greater computational efficiency.
Gas Pricing and State Growth
Glamsterdam also introduces comprehensive adjustments to gas accounting to ensure that transaction fees more accurately reflect real-world resource consumption and storage costs. EIP-8037 increases and separately meters the financial and computational cost of creating new state, while EIP-8038 updates broader state-access costs. Additional protocol modifications cover intrinsic transaction gas parameters, calldata processing, access lists, and overarching block gas accounting.
Application developers are advised to rigorously test their smart contracts and gas estimation logic against these revised rules. Contracts that rely on fixed gas stipends, hardcoded gas limits, or assumptions regarding remaining gas during execution may require modifications to function correctly after the upgrade. Developers can consult the Glamsterdam repricing impact guide to search for affected contracts and access specific testing guidance.
Beyond these major changes, the upgrade includes several developer and validator improvements, such as native Ethereum transfer logs, a new slot-number opcode, a higher maximum contract size limit, a deterministic factory contract, and updated stack-manipulation instructions. Consensus layer adjustments feature forward-compatible data structures, provisions to exclude slashed validators from proposing new blocks, and an increase in exit and consolidation churn rates.
Glamsterdam Security and Specifications
The Ethereum Bug Bounty Program remains fully active for all Glamsterdam specifications and associated EIPs. Client implementations become eligible for bounty rewards as soon as their respective software releases are officially cataloged in the network release tables. Security researchers and developers can review the official Ethereum Bug Bounty documentation for details regarding reward multipliers and vulnerability reporting requirements.
Tracking under EIP-7773, the upgrade encompasses a wide array of technical specifications, networking enhancements, and informational proposals designed to streamline client communication and protocol efficiency.
Client Releases and Tooling
With the Hoodi activation temporarily postponed, previously published release schedules are under review. When new activation milestones are established, compatible client versions for both consensus layer beacon nodes and validator clients, as well as execution layer clients, will be provided through standard release channels.
Node operators running validators must ensure that both their beacon node and validator client software are updated simultaneously. Only software releases whose official notes explicitly confirm support for the scheduled Glamsterdam activation on Hoodi should be deployed in production or test environments. External tooling, such as commit-boost and other builder or validator utilities, will also require updates and verification prior to the new launch date.
FAQ
Ethereum network upgrades rely on explicit, voluntary opt-in from node operators across the ecosystem. Client developers coordinate the protocol changes, while validators and non-staking node operators update their software to adopt the new rules. Because any node running outdated software cannot follow the upgraded network after activation, coordinated updates remain a vital part of Ethereum’s governance and operational model.
For Ethereum mainnet users and general ETH holders, no direct action is required in response to testnet upgrade announcements. Testnets like Hoodi and Sepolia allow developers and operators to test protocol changes in live environments before any mainnet deployment is scheduled. Application and tooling developers should utilize the testnet periods to review scheduled EIPs, test contract compatibility against new gas accounting rules, and update gas estimation pipelines accordingly.
Comments (0)