Ethereum Prepares Developers for Glamsterdam Gas Changes
Ethereum Foundation has warned smart contract teams to test against upcoming Glamsterdam gas repricings before the upgrade reaches mainnet. The change centers on EIP-8037 and EIP-8038, which adjust the cost of creating and accessing state. Historical transaction replay suggests most contracts are unaffected, but a small set may fail or degrade if they rely on fixed gas assumptions.Why Glamsterdam changes gas accounting
The Glamsterdam upgrade includes gas repricings intended to bring state-related operation costs closer to the real work those operations impose on Ethereum nodes. In its Aug. 24 post, Ethereum Foundation said EIP-8037 and EIP-8038 are scheduled for inclusion and target the cost of creating and accessing state.EIP-8037 increases and harmonizes the cost of creating new state, including new accounts, new storage slots and deployed bytecode. It also meters that work separately, a change presented as part of keeping state growth sustainable as gas limits rise. EIP-8038 raises the cost of state access operations including SSTORE, SLOAD, cold account access, EXTCODESIZE and EXTCODECOPY.
The foundation said gas prices for state operations were last adjusted in the Berlin fork in 2021. Since then, Ethereum's state has grown significantly, and recent gas limit increases have accelerated that growth. The practical implication is that contracts and infrastructure built around older gas constants may behave differently when the new schedule is active.
Transaction replay found a narrow but real risk
Ethereum Foundation said it replayed historical mainnet transactions under the new gas schedule to measure real-world divergence rather than only theoretical effects. The replay grouped transactions into four outcomes: no change, succeeds with changes, fixable with a gas-limit increase and potentially broken.The foundation described the large majority of transactions as falling into the no-change category. Some transactions still succeed but use different gas or show another execution detail changing. Another group runs out of gas at its original limit but completes with a higher one, which makes it fixable through a gas-limit increase rather than a contract rewrite.
The smallest but most sensitive group is potentially broken. According to the foundation, contracts in that category commonly depend on hardcoded gas assumptions, such as Solidity transfer or send stipends, fixed gas values in calls, branches based on gasleft(), or presigned transactions with fixed gas limits. That means the main operational risk is not ordinary contract use, but brittle assumptions embedded in code, frontends or transaction infrastructure.
Contract maintainers have two immediate test paths
The foundation directs L1 contract maintainers to check addresses using its affected-contracts search and to test fixes on the Platåberget testnet, also identified as glam-devnet-8. The search is intended to show distinct failure modes and the specific repricing behind each flagged case.For contracts classified as fixable with a gas-limit increase, the suggested action is straightforward: update the gas limits supplied by frontends, infrastructure or users. That category matters because the original transaction limit may fail even when the execution can succeed under a higher cap.
For contracts marked potentially broken, maintainers are told to review flagged call sites and test changes under the new schedule. Even unlisted contracts are not fully exempt from review if they hardcode gas values or branch on remaining gas. The useful lesson is that absence from a list reduces the signal of risk, but it does not replace code review for gas-sensitive patterns.
Wallets and node tooling must update estimation
The repricing also reaches wallets, RPC infrastructure and node tooling through gas estimation. Ethereum Foundation said eth_estimateGas and related handling need to account for the new cost rules, and cached gas constants could underestimate required gas and lead to failed transactions.That warning is important because many users do not set gas limits manually. They depend on wallets, RPC providers and application infrastructure to estimate transaction requirements. If those systems keep pre-Glamsterdam constants, a contract that would otherwise work may fail because the transaction was submitted with an insufficient limit.
For regular users, the foundation said no action is needed, because updated wallets and infrastructure should handle the changes. That statement is conditional on the ecosystem updating before activation, which is why the developer and infrastructure testing window matters.
Repricing is tied to Ethereum's throughput roadmap
The foundation frames the repricing as a prerequisite for raising the gas limit further without degrading the network for node operators. The new schedule is derived from a performance target that supports roughly a 3x increase in base throughput, according to the post.That does not mean every application immediately becomes faster or cheaper. It means Ethereum core developers are aligning gas accounting with measured resource costs so that future gas limit increases are less likely to shift hidden burdens onto nodes. In practice, some state-heavy operations become more expensive while the network gains a clearer basis for scaling decisions.
The schedule is live on devnets now and is expected to roll out to public testnets before mainnet activation. Ethereum Foundation said direct outreach to the most-affected builders is already underway and that user-impacting changes will be communicated through the blog and community channels.
Conclusion
Glamsterdam's gas repricing is not presented as a broad contract-breaking event, but it is a meaningful compatibility test for teams that depend on fixed gas behavior. The strongest signal from the Ethereum Foundation's replay is that most contracts should be unaffected, while the contracts most at risk share recognizable patterns: hardcoded gas limits, fixed stipends, gasleft() logic and presigned transactions with static limits.Developers have a limited but clear checklist: search for affected addresses, test on Platåberget, update gas limits where that is enough, and remove brittle gas assumptions where it is not. Wallet and infrastructure teams need to refresh estimation logic so users are not exposed to avoidable failed transactions after activation.
Sources
Editorial Team - CoinBotLab