Ethereum Devs Say They Won’t Fork “Glamsterdam” on Hoodi Yet

Ethereum core developers have postponed the Glamsterdam upgrade’s progress on the Hoodi testnet after identifying security concerns related to two specific gas-cost change proposals, EIP-8037 and EIP-8038. In a Friday blog post on the Ethereum Foundation’s site, developers said the delay will remain in place until eight smart contract “invariants” tied to the upgrade’s behavior can be resolved.

The decision matters for developers and anyone tracking Ethereum’s upgrade pipeline because Glamsterdam includes changes to how gas is charged for certain operations. According to the Ethereum Foundation, some existing projects may depend on the idea that particular actions always incur a predictable, fixed gas cost. Those assumptions could break once the new gas rules take effect—especially in scenarios where external calls fail.

Key takeaways

• Ethereum core developers delayed Glamsterdam on the Hoodi testnet due to security concerns tied to eight smart contract invariants.
• EIP-8037 and EIP-8038 change gas charging for certain operations, potentially invalidating smart contracts that assume fixed gas costs.
• ChainSecurity’s Oct. 13 report flagged that the two EIPs could disrupt contracts when external calls fail.
• The Hoodi fork won’t move forward until the issues are resolved, giving teams additional time to assess whether further fixes are needed.

Why the Hoodi testnet upgrade was paused

In its Friday update, the Ethereum Foundation said the Hoodi testnet fork is delayed until developers can address vulnerabilities highlighted by a recent audit process. The underlying trigger is not a broad “upgrade instability” claim, but a narrower concern: how the proposed EIPs might affect the correctness of smart contracts that rely on established gas-cost expectations.

The Foundation specifically pointed to risk around invariants—properties smart contracts expect to remain true under certain execution conditions. In this case, the concerns are linked to how gas is metered for operations covered by EIP-8037 and EIP-8038. If those invariants no longer hold, contracts that were written and tested with older gas accounting assumptions could behave unexpectedly when particular call patterns occur.

How EIP-8037 and EIP-8038 could break assumptions

The Ethereum Foundation’s blog post links the pause to a class of contracts that assume gas usage for specific operations. Some Ethereum applications have historically depended on fixed gas-related calculations, whether for internal accounting, risk controls, or logic that makes execution decisions based on expected gas consumption.

Because Glamsterdam includes changes to gas pricing, those fixed-cost assumptions may no longer match reality once the new rules are active. The Foundation explained that EIP-8037 and EIP-8038 could invalidate those assumptions, particularly “when external calls fail”—a failure mode that can change execution flow and, in turn, alter how gas costs are reflected.

This is the critical nuance: the concern isn’t simply that gas costs change, but that specific contract logic may have been engineered around older behavior. When external calls revert or otherwise fail, the difference between “expected” and “actual” gas charging can cascade into broken invariants.

ChainSecurity’s audit set the sequence in motion

Ethereum’s decision followed an Oct. 13 report from smart contract auditor ChainSecurity. As described by the Foundation, the audit concluded that the two EIPs could “break smart contracts that rely on fixed gas-related assumptions when external calls fail.”

That framing gives developers a concrete target for follow-up work. Instead of treating the upgrade as a black box, teams can focus on identifying which contract patterns are affected, whether the upgrade can be adjusted to preserve the expected properties, and which deployed applications may need warnings or compatibility testing before broader rollout.

The Foundation’s post emphasizes that the additional time on Hoodi is intended to support exactly that: finding potential smart contract issues and determining whether changes are necessary before Glamsterdam moves closer to mainnet deployment.

Glamsterdam has already rehearsed on Sepolia

While the Hoodi fork is paused, the broader Glamsterdam effort is not stalled completely. The upgrade previously reached another milestone when it went live on the Sepolia testnet on Oct. 6, described as one of its final major rehearsals.

In earlier guidance from Sept. 28, the Ethereum Foundation said Glamsterdam is designed to advance Ethereum’s layer-1 scaling roadmap. The upgrade’s stated goals include enshrining proposer-builder separation, adding block-level access lists, and modifying gas pricing so it better reflects the cost of execution.

The new development—delaying Hoodi while issues are resolved—shows how testing and rollout are being handled as a risk-managed process. Sepolia gave teams a rehearsal environment, but Hoodi now becomes the stage where unresolved gas-invariant concerns are treated as blocking items before further progression.

Readers should also watch how the “external call failure” scenario continues to be addressed. In practice, failure cases are where many real-world contracts experience edge conditions, from wallet integrations to cross-contract interactions. If the final fixes alter gas behavior again, developers building on the new rules may need to retest failure-mode paths rather than only validating happy-path execution.

What to watch next before Glamsterdam reaches mainnet

Ethereum’s next step depends on whether the team can resolve the eight invariants and determine if further EIP-level or implementation adjustments are required. For developers, the immediate priority is to reassess any contracts that assume fixed gas costs around affected operations—especially in flows involving external call failures—while the upgrade team continues working through the issues flagged in ChainSecurity’s audit.