Ethereum Delays October 26 Glamsterdam Test on Hoodi

Hoodi delay removes October 26 upgrade settings

The canceled activation had been scheduled for 17:42:48 UTC at epoch 132,352. The revised configuration removes Amsterdam on the execution layer, Gloas on the consensus layer and the associated 200 million gas-limit schedule. It changes a future upgrade configuration without reversing Hoodi’s transaction history.

For operators, an announcement alone does not change installed software. The Foundation instructs Hoodi teams to check execution and consensus clients before October 26 and follow release notes that explicitly remove the old activation. Validator and builder infrastructure also needs review. An earlier upgrade table is not sufficient confirmation that a release incorporates the postponement.

This changes the next rehearsal after the previously covered Glamsterdam Sepolia rollout plan. A testnet is a separate environment for checking software and operational behavior before deploying changes to the network that holds real assets.

The immediate consequence is therefore operational: teams planning tests around Monday’s transition need a revised schedule. The Foundation says the notice requires no action from mainnet users or ETH holders.

EIP-8037 changes contract gas assumptions

EIP-8037 proposes separate accounting for creating blockchain state, the stored information applications leave behind. Its stated purpose is to constrain database growth while allowing greater processing capacity. Gas measures computational resource use; it is not a fixed dollar fee.

The companion EIP-8038 proposal updates charges for accessing and changing existing state. It separates access costs, write costs and state-creation costs, reflecting the different work a node performs. Together, these changes reach beyond the headline block limit.

The security concern is how applications behave when another contract fails. Some contracts catch that failure and continue, deciding whether to record an error or allow another attempt. A caller deliberately supplying insufficient gas can test the assumptions behind that decision.

In its October 13 technical assessment, ChainSecurity explains that returned gas and changed costs can let a failure handler finish where it previously would have reverted. An operation that should remain retryable could instead become permanently failed, despite unchanged application code.

The firm cautions that this does not invalidate every gas check. Its assessment calls for reviewing complete call paths, fixed budgets and recovery behavior under the proposed rules. Simply changing one numerical threshold does not establish that the surrounding assumptions hold.

That is a different validation problem from demonstrating higher throughput. A network can process more work while changing what a particular application does after a failed call. Capacity measurements and application compatibility answer separate questions.

ChainSecurity’s 13 examples are not a loss tally

In an October 22 public statement, ChainSecurity said it had found 13 real-world examples and was coordinating responsible disclosure with affected projects. The count describes examples identified by researchers, rather than confirmed victims or drained wallets.

As of October 23 at 09:06 UTC, the reviewed primary disclosures did not establish observed thefts, stolen-fund transactions, a victim-wallet total or a dollar loss estimate linked to these gas changes. That is a limit of the available evidence, not proof that every potentially affected application is safe.

The ACDE 248 agenda and discussion placed the EIP-8037 and EIP-8038 concerns alongside Hoodi scheduling. It listed December 1, 8 and 9 as mainnet candidates, with selection conditional on successful Hoodi testing. Candidate dates should not be treated as an approved launch calendar.

Earlier developer support for a 200 million gas target concerned execution capacity. The newly identified compatibility question adds a separate condition to assessing readiness. The evidence now needed is how the proposed rules affect existing applications and which changes address the findings.

For application teams, the distinction between an error message and a recoverable operation is consequential. A failed transfer that can be retried has a different user outcome from a system that permanently records the attempt as finished. Testing must examine the resulting application state, not only whether a transaction executes.

Alternative.me’s Bitcoin-focused sentiment index stood at 50, or Neutral, versus 68 the previous day when checked October 23. It measures broader sentiment rather than Ethereum upgrade readiness.

The next milestones are the impact assessment, revised client guidance and a replacement Hoodi schedule. The timing of mainnet activation and the complete set of affected applications remain unresolved in the reviewed disclosures.