Ethereum has canceled a planned test scheduled for next Monday. According to a notice from the Ethereum Foundation on October 22, Glamsterdam will not activate on Hoodi at 17:42:48 UTC on October 26, and no new epoch has been set. The accompanying 200 million gas limit increase has also been removed from the testnet schedule. This is a delay of future configurations, not a reversal of any blocks already recorded on Hoodi.
Developers made this decision to study EIP-8037—a proposal to alter the cost of creating new Ethereum state—and its interaction with contracts on mainnet. The Foundation has not indicated that this upgrade has broken the mainnet, nor has it provided a date for a production fork. The immediate operational risk lies with Hoodi: if clients or custom configurations still retain the old activation time, they may diverge from the revised schedule. A deeper issue is how to adjust the internal cost of transactions without disrupting applications that have hardcoded the old values.
The Hoodi fork on October 26 has been removed from the schedule.
The October 16 Hoodi announcement specified epoch 132,352 and slot 4,235,264, linking the execution layer's Amsterdam upgrade with the consensus layer's Gloas upgrade and a 200 million gas limit. The new notice fully supersedes these instructions. Operators should review the latest release notes for both types of clients; versions previously described as compatible with Glamsterdam may still contain the now-canceled Hoodi activation timing.
This is not merely a scheduling footnote. Validators must adhere to the same network rules as their peers. If part of their software still expects new execution rules or consensus duties from the old epoch, while the network does not operate that way, it may lose synchronization with the main chain. Builder and validator infrastructure may also have individual configurations. Therefore, the Foundation urges operators to verify updated client versions and remove outdated custom settings by October 26, rather than assuming inaction is safe due to a fork delay.
Sepolia activated Glamsterdam on October 6 and tested a 200 million gas limit, with related reports documenting this activation. While a successful activation on a testnet is informative, it does not guarantee the same outcome on another testnet. The remaining drills for Hoodi have been postponed precisely because contract investigations require time. No alternative timestamp has been disclosed that could be used to infer a mainnet date.
Glamsterdam was activated on Sepolia on October 6, where developers tested a 200 million gas limit. This successful test does not resolve how EIP-8037 will affect contracts already deployed on mainnet. Hoodi’s exercise has been postponed as developers investigate these interactions, and no alternative date has been announced yet.
This process has changed multiple times this year. Reports in September regarding the Sepolia plan mentioned issues with the development network and implementation problems with EIP-8037 prior to public testing. These earlier issues do not indicate the same cause as the contract investigation on October 22, but they explain why dates have remained conditional as client teams transitioned from private trials to public networks. Other concerns regarding testnet builder behavior relate to another aspect of Glamsterdam and should not be conflated with repricing. The latest notice provides a specific reason for Hoodi’s suspension: further investigation into the interaction between EIP-8037 and mainnet contracts.
Why does the proposal increase the cost of creating a state?
A transaction can perform computations or leave data on the network that must be retained and accessed later. Creating new accounts, opening new storage slots, or deploying contract bytecode all increase this persistent state. EIP-8037 proposes charging higher fees for these operations and metering the state creation portion separately. Its goal is to align pricing more closely with the long-term burden borne by nodes, especially when blocks are allowed to carry more work.
The example table in this proposal sets the gas cost for the new account state creation component at 183,600, compared to the current 25,000; the new storage slot at 97,920, compared to the current 20,000; and 24KB deployment at 37,784,880, compared to the current 4,947,200. This table does not represent a general prediction of the ETH fees users will ultimately pay; it merely breaks down a single component under a proposed constant, with additional execution fees still to be accounted for. The final monetary cost depends on the prevailing gas price at the time. The magnitude of these changes explains why contracts operating under tight constraints warrant closer scrutiny.
The related state access proposal, EIP-8038, would repricing certain read and write operations. According to the Foundation’s developer impact guidelines, gas costs for these operations were last significantly adjusted during the 2021 Berlin fork, and state size has since grown. The planned repricing is designed in tandem with efforts to increase throughput; expanding blocks without accounting for expensive state operations could make it harder for node operators to validate them. Therefore, this pause affects both application compatibility and scaling plans, though its public trigger is an interaction issue with EIP-8037.
An external call can illustrate why such issues are difficult to detect early. The caller may intentionally provide just enough gas to allow the recipient to perform limited actions, assuming any additional work will safely fail. If re-priced account or storage accesses consume this allocated gas, the recipient might fail during a routine payment, even if the user provided sufficient gas for the outer transaction. Adjusting the wallet’s estimation does not rewrite the internal gas limit. Developers must examine code paths and failure handling, as some applications treat external call failures as a reason to revert, while others continue execution and log different outcomes.
Historically, the transfer and send patterns in Solidity forwarded a gas stipend of 2,300. Many teams no longer rely on this stipend, but deployed contracts may continue to use it for years. The foundation lists the fixed stipend as a risk category; it does not state that all calls using this stipend will fail. Receivers with minimal work may still remain within the limit, while contracts that trigger state repricing may exceed it. Testing actual counterparties is more important than assuming issues based solely on function names.
The second category of issues stems from automation. Wallets, relayers, and custodians may store default gas limits for routine tasks. An operation that has succeeded for years may suddenly fail due to insufficient gas, even though the application contract itself is functioning correctly. Raising the frontend estimate can resolve this path, but scheduled tasks or customers using older wallet versions may continue submitting transactions with the outdated limits. Therefore, developers must not only identify the affected code but also locate the services that construct these transactions.
Which contracts might encounter issues?
The foundation replayed historical mainnet transactions according to the proposed schedule. Most transactions did not encounter significant issues. Among the flagged cases, many were successfully completed after increasing the gas limit; a small number may still have failed even with substantially more gas. Fixed subsidies, hard-coded gas amounts sent to another contract, or branches based on gasleft() results could alter transaction outcomes. These categories were previously warned about in contract advisories before Hoodi received its October date. The current extension makes unresolved issues more urgent, but it does not imply that all Ethereum contracts are at risk.
Imagine an application that provides a fixed gas limit when transferring to another contract. Under the new rules, the receiving contract may require more gas to access storage. If the caller’s gas limit is hardcoded into the deployed code, simply increasing the top-level transaction limit may not provide additional gas for that internal call. In such cases, failure may require a contract-level fix or redirecting the user along an alternative path. Conversely, if the issue is merely that the wallet estimated the transaction using outdated prices, updating the estimate and increasing the provided gas limit may be sufficient. These two scenarios are operationally distinct.
A particularly unusual issue in EIP-8037 involves code that measures work by the difference between two remaining gas readings. The proposal explains that state gas refunds can, in certain cases, cause gasleft() to increase. Calculations originally expected to be non-negative and decreasing may therefore behave differently, and already-deployed immutable contracts cannot be patched in place. The specific impact depends on the code and transaction paths, which is why replaying actual historical transactions is more important than general warnings about "higher fees."
The foundation's search tool allows builders to view affected contract addresses and the reasons they were flagged for divergence. It recommends testing with a new schedule on devnet, even if a contract does not appear on the list, to check code that assumes fixed limits. Historical replay is merely a screening tool and not a comprehensive list of future behavior: paths not invoked by users in the sample may still contain fragile assumptions. Teams must test against the branches they actually run.
The replay results also depend on the transaction sample. A contract might contain a fixed gas limit within a function that is rarely called; if this path is not present in the replay history, the tool cannot prove it will fail. The foundation recommends that maintainers inspect the code even if an address does not appear on the affected list. Large applications may have multiple contracts, upgradable frontends, and automated proxies, each of which may have different gas limits. Teams must test operations based on how users actually invoke them, including wallets or bots that may retain cached old estimates.
For contracts with behavior that can change, simply fixing the transaction submission interface is not always sufficient. If the gas limit for internal calls is compiled into immutable code, the owner may need to migrate to a new contract. Such a migration could involve transferring balances, authorizations, or user permissions, and notifying users of the new address. The difficulty depends on the product design; there is no evidence that every flagged contract requires this. Therefore, distinguishing between “failures that can be fixed by increasing the limit” and “contracts that may already be compromised” is crucial for both the team and customers.
Testing guidelines are especially important for applications that use account abstraction or complete a user action through multiple contract calls. A single checkout may sequentially involve asset authorization, routing swaps, and merchant settlement. If an internal step uses a hardcoded limit, customers may see a payment failure without knowing which contract triggered the restriction. Replaying the entire sequence according to the proposed rules provides more insight than examining each contract’s public methods individually. Maintainers should document the first failing step and whether the larger outer gas limit actually changed the outcome.
A contract may continue executing even after a call fails, rather than stopping immediately. A fallback function might log events, update internal balances, or attempt an alternative path, allowing the contract to proceed under conditions the original author did not anticipate. For this reason, describing test outcomes simply as “transaction successful” may be insufficient. The output state and events must be compared against previous execution results. The foundation categorizes “successful execution with changed results” as a distinct case precisely to account for this possibility, rather than automatically assuming it is harmful.
Wallets, RPC, and factories face different tasks.
Wallets and remote procedure call providers estimate the gas required for a transaction before the user signs it. EIP-8037 mandates that both eth_estimateGas and node software must account for both execution gas and the new state gas dimension. Old cached constants may underestimate state-intensive transactions, causing users to encounter transaction failures even though the contract would have executed successfully under a properly estimated gas limit. Therefore, infrastructure updates are part of compatibility, not merely a convenience layer above the protocol.
Deterministic deployment factories represent another narrow case. EIP-8037 discusses factories deployed to standard addresses via presigned transactions with hardcoded gas limits. On a completely new network adopting the new rules but without any existing factories, old presigned deployments might fail due to insufficient gas. The proposal explicitly states that instances already deployed on existing mainnets and layer-2 networks are unaffected by this specific genesis scenario. It is important to mention this: suggesting that all factories already in use on Ethereum would disappear would mislead readers.
Builders must also distinguish between “contract unchanged” and “cost unchanged.” A transaction may succeed but consume a different amount of gas. Businesses that batch deploy or create large numbers of storage slots may face significantly different cost structures, even if no functions fail. Their products may require different fee quotes, revised subsidy policies, or changes to how information is stored. This is precisely why the Foundation’s replay categorization distinguishes between “executed identically,” “executed differently but successfully,” “failures fixable by raising the limit,” and “potentially corrupted contracts.”
The numbers in EIP-8037 require an additional qualifier. The example converts the proposed gas into ETH using a hypothetical base fee of 0.08 gwei. If the base fee changes, the ETH cost for the same amount of gas will also change. Developers comparing the table to existing bills must account for both execution fees and actual transaction conditions, rather than directly stating that a sevenfold increase in state cost equates to a sevenfold increase in total user payment. The goal of this proposal is to price resources; an individual’s final fee depends on the combination of these resources within the transaction.
The scale of the proposed repricing should be understood in conjunction with the capacity target. Allowing more transactions in a block that heavily create persistent state may increase the network’s verification costs. EIP-8037 introduces separate metering for this growth to prevent costs from being obscured by a larger surface gas limit. EIP-8038 addresses access to existing state. They tackle different aspects of resource concerns, and a single working block builder alone cannot prove that an application has correctly handled the repricing.
Ethereum’s access lists have another purpose: they inform clients which accounts and storage locations a block will access, helping to parallelize parts of the verification process. Under favorable conditions, this may increase throughput, but it does not eliminate the persistent storage required for new accounts and new storage slots. Testnets need to run combined upgrades under real-world activity, as improvements in one dimension may reveal constraints in another. This delay temporarily prevents the coordinated drill on Hoodi.
Many users will first perceive these changes indirectly through the gas limit provided by their wallet or the fee estimates from applications. A transaction that does not create new state may be affected differently than one that deploys a large contract. A transaction interface that promises fixed costs must verify whether that promise still covers the actual operations being executed. Without a finalized mainnet schedule, observed demand, and final parameters, it is still too early to broadly claim that all Ethereum fees will move in the same direction.
The number 200 million is only for the testnet configuration.
Glamsterdam is more than just a reprice. The proposer-builder separation written into the protocol changes how block payloads are handed off, and block-level access lists help clients identify which accounts and storage the block will touch. Developers originally planned to test these changes with a 200 million Hoodi gas limit, aligning with Sepolia. This figure was only a testnet parameter and was never intended to imply that Ethereum mainnet would immediately adopt the same limit or that user fees would drop by a fixed percentage.
Remove the Hoodi gas cap schedule to keep the components of the delayed fork together. Operators will not test the anticipated higher capacity of Glamsterdam on this network next Monday. Developers can still use Sepolia and a dedicated devnet to study the impact of repricing. The absence of the Hoodi drill affects the sequence by which client teams build confidence before selecting a mainnet date, but the foundation has not yet released a revised production timeline.
The economic outcomes are not as simple as the slogan "cheaper gas." Charging higher fees for creating persistent state could make a given transaction more expensive at the same gas price. If larger security capacity is adopted and utilized in the future, congestion could be alleviated under other conditions. Demand determines how much block space users bid for, while the final protocol parameters determine which operations become more or less expensive. Neither a pause nor a successful test alone can determine these market variables.
Public coordination comes at a cost, but proceeding with known uncertainties may carry an even higher price. Operators have already prepared software for the old epoch and must now remove that schedule; application developers must continue testing around a proposal whose final form may still change. The cost of this reset is visible. If mainnet rules cause a widely used contract to fail, the consequences will be far harder to reverse and could impact funds or dependent applications. The October 22 notice did not quantify this risk, but it clearly indicated that developers considered this interaction significant enough to pause the Hoodi exercise.
The revised proposal could retain the goal of "charging for state" while changing how state reserves function or the transition rules for existing contracts. Alternatively, the specification could remain unchanged, with targeted application fixes required. This extension notice does not publicly determine which path will be taken. Readers should not treat this investigation as a final design decision. If specific modifications are made, their importance will outweigh how many days Hoodi must wait.
Why developers choose to wait
Ethereum’s process allows client teams to adjust plans prior to activation on public testnets. The decision made at the All Core Devs Execution Call #248 on October 22 built upon prior warnings and communications with affected builders. The public notice identified areas under investigation but did not disclose the final number of at-risk contracts, a revised version of EIP-8037, or a timeline for concluding the investigation. Characterizing this delay as confirmation that all deployed contracts are defective goes beyond the notice’s content; labeling it a routine schedule adjustment ignores the stated reasons.
The old configuration must be withdrawn at both levels. The execution client handles transactions and state, while the consensus client coordinates validators and fork schedules. The network can only test upgrades when these clients are in agreement on rules and timing. Operators of Hoodi who installed the relevant version for October 26 must review the revised release notes. The foundation states that as new client versions are confirmed, it will add links rather than treating the original compatibility table as current.
The order of evidence is also instructive. Historical replay revealed the behavior of a small subset of affected parties; public testnets exposed how clients and applications behave in real-world conditions; and the mainnet exposed the final rules to large-scale economic usage. Each stage answered questions that the previous stage could not. A brief pause on Hoodi may buy time for the contract to work, but it does not, in itself, prove that the final rules are safe. Whether to proceed should be based on test results and clear operational guidance.
The scope of the operational notice should be clearly defined. Ordinary mainnet holders do not need to switch wallets due to the withdrawal of the Hoodi schedule. Hoodi node operators preparing for the fork must revisit the release notes. Protocol engineers investigating the EIP must determine whether the contract behavior observed in the replay is acceptable, fixable via tools, or requires modification of the proposal. Application teams must test their own execution paths. These are distinct audiences with different deadlines; a single “upgrade delayed” notification cannot provide accurate guidance to everyone.
The foundation’s next announcement may also detail how developers will communicate with affected teams. The August guidelines stated that direct outreach has begun, but the number of contacts alone does not prove a contract has been fixed. Verifiable evidence includes an updated contract for a specific product, revised gas configurations, or documented contingency plans. Some immutable contracts may require user migration, introducing another layer of communication and security concerns: users must know the legitimate replacement addresses and avoid fraudulent ones. No large-scale migration has been announced yet, so this remains only an emergency contingency plan for teams whose code cannot be modified in place.
What will happen before the next date?
The revised schedule should specify which EIP-8037 rules will be tested, what changes were made if the proposal was modified, and which client versions will agree on the new Hoodi epoch. Application maintainers need time to run searches for affected contracts, update estimators, raise limits when sufficient, and check hardcoded internal call limits that may fail when insufficient. If a deployed contract potentially affected has no direct upgrade path, its team may need to outline how users will transition to an alternative solution before any mainnet fork.
Public evidence will include the replay method and updated findings of affected contracts, devnet results using the final gas schedule, a Hoodi activation agreed upon by multiple clients, and a separate mainnet announcement. Even if Hoodi is successfully activated, it is merely a drill and not a guarantee of any specific ETH price or final transaction fees. For users, the reality is that no mainnet action on October 26 has been announced. The current actions are the responsibility of Hoodi operators and teams whose applications make assumptions about gas.
What should you pay attention to?
- Client release: Explicitly remove the execution layer and consensus layer updates for the old Hoodi activation time of October 26.
- EIP-8037 Conclusion: New replay results, changes to proposed gas rules, and handling of contracts with hard-coded limits or gasleft() logic.
- Alternative epoch: A dated Hoodi plan to restore testable configurations after the investigation is complete.
- Application fix: Report from affected builders on whether the higher limit is sufficient or if the deployed code requires an alternative path.
- Mainnet Notice: An independent production schedule released by the foundation, following the completion of testnet procedures and client coordination.
Frequently Asked Questions
Will Glamsterdam be activated on Hoodi on October 26?
No. The Ethereum Foundation has postponed the activation of October 26 and has not yet set an alternative epoch or time.
Did the Ethereum mainnet change on October 22?
No. This notice only adjusts the future Hoodi testnet schedule; it does not erase Hoodi’s existing history or activate Glamsterdam on mainnet.
Why was the test postponed?
According to the foundation, core developers want more time to investigate the interactions between EIP-8037 and existing mainnet smart contracts.
What is EIP-8037?
It increases and separately charges gas for creating persistent state, including accounts, storage slots, and deployed code. The exact fee impact depends on the transaction and gas price.
Does every smart contract need to be modified?
No. The foundation stated that the vast majority of contracts in its historical recordings were unaffected. A small number of contracts with fixed gas assumptions warrant direct testing and, in some cases, remediation.
Will Hoodi's gas limit increase to 200 million on October 26?
No. The enhancements in this plan have been removed along with the Glamsterdam activation on Hoodi.
What should the Hoodi validator operator do?
Review the updated execution layer, consensus layer, and validator client instructions. Older software or custom configurations may still retain canceled activation times.
Is there a new mainnet date?
No. After the testing and client teams align on the schedule, a separate production announcement must be issued.