Ethereum market price and chart developers are asking project teams to review smart contracts for compatibility risks in Glamsterdam, while the Hoodi testnet upgrade remains postponed pending further investigation.
In a November 6 Ethereum Foundation update, Marius van der Wijden said testing revealed projects that could become vulnerable because of gas-accounting changes in EIP-8037 and EIP-8038.
Upgrade testing revealed assumptions that contracts must revisit
The Foundation said AllCoreDevs delayed the hardfork process and would not activate Glamsterdam on Hoodi until the issues were resolved. ChainSecurity, Dedaub and internal reviewers are examining affected behavior.
The request focuses on eight invariants, or assumptions that applications expect to remain true. Developers have published explanations and examples to help teams check whether their contracts depend on those assumptions.
The Foundation also said it cannot review every project’s onchain and offchain code. The scope therefore extends beyond the network clients to application developers and auditors familiar with individual systems.
Work on Hegota continues in parallel. The statement identifies compatibility risks before an upgrade; it does not announce a newly confirmed exploit of Ethereum mainnet.
State creation changes affect more than headline fees
EIP-8037 changes how the network charges for creating state. Its design separates aspects of state-gas accounting from ordinary execution-gas accounting, changing how costs move through calls and failures.
EIP-8038 revises state-access pricing. Together, the proposals affect more than the final fee a user pays: they can alter the amount of gas available at a particular point in execution.
A contract may depend on a call failing, a budget being exhausted or a minimum amount of gas remaining. Changing those conditions can alter application behavior even when the contract’s own code has not changed.
The distinction is important for interpreting the delay. A network upgrade can be internally consistent while still requiring applications to reassess assumptions made under earlier rules.
Security research highlights failure handling and gas restoration
ChainSecurity’s technical analysis examines cases where state-gas accounting can restore gas that a contract previously treated as spent. That can change whether a failure handler finishes or reverts.
One example concerns storage created and cleared within the same transaction. Another examines an intermediary reverting after state creation and returning gas to the caller.
The analysis also distinguishes delivering a specified gas budget from guaranteeing that the budget covers every permitted execution path. Repriced operations can make an old limit insufficient, even where the forwarding mechanism still behaves as designed.
These are specific compatibility questions, not evidence that all applications are affected. Teams need to identify the relevant code paths and test their behavior under the proposed rules.
For background on different Ethereum risks, BlockBriefing’s validator slashing guide explains consensus-related penalties. Its article on pending Ethereum transactions addresses user-side execution issues. Neither is interchangeable with a contract compatibility audit.
Testing should include unsuccessful calls and recovery paths, because the reported concerns involve what happens after an operation fails as well as when it succeeds.
The next decision depends on testing results and any changes to the specifications. Affected developers can submit findings to glamsterdam@ethereum.org, the contact identified in the Foundation’s update.
