Ethereum Delays Glamsterdam Fork on Hoodi Testnet Over Contract Risks

Ethereum core developers have delayed the Glamsterdam upgrade's fork on the Hoodi testnet until they resolve security concerns tied to eight smart contract invariants. The Ethereum Foundation confirmed the decision in a Friday blog post, halting one of the final rehearsal steps before the network's next major hard fork moves toward mainnet.

The pause is not cosmetic. At issue are two proposals inside the upgrade, EIP-8037 and EIP-8038, which change how gas is charged for certain operations. Some existing Ethereum projects depend on assumptions that specific operations cost a fixed amount of gas. If those assumptions break, contracts that looked safe yesterday can behave unpredictably tomorrow. The Foundation said the Hoodi fork will not proceed until the issues are resolved.

What triggered the delay?

The decision followed an Oct. 13 report from smart contract auditor ChainSecurity. The audit found that the two Ethereum Improvement Proposals could break smart contracts that rely on fixed gas-related assumptions when external calls fail.

That is a narrow failure mode with wide reach. External calls sit at the heart of DeFi composability, where one contract routinely talks to another. Gas pricing governs how much those interactions cost. Change the pricing model, and legacy contracts that hard-coded their assumptions may no longer function as intended.

Eight invariants — properties that must hold true for the system to behave correctly — are now under investigation by core developers. The delay buys time to identify potential smart contract issues and determine whether changes are needed before Glamsterdam progresses toward mainnet deployment, the Foundation's post explained.

Where does Glamsterdam stand?

The upgrade is not starting from zero. Glamsterdam went live on the Sepolia testnet on Oct. 6, in one of its final major rehearsals, according to the Ethereum Foundation's Sept. 28 blog post.

The upgrade aims to advance Ethereum's layer-1 scaling roadmap through three principal changes:

• Enshrined proposer-builder separation
• Block-level access lists
• Changes to gas pricing that better reflect the cost of execution

Each element carries operational weight. Enshrined proposer-builder separation moves a function currently handled by external middleware directly into the protocol. Block-level access lists let the chain declare, up front, which accounts a transaction will touch. The gas repricing work is exactly where the current trouble lies.

What does this change for developers and protocols?

The practical question for teams building on Ethereum is straightforward: does this delay alter their own upgrade math? For now, the answer is caution. Teams whose contracts assume fixed gas costs for operations affected by EIP-8037 and EIP-8038 now have extra runway to audit their code against the new pricing model before it reaches mainnet. The delay also signals that the Foundation treats contract-level breakage as a gating issue, not a post-launch cleanup task.

The sequencing matters too. Sepolia has already forked. Hoodi has not, and will not until the eight invariants are cleared. That leaves the upgrade in a staged holding pattern — advanced enough to have run on one major testnet, paused before completing the full rehearsal cycle.

Why gas assumptions are the sticking point

Gas is the metering system that prices computation on Ethereum. Contracts deployed years ago encoded their logic against the gas costs that existed at deployment time. EIP-8037 and EIP-8038 adjust how gas is charged for certain operations, which can invalidate those older assumptions — particularly when an external call fails and the contract's fallback logic depends on predictable costs.

ChainSecurity's Oct. 13 report put the problem in writing. The Ethereum Foundation's Friday post turned it into policy: no Hoodi fork until the risks are addressed. Developers now face the task of tracing which live contracts could break, and whether the proposals themselves need revision.

The timeline for resolution remains open. The Foundation's post sets one clear condition — the Hoodi fork proceeds only after the eight invariants are resolved — meaning Glamsterdam's path to a mainnet date now depends on how quickly developers can close out the audit findings and complete the remaining testnet rehearsal.