Ethereum Pushes Back Glamsterdam Hoodi Testnet Launch Over Security Risks

Ethereum developers have postponed the Glamsterdam hard fork scheduled for the Hoodi testnet after security researchers flagged potential flaws tied to the upgrade’s gas mechanics. The Ethereum Foundation said the delay is meant to give teams time to examine how specific proposals could affect smart contracts when transactions fail.

The mainnet timeline now depends on the results of that additional testing and review. Developers had been aiming for early December, with the hard fork schedule expected to be finalized after Hoodi runs successfully—an outcome that is now less certain as the testnet rollout is pushed back.

Key takeaways

• The Ethereum Foundation delayed the Glamsterdam hard fork on Hoodi after researchers identified gas-related security risks.
• ChainSecurity warned that EIP-8037 and EIP-8038 could weaken defenses against insufficient gas griefing.
• Gas could be returned to contracts after failed operations under the new rules, potentially changing how existing safeguards behave.
• Some “gas check” assumptions used by wallets, indexers, and estimators have already been flagged as potentially problematic for Glamsterdam.

Why Hoodi’s Glamsterdam delay matters

The Glamsterdam upgrade is designed to modify Ethereum’s gas model, which has direct consequences for how smart contracts execute and how they interpret transaction failure. On Hoodi, developers were preparing to deploy the hard fork on Oct. 26. Instead, the Ethereum Foundation said it would hold off to investigate interactions between certain proposals and contracts already deployed on Ethereum.

That investigation is important for more than just the test environment. Many deployed contracts include logic that assumes particular behavior around gas availability and what happens when an operation fails. If those assumptions no longer hold under the new rules, contract behavior could become unreliable or open to edge-case exploitation.

ChainSecurity’s warning: potential weakness in griefing defenses

On Oct. 13, ChainSecurity published an analysis warning that two Glamsterdam proposals—EIP-8037 and EIP-8038—could weaken safeguards against a known attack pattern described as insufficient gas griefing.

In such attacks, a malicious caller can intentionally provide too little gas for an otherwise legitimate smart contract operation to succeed. The goal is not always to drain funds directly, but to cause the call to fail in ways that disrupt contract state or user workflows.

ChainSecurity’s concern is that Glamsterdam’s proposed gas rules may allow gas to be returned to a contract after an operation fails. In turn, this could interfere with existing security checks that depend on the amount of gas remaining during a transaction.

The company highlighted that safeguards may not all fail equally. According to the analysis, some gas-related protections could still work, but developers would likely need to review their contracts to confirm that their logic properly accounts for the upgrade’s revised gas behavior.

How failed calls could become “state-changing” under the new gas rules

ChainSecurity’s write-up described scenarios where the consequences of failure could be amplified. For example, if safeguards no longer prevent certain actions after a failure, an affected contract might permanently record a failed operation.

In practical terms, the firm noted that a contract could remove a user’s claim or disable a retry option, leaving users unable to complete an operation they previously would have been able to finish under older assumptions.

That distinction—between a call failing cleanly versus failing in a way that still enables harmful state transitions—can be the difference between a recoverable user experience and a locked or degraded outcome. It is exactly the kind of contract-level risk that hard fork testing is meant to surface before upgrades reach mainnet.

ChainSecurity also said it had not concluded that all relevant checks would be unreliable, but it emphasized the need for developers to verify whether their specific contract logic remains aligned with the post-upgrade gas model.

Developers react as additional real-world examples are identified

The risk assessment has already triggered discussion among Ethereum contributors. In an Oct. 21 GitHub comment, pseudonymous security researcher pcaversaccio characterized the issue as “serious” and called for a reassessment of the hard fork.

ChainSecurity later added that it had “identified” 13 real-world examples and said it was coordinating responsible disclosure with affected projects. The company did not publicly detail the examples or name the projects, but it urged developers to check their contracts as soon as possible.

Separately, earlier coverage cited an Ethereum Foundation warning that Glamsterdam’s gas model could break tools that rely on fixed assumptions, including wallets, indexers, and gas estimators. The upgrade also wasn’t expected to arrive on mainnet cold—Glamsterdam had already been activated on Sepolia on Oct. 6—yet Hoodi’s new postponement suggests that testnet performance and security assumptions still require further validation.

Earlier coverage from Cointelegraph noted the Sepolia activation and also reported on the Foundation’s concerns about tool breakage related to the upgrade. In this latest development, the focus has shifted from “tooling assumptions” to “contract safety under failure,” which can be harder to detect without targeted security review.

What comes next for Glamsterdam

With Hoodi now delayed, Ethereum developers will need to confirm how existing contract safeguards behave once the gas rules change as proposed in Glamsterdam. Readers and teams running on Ethereum should watch for updates on the revised Hoodi testing timeline—and, crucially, for any guidance that clarifies which contract patterns are most affected by the potential griefing-related changes.