Ethereum's next upgrade, Glamsterdam, is currently undergoing verification on the testnet. However, ChainSecurity has identified that some operational assumptions relied upon by various projects will be disrupted by EIP-8037 and EIP-8038. These two proposals adjust the way gas fees are calculated for certain operations and rework how state access is billed. As a result, all core developers have decided to postpone the hardfork process, preventing Hoodi's testnet from moving on until the issues are resolved. Since the upgrade has not yet been deployed to the mainnet, the team has chosen to pause first in order to identify the affected projects. This is precisely the most valuable, yet often overlooked, security aspect of public blockchains.
Why can problems still occur even though the contract code has not been modified?
Smart contracts rely not only on function inputs and account balances but also on the economic rules of the execution environment. Some contracts assume a maximum amount of gas that can be consumed for a particular operation, or use the remaining gas to determine whether an external call has been completed. After EIP-8037 and EIP-8038 changed the way fees are charged for specific operations and state accesses, the original gas boundaries that were in effect may no longer apply. The code remains unchanged, but the running conditions have changed.
These types of risks are more difficult to detect than syntax errors. Contracts can run continuously on the current network for many years, and audit reports may also draw security conclusions based on old rules. Once the underlying protocol is re-priced, refund processes, liquidations, cross-contract calls, or protection logic that depend on specific gas behaviors may fail. An upgrade does not simply result in "slightly higher or lower fees"; rather, it changes the premises of certain control processes.
The eight invariants are a checklist for troubleshooting, not eight confirmed vulnerabilities.
An article from the Ethereum Foundation mentions a repository that outlines eight invariants that Glamsterdam could potentially violate, along with explanations, examples, and tips for checking projects for such violations. It is important to distinguish between “invariants being altered” and “projects inevitably having vulnerabilities.” Only when contracts or off-chain systems actually rely on these assumptions will they be affected; the consequences can range from transaction failures to more serious security issues.
The significance of making the list public is to allow projects that cannot be individually covered by the core team to self-check. On Ethereum, there are not only mainnet contracts but also proxy contracts, bots, indexing services, wallets, and off-chain risk control mechanisms. Audit companies can cover high-value projects, but it is impossible for them to read all the code. By writing risk conditions as searchable and testable rules, developers can more quickly determine whether they fall within the affected scope.
Postponing Hoodi does not mean that the entire route will be suspended.
Official statement: All core developers have decided to postpone the hard fork process and will not perform a fork on Hoodi until the issues are resolved. Meanwhile, work related to Hegota will not be affected and will continue in parallel. This distinction is very important. What is being postponed is the current testing node of Glamsterdam; it does not mean that Ethereum has stopped development, nor has there been any mainnet incident.
In governance upgrades, delays are often misunderstood by the outside world as a failure to meet deadlines. However, for public networks that cannot be rolled back at will, continuing to push for a deadline after discovering preliminary errors can come at a much higher cost than simply delaying. The purpose of a test network is precisely to allow protocol changes to collide with real-world applications. If testing only verifies whether the client can generate blocks without exposing assumptions at the application layer, then going live on time actually defeats the purpose of the testing.
Auditing is shifting from "looking at code" to "looking at changes".
The foundation stated that it is collaborating with auditing firms such as ChainSecurity and Dedaub and conducting internal audits. However, the article also acknowledges that the team is unable to cover all projects, especially since it is not possible to inspect both on-chain and off-chain code simultaneously. This reveals the reality of protocol upgrade audits: just because a contract passes an audit at the time of deployment does not mean it will be compatible with future underlying rules indefinitely.
The project team needs to establish an impact analysis for upgrades. In addition to tracking the EIP text, key economic assumptions should also be incorporated into the tests to allow the same set of contracts to be replayed on new clients and under new gas meters. For clearing, bridging, and permission paths, it is necessary to test whether funds will be locked or restrictions will be bypassed in case of failure. The audit report should also specify the applicable protocol versions and assumptions, rather than simply assigning an indefinite 'security' label.
What does the user need to do now?
Ordinary users do not need to migrate their assets immediately due to this delay. Glamsterdam is still in the testing phase, and there have been no announcements by the official team of any related failures on the mainnet. Those who truly need to take action are contract developers, auditors, and infrastructure operators: they should check whether the project relies on the eight invariants, verify using public examples and tools, and if any impact is found, they should contact the protocol team. They should also avoid incorporating assumptions into new versions until the repairs are completed.
Exchanges, wallets, and data services cannot simply wait for notifications from the contract teams. Off-chain systems may decide whether to submit transactions based on gas estimates, or they may trigger subsequent actions based on the execution results. Changes in underlying billing mechanisms can lead to batch failures, inaccurate quotes, or misjudgments in monitoring. It is often more cost-effective to test real workloads on a test network in advance than to adjust parameters after the mainnet goes live.
A valuable “brake application” at one time
Glamsterdam This postponement indicates that the security of the protocol upgrade depends not only on whether the proposal itself is correct, but also on the implicit dependencies that the vast ecosystem has developed on the old rules. The earlier risks are identified, the greater the room for correction; if problems are discovered after the mainnet goes live, governance, coordination, and financial losses will all be magnified.
Blockchain emphasizes code certainty, but code always runs within a set of environmental rules. EIP-8037 and EIP-8038 are changing some of these rules, and developers must prove once again that their systems are still viable. Delaying is not ideal, but it is more responsible than bringing unknown risks to the mainnet under the pressure of a deadline. A truly mature upgrade is not about never delaying, but about knowing when it is necessary to stop.
