Ethereum Foundation Flags 8 Invariants That Break Under Glamsterdam

EIP-8037, EIP-8038 and the Gas Split

The smart contract developers and auditors behind Ethereum (ETH) deployments received a direct request from the Ethereum Foundation on November 6: verify how planned specification changes for the network's next major upgrade, Glamsterdam, would affect their projects. To support that check, the Foundation released reference material listing eight invariants, conditions that running code may silently assume, which the proposed changes would invalidate; each entry names the condition, explains why it stops holding, and shows where the assumption appears in practice. The request centers on two Ethereum improvement proposals: EIP-8037 changes the gas cost of creating new state on the chain, and EIP-8038 revises the cost of accessing state that already exists. State covers account information and the data a stored contract holds. On Ethereum, gas fees measure the computational resources a transaction or contract execution consumes. Every operation on the network, from a plain transfer to a nested contract call, spends against this budget. EIP-8037 goes beyond repricing: it introduces a separate metering bucket for gas spent on creating state, distinct from gas spent on ordinary processing, which today draws on one combined allowance. In effect, the upgrade would price two resources that a single number covers today. The changes can therefore alter both how much gas an operation needs and how much gas remains available after an operation fails mid-execution. That second effect is where running code faces risk. The material targets contracts already deployed, where a changed rule lands on live code rather than on a draft. Developers and auditors who find a dependency on any of the eight conditions are asked to contact the Foundation directly. The request landed while the Ethereum (ETH) price slipped 5.1% across the past 24 hours, though the upgrade track, not market direction, drove the outreach.

Security firm ChainSecurity had already traced the danger. A technical analysis it published on October 13 identified several projects that could become vulnerable under the changed specifications, because they assume certain invariants keep holding: conditions a contract needs to stay true to work as written. The concrete failure mode involves external calls, the mechanism composable systems rely on to interact. Today, when a call to an external contract fails for lack of gas, the operation that follows cannot complete, and the transaction as a whole reverts. Under the proposed specifications, the follow-on operation may complete while the failed one stays unretryable, leaving the contract in a condition its author never planned for. The Foundation's new repository records the eight invariants that Glamsterdam would break, pairing each with an explanation, a worked example, and prompts developers can run while reviewing their own projects. The delay of Glamsterdam on the testnet Hoodi is not new: on October 22, the Foundation postponed an activation first set for October 26, citing the need for further study of how EIP-8037 interacts with mainnet contracts. No replacement date exists, and the upgrade stays parked until the open questions clear. The impact review runs with support from ChainSecurity and the audit firm Dedaub, both examining how the changed rules land on existing deployments, alongside the Foundation's internal audit, though the Foundation concedes it cannot survey every project, least of all the off-chain code that pairs with on-chain contracts. A decision belongs to the AllCoreDevs developer call, which first needs an inventory of what would stop working after activation and of the specification options that could prevent it. Until that call produces a verdict, the Foundation stressed, nothing in the specification is decided. Work on Hegota, the upgrade that follows Glamsterdam, continues in parallel and is unaffected.

The AllCoreDevs Checkpoint

The gas split at the heart of EIP-8037 is an accounting change to the virtual machine itself, which explains why the Foundation treats it as a protocol-level risk rather than a routine parameter tweak. For deployers, the eight-invariant repository turns an abstract dispute into a checklist: a team can test its assumptions against eight named conditions instead of waiting on a ruling. The limiting factor is coverage, and the Foundation says so itself, since a full sweep of on-chain and off-chain code is impossible. The next fixed point is the AllCoreDevs meeting, where a decision needs both the breakage inventory and the specification alternatives on the table.