Ethereum developers have warned that the upcoming Glamsterdam upgrade could disrupt wallets, indexers and gas estimators that rely on fixed gas assumptions. The caution comes as the network prepares to activate the upgrade on the Platåberget testnet on August 20. Like every Ethereum protocol upgrade, Glamsterdam is a hard fork: node operators and application developers must adopt the new rules in a coordinated step, which is why compatibility problems are being flagged well in advance.

Glamsterdam Changes Ethereum's Gas Assumptions

The Ethereum Foundation's Protocol DevOps team said software that depends on a hardcoded maximum gas limit may break once Glamsterdam ships. Developers have therefore been urged to test their applications on Platåberget before the changes reach Ethereum's longer-running testnets.

According to the Ethereum Foundation, Glamsterdam introduces several changes affecting Ethereum's execution and consensus layers, including gas repricing, enshrined proposer-builder separation and block-level access lists.

The gas changes are the most likely source of trouble for software built around fixed transaction-cost assumptions. In particular, EIP-8037 introduces a separate state-gas dimension for operations that create new Ethereum state. State growth is a long-standing scalability concern on Ethereum because every node must permanently store newly created accounts and storage entries, and the new dimension gives those operations their own explicit price.

An ETH transfer to an existing account will still require 21,000 gas. However, sending ETH to an account that does not yet exist will incur an additional state-gas charge. As a result, wallets and gas estimators that assume every ETH transfer costs exactly 21,000 gas may produce inaccurate estimates, and developers will need to account for the additional state-related costs when updating their software. That 21,000-gas figure has been unchanged since Ethereum launched in 2015, which is why it is baked into so much tooling. Gas repricing itself is rare but not unprecedented: the 2016 Tangerine Whistle fork raised costs for state-heavy operations in response to denial-of-service attacks on the network.

The changes also affect applications that create accounts, deploy contracts or write new storage. Developers should review transaction logic and gas calculations before Glamsterdam advances.

Platåberget Provides an Early Testing Environment

According to Forkcast, Platåberget launched on August 13 as a public testing environment for Glamsterdam. The testnet is expected to run for several months, giving developers more time to identify compatibility issues before the upgrade advances toward broader deployment.

The Ethereum Foundation said the Glamsterdam fork is scheduled for August 20 on Platåberget. Developers can also participate by submitting validator and builder deposits through the testnet infrastructure. Forkcast continues to track the upgrade's development and planned implementation across Ethereum's testing networks.

Broader Protocol Changes in Glamsterdam

Beyond gas repricing, Glamsterdam will introduce enshrined proposer-builder separation, changing parts of Ethereum's block-production process. Today that separation exists outside the protocol, largely through the widely used MEV-Boost relay system, which lets validators source blocks from external builders; enshrining it moves those mechanics into Ethereum's own rules. Block-level access lists will also record the state locations accessed during block execution.

The upgrade further raises Ethereum's maximum deployed contract size from 24 KiB to 64 KiB. The existing cap dates back to EIP-170, introduced in the 2016 Spurious Dragon fork. Initcode limits will increase from 48 KiB to 128 KiB, giving developers more room for larger applications.

After Platåberget testing, Ethereum developers plan additional development networks before Glamsterdam reaches Sepolia and Hoodi, the longer-running public testnets — Hoodi having been introduced in 2025 to replace the retired Goerli and Holesky networks. Mainnet deployment will follow only after the changes demonstrate sufficient stability.