October 24, 2026

Ethereum Prepares for Glamsterdam Network Upgrade with Hoodi Testnet Date Set

Following its successful activation on the Sepolia testnet earlier this month on October 6, the highly anticipated Glamsterdam network upgrade has officially locked in its next major milestone. Developers and network operators are now preparing for the upgrade to go live on the Hoodi testnet, marking another crucial step forward in Ethereum’s Layer 1 scaling roadmap.

The Glamsterdam upgrade combines the Amsterdam execution layer upgrade with the Gloas consensus layer upgrade. Its headlining features focus on improving throughput and efficiency, headlined by enshrined proposer-builder separation (ePBS), block-level access lists (BALs), and comprehensive adjustments to gas pricing designed to better reflect the true cost of execution and state growth.

According to the agreed deployment schedule, the Glamsterdam network upgrade is scheduled to activate on the Hoodi testnet at epoch 132,352, slot 4,235,264, which corresponds to October 26, 2026, at 17:42:48 UTC. At this exact activation epoch, Hoodi’s gas limit will also be raised to 200 million, mirroring the adjustments previously made on Sepolia. While the testnet trajectory is rapidly taking shape, an official mainnet activation date has not yet been decided by client teams and will be announced at a later time.

Ahead of the activation, Hoodi-compatible client versions are being finalized and rolled out across client release channels. Node operators are strongly advised to update both their execution layer and consensus layer clients well before the scheduled timestamp to ensure uninterrupted participation in the network.

Glamsterdam Overview

The core architecture of the Glamsterdam upgrade centers on modernizing how Ethereum blocks are produced, validated, and accounted for. By integrating the Amsterdam execution upgrades with the Gloas consensus updates, the developer community is tackling some of the most persistent bottlenecks limiting Layer 1 performance.

At the heart of these improvements are enshrined proposer-builder separation and block-level access lists. These changes fundamentally alter the mechanics of block validation, providing a robust technical foundation for scaling execution capacity while ensuring that running an independent node remains practical and accessible for operators.

Enshrined Proposer-Builder Separation

One of the most significant protocol changes introduced in Glamsterdam is enshrined proposer-builder separation, specified under EIP-7732. This update formally integrates the separation between block proposers and builders directly into Ethereum’s consensus protocol.

Under the new system, a block proposer includes a builder’s commitment to an execution payload, and the builder subsequently reveals that payload according to protocol rules. Crucially, the protocol itself handles the payment mechanism from the builder to the proposer. This native integration reduces the ecosystem’s reliance on trusted external middleware for the exchange of blocks between proposers and builders.

Furthermore, EIP-7732 separates consensus validation from execution validation, granting validators significantly more time to thoroughly validate execution payloads. A newly introduced 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 these new operational duties and interfaces before the upgrade goes live.

Block-Level Access Lists

Complementing ePBS, EIP-7732 introduces block-level access lists, or BALs, under EIP-7928. These enforced access lists systematically record the specific accounts and storage locations accessed during a given block, alongside the corresponding post-transaction state changes.

By utilizing block-level access lists, client software gains the ability to read state data from disk in parallel, validate transactions concurrently, and compute state roots with a much higher degree of efficiency. Together, ePBS and BALs pave the way for a more scalable execution environment without compromising decentralization.

Gas Pricing and State Growth

Glamsterdam also introduces major adjustments to gas accounting to ensure that fees accurately reflect underlying resource consumption. EIP-8037 increases and separately meters the cost associated with creating new state, while EIP-8038 updates general state-access costs. Additional modifications cover intrinsic transaction gas, calldata pricing, access lists, and broader block gas accounting rules.

Application developers will need to thoroughly test their smart contracts and gas estimation logic against these new parameters. Contracts that rely on fixed gas stipends, hardcoded gas limits, or outdated assumptions regarding remaining gas may require modifications. Developers can consult the Glamsterdam repricing impact guide for search tools and testing guidance to identify any potentially affected contracts.

Developer and Validator Improvements

Beyond its headline features, Glamsterdam delivers a variety of enhancements for developers and validators alike. The upgrade incorporates native ETH transfer logs, a new slot-number opcode, a higher maximum contract size, a deterministic factory contract, and fresh stack-manipulation instructions.

On the consensus side, changes include forward-compatible data structures, rules that exclude slashed validators from proposing new blocks, and increased exit and consolidation churn rates to improve the flexibility of the staking validator set.

Glamsterdam Specifications and Security

The overarching progress of the upgrade is tracked via EIP-7773, which outlines the comprehensive list of scheduled execution and consensus changes, as well as supporting networking and informational EIPs.

To ensure the robustness of the upgrade, 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 official releases are published. Security researchers and developers are encouraged to review the official Ethereum Bug Bounty Program documentation for details regarding reward multipliers and vulnerability reporting requirements.

Activation Details and Client Releases

The agreed deployment schedule places Hoodi activation immediately following Sepolia’s October 6 rollout. Hoodi’s gas limit increase to 200 million will execute simultaneously at epoch 132,352.

Mainnet activation remains under review, and client teams will announce a definitive timeline once testing on Sepolia and Hoodi is complete and stable. Node operators running consensus layer beacon nodes, validator clients, or execution layer clients must ensure they update to versions that explicitly confirm support for the Glamsterdam Hoodi activation. Operators utilizing external builder tooling should similarly verify compatibility with updated middleware releases such as commit-boost.

Frequently Asked Questions

Ethereum network upgrades rely on explicit, voluntary opt-in from node operators worldwide. Client developers coordinate protocol changes, while validators and non-staking nodes independently update their software. Nodes that do not adopt the new rules will find themselves unable to follow the upgraded network after activation, making community coordination vital.

For everyday ETH holders and Layer 1 mainnet users, no direct action is required for this testnet announcement. Mainnet upgrade instructions will be published separately ahead of that activation date. Non-staking Hoodi node operators and Hoodi stakers, however, must ensure that both their execution and consensus layer clients—including beacon nodes and validator clients—are fully updated prior to the October 26 activation timestamp.

Application and tooling developers should take time to review the scheduled EIPs, conduct comprehensive testing on Sepolia and Hoodi, and verify whether adjustments to gas accounting, opcodes, or logs impact their existing smart contracts.

Execution layer upgrades continue the tradition of naming releases after Devcon or Devconnect host cities, while consensus layer upgrades draw inspiration from star names. Glamsterdam aptly combines Gloas with Amsterdam, the historic location of Devconnect in 2022.