Following its successful activation on the Sepolia network earlier this month on October 6, Ethereum’s major upcoming network upgrade, known as Glamsterdam, is officially bound for its next testing milestone. Core developers and client teams have scheduled the upgrade to activate on the Hoodi testnet at epoch 132,352, corresponding to slot 4,235,264. The transition is set to occur precisely on October 26, 2026, at 17:42:48 UTC. Alongside this activation, the Hoodi testnet’s gas limit will be increased to 200 million, mirroring the parameters established on Sepolia. While testnet deployments are pressing forward, a definitive mainnet activation date has not yet been finalized by the development community.
Node operators running infrastructure on Hoodi must prepare for the upcoming transition by updating both their execution layer and consensus layer clients to compatible versions ahead of the scheduled activation time. Client release tables are continuously being updated as new software versions that support the Hoodi deployment are officially confirmed.
Glamsterdam Overview
The Glamsterdam network upgrade represents a massive collaborative effort, combining the Amsterdam execution layer upgrade with the Gloas consensus layer upgrade. At its core, the upgrade introduces pivotal structural changes designed to advance Ethereum’s layer-one scaling roadmap. The headline features of Glamsterdam include enshrined proposer-builder separation and block-level access lists. Together, these modifications fundamentally alter how blocks are produced, proposed, and validated across the network, paving the way for significantly higher layer-one throughput without compromising the decentralization or feasibility of node operations.
Enshrined Proposer-Builder Separation
One of the most anticipated architectural shifts in Glamsterdam is the introduction of enshrined proposer-builder separation, formalized under EIP-7732. This protocol-level change integrates the separation between block proposers and external builders directly into Ethereum’s consensus mechanism. Under the new framework, a block proposer includes a builder’s cryptographic commitment to an execution payload, and the builder subsequently reveals the actual payload during the slot. The protocol itself handles the secure payment transaction from the builder to the proposer, substantially reducing the network’s historical reliance on trusted third-party middleware for managing builder-proposer interactions.
Furthermore, this change decouples consensus validation from execution validation, granting validators a dedicated window of time to properly verify execution payloads. A newly introduced payload timeliness committee will actively attest to whether builders reveal their payloads and ensure that corresponding blob data remains available on schedule. Validator operators and engineering teams maintaining builder infrastructure are strongly advised to review these new operational duties and network interfaces well in advance of the upgrade.
Block-Level Access Lists
Complementing proposer-builder separation, EIP-7732 introduces block-level access lists, formalized via EIP-7928. These enforced lists systematically record all accounts and storage locations that are accessed during the execution of a block, alongside their respective post-transaction state changes. By providing explicit visibility into state dependencies, these lists enable client software to read state data from disk in parallel, validate transactions simultaneously, and compute state roots with a much higher degree of efficiency.
Gas Pricing and State Growth
Glamsterdam also introduces a comprehensive overhaul of Ethereum’s gas accounting system to ensure that resource costs more accurately reflect real-world execution and storage demands. Under EIP-8037, the cost associated with creating new state is significantly increased and separately metered, while EIP-8038 updates the base costs for accessing existing state. Additional modifications affect intrinsic transaction gas parameters, calldata pricing, access lists, and overall block gas accounting mechanics.
Application developers are encouraged to thoroughly test their smart contracts and gas estimation logic against these updated economic rules. Smart contracts that rely heavily on fixed gas stipends, hardcoded transaction gas limits, or legacy assumptions regarding remaining gas may require code modifications to function correctly after the upgrade. Developers can consult the official Glamsterdam repricing impact guide to search for affected contracts and access detailed testing methodologies.
Developer and Validator Improvements
Beyond its major architectural changes, the Glamsterdam upgrade packs a wide array of enhancements for developers and validators alike. The execution layer gains native ETH transfer logs, a dedicated slot-number opcode, an increased maximum contract size limit, a deterministic factory contract, and several new stack-manipulation instructions. On the consensus side, updates include forward-compatible data structures, protocol-level rules to exclude slashed validators from proposing blocks, and an increase in the maximum validator exit and consolidation churn rates.
Glamsterdam Security
To ensure the robustness of the upgrade, the Ethereum Bug Bounty Program has been expanded to cover all Glamsterdam specifications and associated EIPs. Client implementations become officially eligible for bug bounty rewards as soon as their respective software releases are integrated into the network’s tracking tables. Security researchers and developers looking to participate can review reward multipliers, submission guidelines, and reporting requirements directly through the official Ethereum Bug Bounty portal.
Glamsterdam Activation
The agreed deployment schedule places Sepolia as the earliest adopter, having activated the upgrade on October 6, 2026, at epoch 353,024 and slot 11,296,768. Hoodi follows as the second testing environment on October 26, 2026, at epoch 132,352. Alongside the activation on Hoodi, the network’s gas limit will scale up to 200 million via the implementation of EIP-8261. Mainnet activation remains under discussion, and client teams will announce a concrete date and timeline once consensus is reached.
Client Releases
Node operators and validators preparing for the Hoodi upgrade must ensure they utilize client versions that explicitly declare support for the upcoming transition. When running validator infrastructure, operators are reminded that both the consensus layer beacon node and the validator client must be updated simultaneously. Additionally, tooling providers have begun releasing compatible software packages, such as commit-boost version 0.12.0-rc1, with further compatibility guidelines expected to roll out as the activation window approaches.
FAQ
Ethereum network upgrades rely entirely on the explicit opt-in and coordination of independent node operators and client developers. Because a node running outdated software cannot follow the new protocol rules after activation, timely software updates are vital for maintaining network continuity. Mainnet users and general ETH holders are not required to take any personal action for the Hoodi testnet upgrade, as mainnet activation will be scheduled and announced separately at a later date.
Non-staking node operators on the Hoodi testnet must update both their execution and consensus layer clients prior to the October 26 activation timestamp. Similarly, Hoodi stakers must ensure both their beacon nodes and validator clients are fully updated, while taking time to review any changes to ePBS duties or validator gas limit targets. Application developers should leverage testnets to evaluate how the new gas pricing rules, opcodes, and execution changes impact their smart contracts and decentralized applications, ensuring a smooth transition ahead of Ethereum’s eventual mainnet deployment.
Comments (0)