Ethereum’s Glamsterdam review expands after 13 contract examples flagged
The short answer
Ethereum researchers have begun coordinating AI agents to look for smart-contract problems around the proposed Glamsterdam upgrade, according to Cointelegraph’s latest Hodler’s Digest. The effort follows the postponement of the Hoodi testnet rehearsal and a security review that Cointelegraph says identified 13 real-world contract examples potentially affected by changes to gas accounting. ETH holders should distinguish that testing delay from a confirmed incident affecting their own assets (Cointelegraph’s digest, earlier reporting).
The immediate issue concerns how a contract behaves after another contract call fails. ChainSecurity’s published analysis explains how the proposed rules could leave enough gas for a failure-handling routine to finish, even when existing rules would have stopped it. That difference can matter when recording a failure also removes a user’s ability to retry a legitimate operation. The research concerns proposed behavior and compatibility; it does not establish that every Ethereum application has the problem (ChainSecurity analysis).
For a reader holding ETH on an exchange, the useful question is whether that exchange has announced an operational change for the particular network and account. The opened reports do not establish a deposit suspension, withdrawal suspension or customer action at any named exchange. A testnet review alone cannot supply those missing details. Keep any transfer decision tied to the actual network status shown in the account rather than treating an upgrade headline as a notice from the venue.
Show less
What the new report says about AI coordination
Cointelegraph’s digest attributes the AI effort to Derek Chiang of Ethlabs. In the publication’s account, researchers from Ethlabs and the Ethereum Foundation independently put agents to work scanning contracts. After discovering they were using the same approach, they established a GitHub repository as a message board so the agents could coordinate their work. This is a reported description of the research process, rather than a separately verified tally of contracts scanned or bugs resolved (Cointelegraph).
The same digest says another board has been created to examine EIP-8198, also called Quick Slots, for the subsequent Hegota fork. That is useful context for how researchers are organizing reviews. It does not demonstrate that Glamsterdam’s compatibility questions are closed, or that an agent’s finding has been accepted as a confirmed vulnerability. The opened material provides no complete accounting of findings, dismissals or fixes from the boards ([Cointelegraph](https://cointelegraph.
An agent can help locate a contract worth examining. Determining whether the suspected path is reachable, what funds or permissions it affects, and whether a change fixes it still requires evidence about that contract. Readers evaluating the AI headline should look for those project-specific results. The number of agents or messages would not, by itself, answer whether a particular application is ready for an upgrade.
Why a gas change can affect an unchanged contract
ChainSecurity’s article is dated 13 October 2026 and identifies the specifications it reviewed on that date. Its analysis focuses on EIP-8037, which changes state-creation charging and introduces a separate state-gas reservoir, and EIP-8038, which reprices state access. This date matters: a technical article describes the proposal version it examined, while a proposal can continue to change during review (ChainSecurity).
The official EIP-8037 page describes two gas dimensions: execution gas and state gas. It says users pay for both, while the separate accounting is intended to address state growth and permit higher throughput. It also explicitly labels the repricing as backwards incompatible and says wallet and node software must update gas estimation to accommodate the model. The proposal therefore contains compatibility work as part of its own design, independently of the latest news coverage (EIP-8037).
A failed external call can have more than one explanation. The requested operation may be invalid, or the caller may have supplied too little gas for a valid operation to complete. ChainSecurity calls deliberate underfunding of the latter kind insufficient gas griefing. Trouble arises when the surrounding contract interprets that failure as final, perhaps by marking a claim as used or preventing another attempt. A mechanism intended to keep processing after an error can then make the user’s situation worse (ChainSecurity).
Some contracts try to detect underfunding by checking the gas left after a call. Others rely on the remaining work being too expensive to finish, so the whole operation stops. ChainSecurity explains that the new accounting can change both assumptions. A contract’s source code can stay exactly the same while its execution follows a different path under a different gas schedule. That is the compatibility issue the review needs to resolve (ChainSecurity).
The 97,920-gas example needs its conditions
ChainSecurity gives a specific state-creation example: 64 bytes multiplied by 1,530 gas per byte equals 97,920 state gas for a fresh storage slot. Its table separates that state charge from the execution charge. When the reservoir pays the state component, the amount required from the execution balance can be lower even though the combined price is higher. Quoting only the larger total cost would miss why a previously failing continuation might now succeed (ChainSecurity).
The analysis also describes an immediate refill when state created during a transaction is undone. Under the conditions it lays out, clearing a slot can restore execution gas and let a failure handler continue. The slot must have been zero at the transaction’s start, the relevant state creation must have drawn from the execution balance, and enough execution gas must remain to perform the clearing operation. These are conditions on an example, not a claim that any failed call receives 97,920 gas (ChainSecurity).
Another path involves an intermediary contract that creates state, calls a target and then propagates the target’s failure. ChainSecurity distinguishes a deliberate revert from the intermediary itself running out of gas. That distinction affects whether restored execution gas can return to the original caller. For application teams, testing the entire call chain is therefore more useful than changing one threshold while leaving its assumptions unchecked (ChainSecurity).
The official proposal separately warns that contracts measuring work from the difference between two gas readings can encounter a negative result. It also discusses gas-accounting issues for ERC-4337 bundles. Those sections support a broad compatibility review, but they do not identify a particular retail wallet as broken today. The status of an individual product needs evidence from its implementation and testing (EIP-8037).
What the Hoodi delay establishes
Cointelegraph’s 23 October report says the Hoodi upgrade, originally scheduled for 26 October, was postponed so developers could investigate the interaction between the proposals and deployed contracts. It reports that ChainSecurity had identified 13 real-world examples and was coordinating responsible disclosure. The report says the affected projects were not publicly identified. Readers therefore cannot infer a list of exposed applications from the count alone (Cointelegraph).
The digest describes the Hoodi rehearsal as awaiting further analysis of the fork’s effects. Neither opened Cointelegraph report provides a confirmed replacement date that readers can use as a new timetable. An earlier schedule is historical context, not a deadline that remains valid after a postponement. A later announcement with a specific date would be the relevant update for an upgrade calendar ([Cointelegraph’s digest](https://cointelegraph.
For traders, this leaves a distinction between a network-development milestone and an exchange operation. A testnet date concerns testing; an exchange notice concerns that venue’s service. Check the network label on an ETH deposit or withdrawal request and the status associated with that exact route. If an account displays a maintenance notice, preserve its stated scope and timing rather than expanding it to all ETH services or other networks.
Checks for ETH holders and application users
If you hold ETH without interacting with a smart contract, the cited research does not identify a special transaction you must make to respond to the AI review. Do not infer a migration requirement from the title. The opened material describes compatibility investigation and testnet scheduling, without establishing an account-specific action for an ordinary holder. Keep the source of any claimed required action visible before approving a transfer or wallet request.
If you have a claim, withdrawal request or other pending operation inside an application, look for that application’s own explanation of its upgrade testing. The pertinent questions follow directly from ChainSecurity’s analysis: can a failed call remove the ability to retry, does the application rely on a fixed gas budget, and has its failure handling been tested under the proposed schedule? A generic statement that a team uses AI does not answer those implementation questions (ChainSecurity).
Developers have more concrete work. ChainSecurity recommends tracing calls that continue after failure, examining proxies and intermediary contracts, checking the location of refills relative to gas checks, and forcing subcalls to fail during tests. Its recommended comparison uses the same relevant starting state under both schedules. The objective is to inspect the actual outcome: whether a retry disappears, a claim is removed or an incorrect result becomes permanent (ChainSecurity).
The next useful evidence would be an updated Hoodi schedule, findings accepted and resolved by affected teams, and application-specific test results. The AI coordination report explains how researchers are expanding the search. The official proposal and ChainSecurity analysis explain why that search is necessary. None of the opened sources supplies a complete affected-project roster or proves that every compatibility concern has been fixed.