[REVISION HISTORY]

Ethereum Glamsterdam upgrade development

12 recorded revisions of this situation.

What changed

2026-10-27 12:03 UTC → 2026-11-06 15:11 UTC · added ~~removed~~

The Ethereum Foundation is progressing with the Glamsterdam upgrade, a major technical advancement combining the Amsterdam execution layer with the Gloas consensus layer to improve Layer 1 scaling and throughput. Scheduled for a target mainnet activation in Q4 2026, the upgrade introduces EIP-7732 (enshrined proposer-builder separation) and EIP-7928 (block-level access lists) to decouple block proposers from builders and enable parallelization of disk reads. To manage growing state size, the upgrade implements gas repricing via EIP-8037 and EIP-8038. These proposals aim to align costs with the actual computational resources required for state creation and access. While most transactions should remain unaffected, developers using hardcoded gas assumptions may face execution failures, necessitating updates to wallets and RPC infrastructure for accurate estimation. Following performance testing by Nethermind, the upgrade launched on the Sepolia testnet on October 6, 2026. During this rollout, developers resolved a configuration issue with the Prysm transaction verification software to manage an intended increase in the transaction processing group limit from 60 million to 200 million units. Developers previously scheduled the Glamsterdam upgrade to activate on the Hoodi testnet on October 26, 2026. However, during the ACDE #248 call, core developers postponed this activation due to security concerns raised by ChainSecurity regarding EIP-8037 and EIP-8038. Specifically, gas repricing could cause failed calls to behave differently, potentially turning retryable operations into permanent failures. ChainSecurity identified 13 real-world smart contracts that could be affected, particularly those relying on fixed-gas assumptions like the gasleft() function or a 2,300-gas stipend. Additionally, a deposit-handling vulnerability was identified by researcher avsetsin. The flaw could have allowed staking deposits intended for a new validator to be incorrectly credited to a block builder if both roles shared the same public key. Developers have since merged a fix for this vulnerability into the consensus specifications.

Versions

Select a version to see what changed compared to the one before it.