Glamsterdam follows the Fusaka upgrade, advancing Ethereum’s L1 scaling roadmap with enshrined proposer-builder separation, block-level access lists, and changes to gas pricing that better reflect the cost of execution and state growth.
The Glamsterdam network upgrade is scheduled to activate on Sepolia at epoch 353,024, slot 11,296,768 (October 6, 2026, 13:53:36 UTC). See the activation table below for the deployment schedule. Hoodi and mainnet activation dates have not yet been decided.
Sepolia-compatible client versions will be added to the client release tables as they are confirmed. Node operators must update both their execution and consensus layer clients before activation.
Glamsterdam Overview
Glamsterdam combines the Amsterdam execution layer upgrade with the Gloas consensus layer upgrade. Its headlining changes are enshrined proposer-builder separation (ePBS) and block-level access lists (BALs), which change how blocks are produced and validated to support greater L1 throughput.
Enshrined Proposer-Builder Separation
EIP-7732 brings the separation between block proposers and builders into Ethereum’s consensus protocol. A proposer includes a builder’s commitment to an execution payload, and the builder subsequently reveals that payload. The protocol handles payment to the proposer, reducing reliance on trusted middleware for the exchange between proposers and builders.
The change also separates consensus validation from execution validation, giving validators more time to validate execution payloads. A payload timeliness committee attests to whether the builder revealed its payload and the corresponding blob data was available on time. Validator operators and teams maintaining builder infrastructure should review the new duties and interfaces before the upgrade.
Block-Level Access Lists
EIP-7928 introduces enforced block-level access lists that record the accounts and storage locations accessed during a block, together with post-transaction state changes. These lists allow clients to read state from disk in parallel, validate transactions in parallel, and compute state roots more efficiently.
Together, ePBS and BALs provide a foundation for scaling execution capacity while keeping block validation practical for node operators.
Gas Pricing and State Growth
Glamsterdam adjusts gas accounting to better reflect resource usage. EIP-8037 increases and separately meters the cost of creating state, while EIP-8038 updates state-access costs. Additional changes cover intrinsic transaction gas, calldata, access lists, and block gas accounting.
Application developers should test contracts and gas estimation against the new rules. Contracts that rely on fixed gas stipends, hardcoded gas limits, or assumptions about remaining gas may need changes. See the Glamsterdam repricing impact guide for the affected-contracts search and testing guidance.
Developer and Validator Improvements
Glamsterdam also includes ETH transfer logs, a slot-number opcode, a higher maximum contract size, a deterministic factory contract, and new stack-manipulation instructions. Consensus changes include forward-compatible data structures, excluding slashed validators from proposing, and increased exit and consolidation churn. The complete scheduled EIP list is below.
Glamsterdam Specifications
EIP-7773 tracks the Glamsterdam upgrade. The following EIPs are scheduled for inclusion:
EIP-7773 also lists supporting networking and informational EIPs:
Glamsterdam Security
The Ethereum Bug Bounty Program is now active for Glamsterdam specifications and EIPs. Client implementations become eligible as soon as their releases are added to the client release tables below. See the Ethereum Bug Bounty Program for more information, including reward multipliers and reporting requirements.
Glamsterdam Activation
The agreed deployment schedule, reflected in the Sepolia activation update to EIP-7773, is:
| Network | Epoch | Slot | UTC Time | UNIX Timestamp |
|---|---|---|---|---|
| Sepolia | 353,024 | 11,296,768 | 2026-10-06 13:53:36 | 1791294816 |
| Hoodi | TBD | TBD | TBD | TBD |
| Mainnet | TBD | TBD | TBD | TBD |
Hoodi and mainnet activation times will be announced once decided by client teams. This announcement covers Sepolia; it does not schedule a mainnet upgrade.
Client Releases
Sepolia-compatible client releases are listed below. The tables will be updated as additional releases become available. Only use a release whose notes explicitly confirm support for the scheduled Glamsterdam activation on Sepolia.
Consensus Layer Sepolia Releases
When running a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.
Prysm 7.2.0 supports the Sepolia fork but defaults to a 60M gas limit after activation. Validators wishing to propose with a 200M gas limit must configure it explicitly using version 2 proposer settings or the keymanager API; –suggested-gas-limit has no effect after Gloas. See the Prysm release notes for instructions.
Teku 26.9.1 supports the Sepolia fork but defaults to a 60M gas limit after activation. Validators wishing to propose with a 200M gas limit must configure it explicitly using –validators-builder-registration-default-gas-limit=200000000. See the Teku docs for details.
Execution Layer Sepolia Releases
Builder and validator tooling compatibility guidance will be added once confirmed for Sepolia. Operators using external block-building infrastructure should also review its Glamsterdam-specific upgrade instructions.
FAQ
How do Ethereum network upgrades work?
Ethereum network upgrades require explicit opt-in from node operators. Client developers coordinate the protocol changes, and validators and non-staking nodes update their software to support them.
A node that does not support the new rules cannot follow the upgraded network after activation. Coordinating these updates is therefore essential for a successful upgrade.
For a more exhaustive overview of Ethereum’s governance process, see this talk by Tim Beiko.
As an Ethereum mainnet user or ETH holder, is there anything I need to do?
No. This announcement concerns Sepolia. A separate announcement will cover Glamsterdam’s activation on mainnet.
If you’d like to watch the upgrade go live, you can join the online viewing party!
As a non-staking Sepolia node operator, what do I need to do?
Before October 6, 2026 at 13:53:36 UTC, update both your execution and consensus layer clients to releases that support the scheduled Sepolia activation. The client release tables will be updated as versions are confirmed.
As a Sepolia staker, what do I need to do?
Update your execution and consensus layer clients before activation. Make sure both your beacon node and validator client are updated. Review your client’s upgrade instructions for the new ePBS duties and any changes required to builder or validator tooling.
As a Hoodi or mainnet node operator or staker, what do I need to do?
No action is required for those networks as a result of this Sepolia announcement. Their activation dates and compatible client releases will be announced separately.
As an application or tooling developer, what should I do?
Review the EIPs scheduled for Glamsterdam, test on Sepolia after activation, and check whether changes to gas accounting, logs, opcodes, or client interfaces affect your project. In particular, follow the repricing impact guide to identify contracts that depend on fixed gas assumptions and update gas estimation where needed.
Why “Glamsterdam”?
Execution layer upgrades are named after Devcon or Devconnect host cities, and consensus layer upgrades use star names. Glamsterdam combines Gloas and Amsterdam, the location of Devconnect in 2022.
