The Ethereum Foundation has urged developers to test smart contracts and update hardcoded gas assumptions before the Glamsterdam upgrade is activated on mainnet. The warning concerns EIP-8037 and EIP-8038, which change the cost of creating and accessing state and could disrupt a small group of Layer 1 contracts. By replaying historical transactions under the proposed rules, developers found that most contracts remain unaffected, while a limited subset could break or experience degraded functionality without updates.
Key finding: Contracts most exposed to compatibility issues include those relying on the 2,300-gas stipend, fixed call gas limits, gasleft()-based logic, and pre-signed transactions with fixed gas limits. Most flagged failures can be resolved simply by increasing the transaction gas limit.
EIP-8037 changes how Ethereum charges for the creation of new state, including new accounts, storage slots and deployed contract bytecode. The proposal introduces separate state-gas accounting designed to prevent uncontrolled blockchain state growth as network throughput increases. It is a preventive measure: without higher costs for persistent state, increases in block gas capacity could cause node databases to expand at an unsustainable rate.
EIP-8038 increases the cost of accessing existing state. The proposal covers operations including SLOAD, SSTORE, cold account access, EXTCODESIZE and EXTCODECOPY. Together, the two proposals form an important part of Glamsterdam's gas repricing policy and complement other changes intended to make long-term state growth sustainable.
The key innovation of EIP-8037 is the separation of execution gas from state gas. Execution gas continues to pay for computation, while state gas covers operations that increase the size of Ethereum's global state, such as creating an account, writing a new storage slot or deploying contract bytecode. Separating the two allows the protocol to adjust the cost of persistent state without directly changing the economics of computation and could provide a foundation for future state-management mechanisms.
For developers, this means the full cost of a transaction can effectively contain separate components, and tooling needs to account for both. Transactions that create large amounts of new state — such as airdrops to new addresses or contract factories deploying many instances — may become noticeably more expensive, while computation-heavy operations that create little state may see less impact. The economic signal is straightforward: computation is temporary, while permanent storage creates a lasting burden on the network.
Ethereum developers replayed historical mainnet transactions using the proposed Glamsterdam gas schedule. The results were divided into four broad categories: transactions whose behavior remained unchanged; successful transactions with different gas consumption; failures that could be fixed by increasing the gas limit; and transactions that appeared potentially incompatible.
The final category continued to fail even after researchers substantially increased the available gas. Recurring risk factors included fixed gas stipends, hardcoded call limits, logic based on gasleft(), and pre-signed transactions created with fixed gas assumptions. The group of potentially affected contracts was described as small, and outreach to some of the most affected teams has already begun.
Contracts relying on Solidity's historical 2,300-gas stipend through transfer or send require particular attention. The mechanism was widely used as a defense against reentrancy because the receiving contract was given only a small amount of gas. Under a new state-access pricing schedule, however, operations that previously fit within that allowance may become more expensive, potentially causing transfers to revert.
The 2,300-gas assumption has already been considered fragile for years. Earlier repricing changes, including those introduced through EIP-1884 and EIP-2929, demonstrated that developers should not assume specific operations will always fit within a fixed stipend. Glamsterdam further reinforces that lesson. Developers maintaining affected contracts should review uses of transfer and send and consider explicit calls with appropriately managed gas behavior where necessary.
The warning extends beyond smart contracts. Wallets, RPC providers, indexers and node-related tooling may need to update their gas-estimation logic. Software relying on cached constants or hardcoded assumptions could underestimate the gas required for certain transactions and cause them to fail. Tooling built around eth_estimateGas and related methods must correctly account for the revised state costs.
One important example involves the familiar assumption that a simple ETH transfer always costs 21,000 gas. Transfers between existing externally owned accounts may continue to fit the traditional model, while operations that create new state can carry additional costs under the revised framework. Ordinary users should generally not need to make manual adjustments, provided their wallets and infrastructure providers update their estimation logic before the fork.
Ethereum developers have launched Platåberget, also known as glam-devnet-8, as a long-running development environment for testing Glamsterdam. The network allows developers to experiment with the proposed gas schedule and identify incompatibilities before the changes reach production.
Contract maintainers can test affected applications and compare their behavior under the new rules. If a failure disappears after increasing the transaction gas limit, the required fix may be relatively straightforward. If it persists, developers need to inspect individual call sites and contract assumptions more closely. Finding these incompatibilities during the devnet and testnet stages is significantly cheaper and safer than discovering them after mainnet activation.
The changes are relevant not only to obscure legacy contracts but also to widely used patterns such as multisig wallets, ERC-4337 paymasters using counterfactual deployment, token factories and NFT minting systems that create large numbers of new storage slots. For many of these applications, the impact is likely to be economic rather than fundamentally breaking: state-heavy operations become more expensive, potentially changing the cost advantage of executing certain workloads directly on Layer 1.
The repricing also reinforces Ethereum's broader rollup-centric architecture. As persistent state becomes more expensive on the base layer, storage-intensive applications have a stronger incentive to move activity to Layer 2 networks, where execution and state can be handled more efficiently while compressed data is ultimately settled through Ethereum. Glamsterdam therefore aligns protocol-level pricing with Ethereum's long-term scaling strategy.
Preparation for Glamsterdam includes long-running development networks such as Platåberget/glam-devnet-8, client testing and audits, public testnet deployments and, eventually, activation on Ethereum mainnet. Gas repricing is expected to arrive as part of the broader network upgrade rather than as an independent switch, making advance compatibility testing especially important for contract maintainers.
The final scope of an Ethereum upgrade can still change during development. EIPs that fail to complete implementation, testing or security review in time can be postponed to a later fork. Ethereum has followed this approach with previous upgrades, reducing or adjusting scope when necessary rather than forcing unfinished changes into a scheduled release.
Contract maintainers should test their applications under the proposed Glamsterdam rules, review uses of transfer, send and gasleft(), identify hardcoded gas limits and replace brittle assumptions where possible. Applications that create significant amounts of state should also evaluate how the new pricing affects their economics.
Wallet developers and RPC providers should update eth_estimateGas models and remove assumptions that specific transaction types will always consume a fixed amount of gas. Cached gas constants should be reviewed throughout the infrastructure stack. Ordinary users are unlikely to need to take action themselves, although outdated wallets or interfaces could temporarily experience failed transactions around the upgrade if their estimation logic has not been updated.
Bottom line: Glamsterdam's gas repricing is intended as preventative maintenance for Ethereum's long-term scalability, but it also acts as a compatibility test for a small group of Layer 1 contracts. Applications still relying on gas assumptions inherited from earlier eras of Ethereum may need updates, while most contracts are expected to pass through the upgrade without noticeable disruption.
The Ethereum ecosystem is approaching the upgrade with extensive preparation, including transaction replay testing, dedicated development networks and direct coordination with potentially affected teams. This process is intended to expose edge cases before they can become mainnet incidents.
“State is one of Ethereum's most expensive long-term resources: data stored permanently imposes costs on the network far beyond the transaction that created it. Repricing is ultimately about making those costs more accurately reflect reality.”
— On Ethereum's long-term state-growth challenge
