Ethereum Developers Ask dApp Teams to Test Eight Gas Assumptions Under Glamsterdam Changes

Ethereum's core developers have asked application teams and auditors to check whether gas changes proposed for the Glamsterdam upgrade would break their contracts. They say internal reviews cannot reach every project's code and off-chain systems.

The request, published on the Ethereum Foundation blog on 6 November by developer Marius van der Wijden, lists eight gas-related assumptions that the upgrade could invalidate. It asks builders to say not only whether they are affected but how they would fix any damage.

A testnet delay and an open call for evidence

The appeal follows a pause in the upgrade's rollout. Activation on the Hoodi testnet had been planned for 26 October, alongside an increase in the gas limit to 200 million. Both were postponed on 22 October.

According to CryptoSlate, the 6 November post says the delay will continue until the open questions are resolved. No date has been set for mainnet activation.

Security firms ChainSecurity and Dedaub are investigating alongside the developers' own audits. The blog post makes clear that this coverage has limits. Thousands of deployed contracts and the services built around them encode their own expectations about gas, and only the teams that wrote them can fully judge the impact.

This makes repairability part of the decision. If affected applications can be patched cheaply, the proposals may proceed largely intact. If fixes prove difficult or impossible for important systems, developers may need to revise the specifications.

What EIP-8037 and EIP-8038 would change

Two proposals sit at the centre of the review. EIP-8037 would make it more expensive to create persistent data on the blockchain and would meter that state growth separately from ordinary execution. EIP-8038 would reprice operations that read from or write to existing state.

The broader aim is to let Ethereum process more activity without letting the data that nodes must store grow unchecked. State growth is a long-running concern for the network. Every new account or storage slot adds to the burden on node operators, and raising throughput without pricing that burden properly could make running a node harder over time.

Separating state costs from execution costs is a structural change, however. Gas has historically been a single pool that contracts could measure and reason about directly. Splitting it introduces new accounting that existing code was not written to expect.

The eight invariants

The framework published with the appeal divides the eight assumptions into two groups. Three concern prices: contracts that rely on fixed gas budgets or hold back a set reserve of gas for later steps. If the cost of certain operations rises, those hard-coded figures may no longer be enough.

The other five concern accounting. They cover how gas is refunded, how failures are handled, how fees are billed and how delegation works. CryptoSlate reported that the possible consequences range from relayers recovering too little of what they spend to wallet authorisations becoming reusable after a specific type of failure.

The second category is the more subtle. Price changes tend to cause visible failures, such as transactions running out of gas. Accounting changes can leave a system working while it quietly charges the wrong amounts.

How relayer billing could break

The clearest example in the framework, labelled INV-5, concerns relayers. These services pay to submit transactions on behalf of users, then recoup the expense. A common way to calculate the charge is to read the remaining gas before and after the work and bill the difference.

Under EIP-8037, a transaction with a gas limit above 16,777,216 would first put gas into a separate state-gas reservoir. Operations that create state draw on that reservoir before touching ordinary execution gas. Solidity's gasleft() function, which contracts use to read remaining gas, does not include the reservoir.

The result is a blind spot. Subtracting one gasleft() reading from another can miss state costs that the relayer has in fact paid. The source gives an illustration using the proposed price of a single cold storage write that changes a zero value to a non-zero one: 12,100 gas for execution plus 97,920 gas for state, totalling 110,020.

If the reservoir holds at least 97,920 gas at that point, only the 12,100 execution component appears in the gasleft() difference. If the reservoir is empty, the full 110,020 comes out of the execution balance and is visible. Partly funded reservoirs split the charge between the two. The same operation can therefore look very different to the billing logic depending on the reservoir's state.

There is a second problem. In some cases the later gas reading could be higher than the earlier one. With checked arithmetic, the subtraction would revert and block the operation. With unchecked arithmetic, the result could wrap around to a very large number and, depending on the surrounding code and payment checks, potentially trigger an excessive reimbursement.

Where reservoir spending stays invisible, the effect runs the other way: users are undercharged and operators absorb the difference.

Suggested fixes and their limits

The guidance offers several mitigations. The preferred route is for the user to sign an agreed fee in advance, based on an estimate calculated under the new rules, removing reliance on in-transaction metering.

Where metering cannot be avoided, teams are advised to clamp the subtraction so it cannot underflow and to cap any payment at a maximum the user has signed. This limits the downside, but costs paid from the reservoir would still fall outside the measurement.

An open specification change, PR #12581, would stop gas readings from ever increasing during execution. That would remove the subtraction hazard. It would not, however, make reservoir spending visible to gasleft(), so the underlying billing gap would remain.

That distinction illustrates why developers want application-level feedback. A protocol tweak can close some failure modes, but others may only be solvable in each project's own code, and the cost of those fixes bears on whether the design is acceptable.

What to watch

The timetable for Glamsterdam now depends partly on how quickly the ecosystem responds. Key points to follow include:

• Findings from ChainSecurity, Dedaub and the internal audits
• Responses from relayer, wallet and account-abstraction teams on how readily they can adapt
• Whether PR #12581 or other specification changes are adopted
• A new date for Hoodi testnet activation and the 200 million gas-limit rise

For now, the episode highlights the trade-off facing Ethereum as it tries to scale. Pricing state growth more accurately supports the network's long-term health, but changing how gas is counted touches assumptions buried deep in applications. Developers appear to be treating the question of who can repair what as a factor in the final design rather than an afterthought.