The October 26 Hoodi test has been pulled, including its planned 200 million gas limit. Developers are examining a repricing proposal against contracts already on mainnet.
Summary
- Ethereum’s developers postponed Glamsterdam’s October 26 Hoodi activation at epoch 132,352, with no replacement date set.
- The delay follows questions about how EIP-8037, which raises the cost of creating chain state, interacts with existing mainnet smart contracts.
- The Amsterdam execution and Gloas consensus activations were both removed from Hoodi’s schedule, along with the planned move to a 200 million gas limit.
- Ethereum’s earlier transaction replay found most contracts unaffected, but flagged a small set relying on fixed gas stipends, hardcoded limits or remaining-gas logic.
- Hoodi operators must check execution and consensus client instructions so their software does not still activate the old fork on October 26.
Ethereum has called off a test that was due to run next Monday. The Ethereum Foundation’s October 22 notice says Glamsterdam will not activate on Hoodi at 17:42:48 UTC on October 26, and no new epoch has been set. The accompanying gas-limit increase to 200 million has been taken off the testnet’s schedule as well. This is a postponement of future configuration, not a reversal of blocks already recorded by Hoodi.
Developers made the decision to investigate how EIP-8037, a change to the price of creating new Ethereum state, interacts with contracts on mainnet. The Foundation has not said the upgrade has broken mainnet. It has not put a date on a production fork either. The immediate operational risk is on Hoodi: clients or custom configurations still carrying the old activation time could disagree with the revised schedule. The deeper question is how to change the cost of work inside a transaction without upsetting applications that embedded the old numbers in code.
Hoodi’s October 26 fork is off the calendar
The October 16 Hoodi announcement specified epoch 132,352 and slot 4,235,264. It paired the execution-layer Amsterdam changes with the consensus-layer Gloas changes and a 200 million gas limit. The new notice supersedes those instructions in full. Operators should read the latest release notes for both types of client; an earlier release described as Glamsterdam-compatible may still contain the now-cancelled Hoodi activation.
That is more than a scheduling footnote. A validator needs to follow the same network rules as its peers. If part of its software expects new execution rules or consensus duties at the old epoch while the network does not, it can lose the ability to follow the canonical chain. Builder and validator infrastructure may have their own configuration. The Foundation therefore tells operators to verify revised client versions and remove stale custom settings before October 26, rather than assume that doing nothing is safe because a fork was delayed.
Sepolia activated Glamsterdam on October 6 and tested a 200 million gas limit, as coverage of that activation recorded. One testnet’s successful activation is useful but not conclusive for another. Hoodi’s remaining rehearsal has been postponed precisely because the contract investigation needs time. There is no published replacement timestamp to extrapolate into a mainnet date.
Glamsterdam activated on Sepolia on October 6, where developers tested a 200 million gas limit. The successful test does not settle how EIP-8037 will affect contracts already running on mainnet. Hoodi’s rehearsal is postponed while developers investigate those interactions, and no replacement date has been announced.
The sequence has changed more than once this year. September reporting on the Sepolia plan described devnet problems and an EIP-8037 implementation issue before the public test proceeded. Those earlier problems are not proof of the same cause as the October 22 contract inquiry. They show why the dates have been conditional as client teams move from private trials to public networks. Separate concerns about builder behavior on testnets concern another part of Glamsterdam and should not be conflated with repricing. The latest notice gives one specific reason for the Hoodi pause: further investigation of EIP-8037’s interaction with mainnet contracts.
Why creating state costs more in the proposal
A transaction can execute calculations and it can leave data that the network must retain and access later. Creating a new account, opening a new storage slot or deploying contract bytecode adds to that persistent state. EIP-8037 proposes charging more for those operations and metering the state-creation part separately. The aim is to put the price closer to the longer-lived burden on nodes, especially if blocks are allowed to carry more work.
The proposal’s illustrative table puts a new account’s state-creation component at 183,600 gas, compared with a current 25,000; a new storage slot at 97,920, compared with 20,000; and a 24 kilobyte deployment at 37,784,880, compared with 4,947,200. The table is not a universal prediction of the ETH fee a user will pay. It isolates a component under a proposed constant, with other execution charges on top, and the final currency cost depends on the gas price at the time. The size of the change explains why contracts with tight limits deserve a closer look.
A related state-access proposal, EIP-8038, reprices some reads and writes. The Foundation’s developer impact guide says these gas costs were last substantially adjusted in the Berlin fork in 2021, while the state has grown. The planned repricing was designed alongside work to raise throughput; making blocks larger without accounting for expensive state operations could make validation harder for node operators. The pause therefore touches both application compatibility and the scaling plan, although its announced trigger is the EIP-8037 interaction.
An external call shows why this can be difficult to notice in advance. A caller may deliberately pass only enough gas for a recipient to perform a limited action, assuming that any further work will fail safely. If a repriced account or storage access now consumes that allowance, the recipient may fail during a routine payment, even though the user supplied plenty of gas to the outer transaction. Changing the wallet’s estimate does not rewrite the internal allowance. Developers need to inspect the code path and the failure handling around it, because some applications regard a failed external call as a reason to revert while others continue and record a different outcome.
The Solidity transfer and send patterns historically forward a 2,300-gas stipend. Many teams have already moved away from relying on that stipend, but deployed contracts can remain in use for years. The Foundation identifies fixed stipends as one risk category; it does not say every call using them will fail. A recipient that performs little work may remain within the allowance, while a contract that touches newly repriced state can exceed it. Testing actual counterparties matters more than treating the mere presence of a function name as proof of breakage.
A second class of problem lies in automation. Wallets, relayers and custodians may store default gas limits for regular tasks. An operation that ran successfully for years could start running out of gas even though the application contract itself is sound. Raising an estimate at the frontend can fix that route, but a scheduled agent or a customer using an older wallet may continue to submit the previous limit. Developers therefore have to identify not only the affected code, but also the services that construct transactions for it.
Which contracts can run into trouble?
The Foundation replayed historical mainnet transactions under the proposed schedule. Most had no meaningful problem. Of the flagged cases, many completed after their gas limit was raised; a smaller group could fail even with substantially more gas. A fixed stipend, a hardcoded amount of gas sent into another contract, or a branch based on the result of gasleft() can change the path a transaction takes. The earlier contract warning described those categories before Hoodi acquired its October date. The current postponement makes the unanswered cases urgent, but it does not show that all Ethereum contracts are vulnerable.
Consider an application that sends funds to another contract while providing a fixed gas allowance. The receiving contract may need more gas under the new schedule to touch storage. If the caller’s allowance is embedded in deployed code, simply raising the top-level transaction limit may not give the receiving call more room. A failure could then require a contract-level fix or a different route for users. By contrast, if the only problem is that a wallet estimated a transaction using old prices, updated estimation and a higher supplied limit may be sufficient. The two cases are operationally distinct.
A particularly unusual EIP-8037 issue involves code that measures work by subtracting two readings of remaining gas. The proposal explains that the state-gas reservoir can make gasleft() rise under some circumstances. A calculation expecting a nonnegative decrease could behave differently, and immutable deployed contracts cannot be patched in place. The precise impact depends on the code and transaction path, which is why a replay of actual historical transactions matters more than a generic warning about higher fees.
The Foundation’s search tool lets builders examine affected contract addresses and the reason for a flagged divergence. It recommends testing on a devnet using the new schedule and inspecting code that assumes fixed limits even when a contract does not appear in the list. A historical replay is a screen, not a full inventory of future behavior: a route that no user called during the sample could still contain a vulnerable assumption. Teams need their own tests for the branches they operate.
The result of a replay also depends on the transaction sample. A contract may contain a fixed gas allowance in a function that has rarely been called; if that route is absent from the replayed history, the tool cannot demonstrate its failure. The Foundation advises maintainers to check code even when its address does not appear in the affected list. A large application may have several contracts, upgradeable frontends and automated agents, each supplying a different gas limit. The team needs to test the operation as its users actually invoke it, including a wallet or bot that may be holding an old estimate in a cache.
For a contract whose behavior changes, fixing the interface that submits transactions is not always enough. If an internal call’s gas allowance was compiled into immutable code, its owner may need a migration to a new contract. Such a migration can involve moving balances, approvals or user permissions, and communicating the new address. The difficulty depends on the product’s design; there is no evidence that every flagged contract requires that work. This is precisely why the distinction between a limit-fixable failure and a potentially broken contract matters to both the team and its customers.
The testing guidance is especially relevant to applications that use account abstraction or multiple contract calls to complete one user action. A checkout may approve an asset, route a swap and settle a merchant in one sequence. If an internal step uses a hardcoded allowance, the customer can see a failed payment without knowing which contract hit the limit. Replaying the whole sequence under the proposed rules is more informative than checking each contract’s public method in isolation. Maintainers should record the first failing step and whether a larger outer gas limit actually changes the outcome.
Contracts can also behave differently after a failed call rather than simply stopping. A fallback that logs an event, credits an internal balance or tries a second route may continue under conditions its original authors never expected. Such divergence is why a test result described only as “transaction succeeded” can be inadequate. The output state and events need comparison with the old execution. The Foundation’s category of successful execution with changes captures this possibility without declaring it automatically harmful.
Wallets, RPCs and factories face different work
Wallets and remote procedure call providers estimate the gas a transaction needs before a user signs. EIP-8037 says eth_estimateGas and node software must account for both execution gas and the new state-gas dimension. An old cached constant can underestimate a state-heavy transaction. Users may then see failed transactions, even if the contract would work with a properly estimated limit. Infrastructure updates are therefore part of compatibility, not merely a convenience layered over the protocol.
Deterministic deployment factories present another narrow case. EIP-8037 discusses factories originally placed at standard addresses using presigned transactions with hardcoded gas limits. On a fresh network that adopts the new schedule before the factory exists, the old presigned deployment could run out of gas. The proposal explicitly says already-deployed instances on existing mainnet and layer 2 networks are not affected by that particular genesis scenario. Reporting the caveat matters: it would be misleading to suggest that every factory already used on Ethereum is about to vanish.
Builders also need to distinguish an unchanged contract from unchanged costs. A transaction may succeed but consume a different amount of gas. A business that batches deployments or creates many storage slots could face a materially different cost structure even when no function fails. Its product may need different fee quotations, a revised subsidy policy or a change in how it stores information. The Foundation’s replay categories separate identical execution, changed but successful execution, limit-fixable failures and potentially broken contracts for just that reason.
The numbers in EIP-8037 deserve another qualification. Its example converts proposed gas to ETH using an assumed base fee of 0.08 gwei. If the base fee changes, the ETH paid for the same gas changes too. A developer comparing the table with an existing bill must add execution charges and the actual transaction conditions, rather than present a sevenfold state-cost change as a sevenfold increase in a user’s complete payment. The proposal’s purpose is to assign costs to resources; a person’s final fee depends on the mix of those resources in the transaction.
The scale of proposed repricing should be read alongside the capacity objective. More room for transactions in a block can make the network expensive to validate if those transactions disproportionately create persistent state. EIP-8037 assigns a separate meter to that growth so the cost does not disappear inside a larger headline gas limit. EIP-8038 addresses accesses to existing state. They solve different parts of the resource question, and a working block builder alone cannot establish that applications handle the repricing correctly.
Ethereum’s block access lists have a separate task. They tell clients which accounts and storage locations a block touches, helping organize some validation work in parallel. That may allow greater throughput under favorable conditions, but it does not erase the persistent storage added by new accounts and slots. A testnet needs to run the combined upgrade under realistic activity because an improvement in one dimension can expose a constraint in another. The postponement leaves that combined Hoodi exercise undone for now.
Many users will first encounter these changes indirectly, through their wallet’s quoted gas limit or an application’s fee estimate. A transaction that creates no new state may see a different effect from one deploying a sizable contract. A trading interface that promises a fixed transaction cost would need to check whether its promise still covers the operations it performs. Generalizations about all Ethereum fees moving in one direction would be premature without a final mainnet schedule, observed demand and the final parameters.
The 200 million figure was a testnet setting
Glamsterdam combines more than repricing. Enshrined proposer-builder separation changes the handoff of a block payload, while block-level access lists help clients identify the accounts and storage a block will touch. Developers planned to test those changes with a 200 million Hoodi gas limit, matching Sepolia. The figure was a testnet parameter. It was never a promise that Ethereum mainnet would immediately adopt the same limit or that user fees would fall by a certain percentage.
Removing the Hoodi gas-limit schedule keeps the postponed fork’s components together. Operators will not be testing the intended higher capacity under Glamsterdam on that network next Monday. Developers can still use Sepolia and purpose-built devnets to investigate the effects of repricing. The missing Hoodi rehearsal affects the sequence in which client teams can gain confidence before choosing a mainnet time, but the Foundation has not published a revised production timetable.
The economics are less straightforward than a slogan about cheaper gas. Charging more for creating durable state can make a particular transaction costlier at the same gas price. A larger safe capacity, if later adopted and used, could ease congestion in other conditions. Demand determines how much block space users bid for, and the final protocol settings determine which operations become more or less expensive. Neither the pause nor a successful test would settle those market variables by itself.
Public coordination has costs, but proceeding with a known uncertainty can have greater ones. Operators prepared software for the old epoch and now must remove that schedule; application developers have to keep testing against a proposal whose final shape may change. The cost of that reset is visible. A mainnet rule that caused a widely used contract to fail would be harder to reverse, and the fallout could involve funds or dependent applications. The October 22 notice does not quantify such a risk, but it makes clear that developers regarded the interaction as important enough to halt the Hoodi rehearsal.
A revised proposal could preserve the objective of charging for state while changing the way the gas reservoir works or the transition rules for existing contracts. It could instead keep the specification and require targeted application fixes. No public decision between those routes appears in the postponement notice. Readers should resist treating an investigation as a final design choice. The precise amendments, if any, will matter more than how many days Hoodi waits.
Why developers chose to wait
Ethereum’s process lets client teams adjust a plan before a public testnet activation. The October 22 decision at All Core Devs Execution call 248 follows earlier warnings and outreach to affected builders. The public notice identifies the area under investigation but does not publish a final count of contracts at risk, a new version of EIP-8037, or a date on which the inquiry will end. Calling the delay a confirmed flaw in all deployed contracts would go beyond the release; calling it a routine calendar shuffle would miss its stated cause.
The old configuration has to be withdrawn across both layers. Execution clients process transactions and state, while consensus clients coordinate validators and the fork schedule. A network can only test the upgrade if those clients agree on the rules and timing. Hoodi operators who installed releases specifically for October 26 must look for the revised release notes. The Foundation says it will add links to new client versions as they are confirmed, rather than treating its original compatibility table as current.
There is also a lesson in the order of evidence. Replaying history revealed a small affected group; public testnets reveal client and application behavior in a live setting; mainnet exposes the final rules to economic use at scale. Each stage answers something the preceding one cannot. A short delay on Hoodi may buy time for the contract work, but it does not itself prove the eventual rules are safe. The decision to proceed should follow test results and clear operator instructions.
The scope of the operator notice is worth spelling out. An ordinary mainnet holder does not need to change a wallet because Hoodi’s schedule was withdrawn. A Hoodi node operator who prepared for the fork does need to revisit release notes. A protocol engineer investigating the EIP needs to determine whether the contract behavior found in replays is acceptable, fixable by tooling, or a reason to alter the proposal. An application team needs to test its own execution routes. Those are different audiences with different deadlines, and a single “upgrade delayed” alert does not give each of them the right instruction.
The next Foundation post can also resolve how developers will communicate with affected teams. Its August guide said direct outreach had begun, but an outreach count alone would not establish that a contract was repaired. The testable evidence is an updated contract, revised gas configuration or documented fallback for a particular product. Some immutable contracts may require a user migration, which raises a separate communication and security concern: customers must know where a legitimate replacement lives and avoid fraudulent addresses. No mass migration has been announced, so this remains a contingency for teams whose code cannot be changed in place.
What comes before another date
A revised schedule should say which EIP-8037 rules will be tested, what changed if the proposal is amended, and which client versions agree on the new Hoodi epoch. Application maintainers need time to run affected-contract searches, update estimators, raise limits where that is sufficient and examine hardcoded internal call allowances where it is not. If a potentially broken deployed contract has no direct upgrade path, its team may need to explain how users will reach a replacement before any mainnet fork.
Public evidence would include the replay methodology and updated affected-contract findings, results from devnets with the final gas schedule, a Hoodi activation with diverse clients in agreement, and a separate mainnet announcement. Even a clean Hoodi activation would be a rehearsal, not a guarantee of a specific ETH price or final transaction fee. The practical story for users is that no October 26 mainnet action has been announced. The immediate action belongs to Hoodi operators and teams whose applications make assumptions about gas.
What to watch
- Client releases: Execution and consensus updates that explicitly remove the old October 26 Hoodi activation.
- EIP-8037 findings: New replay results, changes to the proposed gas rules and the treatment of contracts with hardcoded limits or gasleft() logic.
- A replacement epoch: A dated Hoodi plan that restores a testable configuration after the investigation.
- Application fixes: Reports from affected builders explaining whether higher limits suffice or deployed code needs another route.
- Mainnet notice: A distinct production schedule from the Foundation after the testnet sequence and client coordination.
FAQ
Is Glamsterdam activating on Hoodi October 26?
No. The Ethereum Foundation postponed the October 26 activation and has not set a replacement epoch or time.
Did Ethereum mainnet change on October 22?
No. The notice changes a future Hoodi testnet schedule. It does not revert Hoodi’s existing history or activate Glamsterdam on mainnet.
Why was the test delayed?
Core developers want more time to investigate EIP-8037’s interaction with existing mainnet smart contracts, according to the Foundation.
What is EIP-8037?
It raises and separately meters gas charged for creating persistent state, including accounts, storage slots and deployed code. Its exact fee impact varies by transaction and gas price.
Does every smart contract need a change?
No. The Foundation says the large majority in its historical replay were unaffected. A small set with fixed gas assumptions deserves direct testing and, in some cases, a fix.
Will Hoodi’s gas limit rise to 200 million on October 26?
No. The scheduled increase was removed along with both parts of the Glamsterdam activation on Hoodi.
What should a Hoodi validator operator do?
Check updated execution, consensus and validator-client instructions. Old software or custom configurations may still carry the cancelled activation time.
Is there a new mainnet date?
No. A separate production announcement will be needed after testing and client teams agree on the schedule.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of October 23, 2026.
