EIP-8037 state-gas rules force Ethereum dApps to rewrite billing
A November 6 appeal asks projects to test gas assumptions and report repair options that could shape Glamsterdam’s specifications. Read the full story on CryptoSlateUnderstand the crypto stories that matter and what to watch next. Get The Catalyst in your inbox
Ethereum’s core developers are asking application teams to help decide whether proposed gas changes in the Glamsterdam upgrade need revision, because their own audits cannot cover every project’s contracts and off-chain services.
In a Nov. 6 post on the Ethereum Foundation blog, Marius van der Wijden asked developers and auditors to check eight gas assumptions affected by the proposed upgrade. Security auditors ChainSecurity and Dedaub are investigating alongside internal audits, but the review also needs projects to explain how they could repair affected systems.
The Hoodi testnet’s planned Oct. 26 activation and accompanying 200 million gas-limit increase were postponed on Oct. 22.
The Nov. 6 appeal says the delay continues pending resolution, while the notices leave mainnet activation unset.
The consequences extend from relayers recovering too little of their transaction costs to wallet authorizations becoming reusable after a particular kind of failure. That makes application repairability part of the evidence developers need when weighing changes to the upgrade.
Glamsterdam’s EIP-8037 would raise the cost of creating persistent blockchain data and meter that state growth separately from execution, and EIP-8038 would reprice access and writes to existing state.
The aim is to support higher throughput while controlling the data Ethereum nodes must retain.
The eight-invariant framework separates three price assumptions, covering fixed budgets and reserves, from five accounting assumptions involving gas returns, failure handling, billing and delegation.
A relayer pays to execute a transaction for someone else and may recover that expense by measuring gas before and after the work. The framework’s INV-5 entry explains how the proposed accounting can disrupt that calculation.
Under EIP-8037, a transaction initially funds a separate state-gas reservoir when its gas limit exceeds 16,777,216. State creation draws from that pool first, then execution gas. Solidity’s gasleft() reading excludes the reservoir, so subtracting two readings can miss costs that the relayer actually pays.
If the later reading exceeds the earlier one, checked subtraction reverts, blocking the operation. Unchecked subtraction can wrap into a large number and potentially produce excessive reimbursement, depending on the surrounding arithmetic and payment checks.
Meanwhile, invisible reservoir spending can leave users undercharged and operators covering the shortfall.
The billing guidance suggests agreeing on a user-signed fee using an estimate under the new rules. Where metering remains necessary, clamping the subtraction and capping payment at a signed maximum limits the charge, while reservoir-funded costs remain outside the measurement.
An open specification proposal, PR #12581, would prevent gas readings from increasing. That would address the subtraction problem, but the reservoir’s billing blind spot would remain.