Ethereum has canceled a test that was originally scheduled for next Monday. A notice from the Ethereum Foundation on October 22 stated that Glamsterdam would not be activated at 17:42:48 on October 26 at Hoodi; no new epoch has been set yet. Consequently, the increase in the upper limit to 200 million gas has also been removed from the schedule for this test network. This is a postponement of future configurations, and not a revocation of the blocks that have already been recorded in the Hoodi.

Developers made this decision in order to study the interaction between EIP-8037 – a proposal that aims to change the cost of creating new Ethereum states – and contracts on the mainnet. The foundation has not stated that this upgrade has damaged the mainnet, nor has it provided a date for a production environment fork. The immediate operational risk lies with Hoodi: if clients or custom configurations still retain the old activation times, there may be discrepancies with the revised schedule. A deeper issue is how to adjust the cost of internal transaction operations without disrupting applications that have written old values into their code.

The fork on Hoodi October 26th has been removed from the schedule.

On October 16th, the Hoodi announcement specified epoch as 132,352 and slot as 4,235,264, and linked the execution layer's Amsterdam changes with the consensus layer's Gloas changes, as well as a cap of 200 million gas. The new notification completely replaces these instructions. Operators should read the latest release notes for both types of clients; versions previously described as compatible with Glamsterdam may still contain the now-canceled Hoodi activation times.

This is not just a scheduling note. Verifiers must adhere to the same network rules as their peers. If a part of their software is still expecting new execution rules or consensus responsibilities on the old epoch, while the network does not operate in this manner, they may lose the ability to follow the main chain. The infrastructure for builders and verifiers may also have their own configurations. Therefore, the foundation reminds operators to check the revised client versions and clear outdated custom settings before October 26th; it is not safe to assume that doing nothing is the right approach just because of the fork delay.

Sepolia was activated on October 6th along with Glamsterdam, and a limit of 200 million gas was tested. Relevant reports documented this activation. While the successful activation of one test network is certainly of reference value, it does not guarantee that another test network will proceed as smoothly. The remaining drills for Hoodi have been postponed precisely because contract investigations take time. Currently, there is no alternative timestamp available that could be used to infer the date for the mainnet launch.

Glamsterdam was activated on October 6th at Sepolia. Developers tested the upper limit of 200 million gas there. This successful test does not address how EIP-8037 will affect the contracts that are already running on the mainnet. The experiment with Hoodi was postponed while developers investigated these interactions, and no alternative date has been announced yet.

This process has undergone several changes this year. Reports in September regarding the Sepolia plan mentioned issues that arose on the development network before the public testing began, as well as implementation problems with EIP-8037. Those earlier issues did not prove to be caused by the same factors as the contract investigation on October 22nd, but they did illustrate why there were always conditions attached to the timeline as the client team transitioned from private trials to the public network. Other concerns regarding the behavior of the test network builders pertain to another aspect of Glamsterdam and should not be confused with the price re-adjustments. The latest notification provided a specific reason for the suspension of Hoodi: further investigation into the interaction between EIP-8037 and the mainnet contracts.

Why is it proposed to increase the cost of creating a status?

A transaction can perform calculations, as well as leave behind data that the network must retain and access in the future. Creating a new account, opening a new storage slot, or deploying contract bytecode all increase this persistent state. EIP-8037 proposes to charge higher fees for these operations and to measure the cost of state creation separately. The goal is to make the fees more in line with the long-term burden borne by the nodes, especially when blocks are allowed to handle more work.

The example table in this proposal sets the status creation component for new accounts to 183,600 gas, whereas the current value is 25,000; new storage slots are set to 97,920, compared to the current 20,000; and 24KB deployments are set to 37,784,880, while the current value is 4,947,200. This table does not represent a general prediction of the ETH costs that users will ultimately pay. It merely splits a certain component under a proposed constant, with other execution costs to be calculated separately. The final monetary cost will depend on the prevailing gas price at the time. Such a large range of variations also explains why those contracts with tight restrictions deserve more careful examination.

The related status access proposal EIP-8038 will reprice some read and write operations. According to the developer impact guide from the foundation, the last significant cost adjustment for these gas was during the Berlin fork in 2021, and since then, the state size has grown. The planned repricing this time is designed to be synchronized with the work to increase throughput; if blocks are expanded without considering the cost of expensive status operations, it may make it more difficult for node operators to verify them. Therefore, this pause affects both application compatibility and the expansion plan, although the public trigger point is an interaction issue with EIP-8037.

An external call can illustrate why such issues are difficult to detect early on. The caller may intentionally pass in only enough gas to allow the receiver to perform limited actions, assuming that any additional work will fail safely. If the re-priced account or storage access consumes this portion of the quota, the receiver may fail during a regular payment, even though the user has provided sufficient gas for the outer transaction. Adjusting the wallet's estimates will not rewrite the internal quotas. Developers need to check the code paths and failure handling, as some applications may consider an external call failure as a reason to roll back, while others will continue to execute and record different outcomes.

The transfer and send modes within Solidity have historically forwarded subsidies amounting to 2,300 gas. Many teams no longer rely on these subsidies, but the deployed contracts may continue to use them for many years. The foundation has classified such fixed subsidies as a risk category; this does not mean that all calls that utilize these types of subsidies will fail. Recipients with minimal workloads may still remain within the quota, whereas contracts that reach the repricing state may exceed the limits. It is more important to actually test the trading counterparts than to judge whether there will be issues based solely on the function names.

The second type of issue lies in automation. Wallets, relayers, and custodians may set default limits based on gas. Even if an operation has been successful for many years, it may start to fail due to insufficient gas, even though there is no problem with the contract itself. Increasing the front-end estimates can fix this issue, but customers who schedule tasks or use older versions of wallets may continue to submit requests with the old limitations. Therefore, developers not only need to identify the affected code but also the services that construct transactions for it.

Which contracts might run into trouble?

The foundation replayed historical mainnet transactions according to the proposed schedule. Most transactions did not encounter any substantial issues. In the cases that were marked, many were able to be completed after raising the gas limit; however, a small portion could still fail even with a significantly higher gas. Fixed subsidies, hardcoded amounts of gas sent to another contract, or branches based on the results of gasleft () could all potentially change the transaction path. Earlier contract warnings regarding these categories were described before the Hoodi date in October. The current extension makes the unresolved issues more urgent, but it does not mean that all Ethereum contracts are at risk.

Imagine an application that provides a fixed amount of gas when transferring funds to another contract. The receiving contract may require a larger amount of gas under the new rules in order to access storage. If the caller's quota is hardcoded in the deployed code, simply increasing the upper limit for top-level transactions may not provide additional space for that internal call. In such cases, a contract-level fix may be necessary, or users may need to be directed to another method of transfer. On the other hand, if the issue is merely that the wallet estimated the transaction cost using an outdated price, then updating that estimation and raising the provided quota might be sufficient. These two situations require different approaches in terms of implementation.

A particularly unusual issue in EIP-8037 involves code that measures performance by the difference between two remaining gas readings. The proposal explains that under certain circumstances, the state gas reserve can cause gasleft () to rise. The calculation, which was originally expected to be non-negative and decreasing, may therefore behave differently, and the deployed immutable contracts cannot be patched on the spot. The specific impact depends on the code and transaction paths, which is why replaying real historical transactions is more important than a general warning of "higher fees."

The search tool of the foundation allows builders to view the affected contract addresses and the reasons for the marked discrepancies. It is recommended to use a new schedule for testing on devnet. Even if a contract does not appear in the list, those codes with assumed fixed limitations should still be checked. Historical playback is just a screening tool and not a complete list of future behaviors: a path that has not been called by any user in the sample may still contain vulnerable assumptions. The team needs to conduct tests on the branches they actually use.

The playback result also depends on the transaction samples. A contract may contain a fixed amount of gas in a function that is rarely called; if this path is not present in the playback history, the tool will not be able to prove that it will fail. The foundation recommends that maintainers check the code even if a particular address does not appear on the affected list. Large applications may have multiple contracts, upgradable frontends, and automated proxies, and the upper limits of gas provided by each component may vary. Teams need to test operations according to how users actually use them, including possible retention of old estimates in caches or by robots.

For contracts whose behavior may change, simply fixing the interface for submitting transactions is not always sufficient. If the gas quota used in internal calls is compiled into immutable code, the owner may need to migrate to a new contract. Such a migration may involve transferring balances, authorizations, or user permissions, as well as notifying the new address. The difficulty of this migration depends on the product design; there is no evidence to suggest that every marked contract necessarily requires this action. For this reason, it is important for both the team and the customers to be able to distinguish between "failures that can be fixed by increasing the limit" and "contracts that may already be damaged."

Test guidelines are particularly important for applications that use account abstraction or complete a user operation through multiple contract calls. A single checkout may sequentially involve asset authorization, routing and exchange, and merchant settlement. If a hard-coded limit is used in any internal step, customers may encounter payment failures without knowing which contract triggered the restriction. Replaying the entire sequence according to the proposed rules provides more informative results than checking each contract's public methods individually. Maintainers should record the first failed step, as well as whether the larger outer gas limit actually affected the outcome.

A contract may continue to execute even after a call fails, rather than stopping immediately. A fallback might record the event, update the internal balance, or attempt a second approach to continue running under conditions not anticipated by the original author. For this reason, describing the test results as merely 'transaction successful' may be insufficient. The output status and events need to be compared with previous execution results. The foundation categorizes 'execution successful but with changed results' as a separate case precisely to account for this possibility, rather than automatically assuming it to be harmful.

Wallets, RPC, and factories face different tasks.

Wallets and remote procedure call providers will estimate the gas required by the exchange before the user signs. According to EIP-8037, eth_estimateGas and node software must simultaneously take into account both the execution of gas and the new state gas dimensions. Old cache constants may underestimate state-intensive transactions, which could result in transaction failures for users, even though the contract could have run normally within the correctly estimated limits. Therefore, infrastructure updates are part of compatibility, not just a convenient feature above the protocol.

Deterministic deployment of factories is another narrow case. EIP-8037 discusses the initial deployment of pre-signed transactions with hardcoded gas restrictions to standard addresses using these factories. On a brand-new network that adopts new rules but where such factories do not yet exist, old pre-signed deployments may fail due to insufficient gas. The proposal clearly states that instances already deployed on the existing mainnet and layer-two networks are not affected by this specific genesis scenario. It is important to mention this: implying that all factories currently in use on Ethereum will disappear would be misleading to readers.

Constructors also need to distinguish between 'contract unchanged' and 'cost unchanged'. A transaction may be successful, but the amount of gas consumed can vary. Businesses that deploy in bulk or create a large number 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 the way information is stored. This is precisely why the foundation's replay classification distinguishes between 'executed the same', 'executed with changes but successful', 'failures that can be repaired by increasing the limit', and 'contracts that may be damaged'.

The numbers in EIP-8037 need to be further qualified. The example uses an assumed value of 0.08. The gwei base fee will be converted to gas. If the base fee changes, the corresponding ETH expenses for the same gas will also change. Developers, when comparing tables with existing bills, must take into account both the execution fees and the actual transaction conditions, rather than simply stating that the total user payment has increased sevenfold due to a sevenfold increase in status costs. The purpose of this proposal is to price resources; a person's final cost depends on the combination of these resources in the transaction.

The scale of the proposed repricing should be understood in conjunction with the capacity targets. Allowing more transactions within a block may create more space, but if these transactions generate a large amount of persistent state, it could increase the verification costs for the network. EIP-8037 A separate metric is set for this type of growth to prevent the costs from being obscured by larger apparent gas limits. EIP-8038 deals with access to the existing state. They address different aspects of resource issues, and relying solely on a single operational block builder cannot prove that the repricing has been correctly handled by the application.

Ethereum’s block access list has another task as well. It informs clients which accounts and storage locations a block will affect, helping to parallelize part of the verification work. Under favorable conditions, this can lead to higher throughput, but it does not eliminate the persistent storage requirements associated with new accounts and new storage slots. The test network needs to run combined upgrades under real-world conditions, because improvements in one area may expose constraints in another. This delay has temporarily made it impossible to carry out joint exercises on Hoodi.

Many users will first become aware of these changes indirectly through the limits set by wallets (such as gas) or the cost estimates provided by applications. A transaction that does not create a new state may be affected differently from a transaction that deploys a large contract. For a user interface that promises a fixed transaction cost, it is necessary to check whether this promise can still cover the actual operations performed. It is still too early to generalize that all Ethereum fees will change in the same direction without having a final mainnet schedule, observed demand, and final parameters in place.

The number 200 million is just a setting for the test network.

Glamsterdam It's not just about re-pricing. The proposal to separate proposers from builders, which was written into the protocol, has changed the way block payloads are handed over, while the block-level access list helps clients identify the accounts and storage that the blocks will affect. Developers originally planned to test these changes with a limit of 200 million Hoodi gas, in line with Sepolia. This number is merely a test network parameter; there was never any commitment that the Ethereum mainnet would immediately adopt the same limit, nor that user fees would decrease by a fixed percentage.

Remove the gas deadline from Hoodi to keep the various components of the delayed fork together. The operators will not test the higher capacity expected for Glamsterdam on that network next Monday. Developers can still use Sepolia and the specially set up devnet to study the impact of the price revaluation. The lack of Hoodi rehearsals will affect the order in which the client team builds confidence before choosing the mainnet time, but the foundation has not yet announced a revised production schedule.

Economic outcomes are not as simple as the slogan “cheaper gas”. Charging higher fees for creating persistent states may make a certain transaction more expensive at the same gas price. However, if larger security capacities are adopted and utilized in the future, it might alleviate congestion under other conditions. Demand determines how much block space users are willing to bid for, while the final protocol parameters decide which operations will become more or less expensive. Neither a pause nor a successful test can determine these market variables on their own.

Public coordination comes at a cost, but continuing to move forward with known uncertainties could result in even higher costs. The operators have already prepared software for the old epoch, and that agenda must now be removed; application developers also need to continue testing around a proposal whose final form may change. The cost of such a reset is evident. If the mainnet rules lead to the failure of a widely used contract, the consequences will be more difficult to reverse, and the impact may involve funds or applications that depend on it. The notice on October 22 did not quantify this risk, but it clearly indicated that developers considered this interaction important enough to pause the Hoodi exercise.

The revised proposal can retain the goal of "charging for status," while also changing the working method of status reserves or the transition rules for existing contracts. It is also possible to keep the specifications unchanged and require targeted application fixes. This postponement notice does not publicly decide which path to take. Readers should not regard one survey as the final design choice. If there are specific modifications, their importance will outweigh how many days Hoodi needs to wait.

Why do developers choose to wait?

Ethereum's process allows client teams to adjust their plans before the activation of the public test network. The decision made on October 22nd at All Core Devs Execution call 248 followed previous warnings and communications with affected builders. The public notice identified the areas under investigation, but did not disclose the final number of contracts at risk, nor did it announce a new version of EIP-8037, nor provide a deadline for the investigation to conclude. Referring to this delay as merely a routine schedule adjustment ignores the reasons stated for it, as it implies that all deployed contracts were confirmed to have defects, which goes beyond what was announced in the notice.

The old configuration must be retracted at both levels. The client is responsible for processing transactions and maintaining status, while the consensus client coordinates with verifiers and manages the fork schedule. Only when these clients reach an agreement on rules and timing can the network test the upgrade. For operators who installed the relevant version of Hoodi on October 26th, it is necessary to review the revised release notes. The foundation stated that as new client versions are confirmed, they will add links instead of using the original compatibility table as the current version.

The order of evidence also holds revelatory significance. The historical replay has revealed a small portion of the affected groups; the public test network has shown the behavior of clients and applications in a real-world environment; the mainnet, on the other hand, exposes the final rules to large-scale economic use. Each stage has answered questions that could not be answered in the previous stage. The brief pause on Hoodi may have bought time for the contract to function, but it does not in itself prove that the final rules are secure. Whether to proceed further should be based on the test results and clear operational guidelines.

It is necessary to clarify the scope of this operational notice. Ordinary mainnet holders do not need to change their wallets due to the withdrawal of the Hoodi schedule. However, the operators of the Hoodi nodes, who are preparing for the fork, need to review the release notes again. Protocol engineers investigating EIP need to determine whether the contract behaviors observed in the replay are acceptable, can be fixed with tools, or whether the proposal needs to be modified. The application team, on the other hand, needs to test their own implementation paths. These are different groups of people with different deadlines, and a single reminder of an "upgrade delay" cannot provide the correct guidance for everyone.

The next announcement from the foundation may also explain how developers will communicate with the affected teams. The guidelines from August stated that direct contact has already begun, but the number of contacts alone does not prove that a contract has been fixed. Verifiable evidence includes updated contracts for a specific product, revised gas configurations, or recorded backup plans. Some immutable contracts may require users to migrate, which brings another layer of communication and security issues: customers must know where the legitimate alternative addresses are and avoid fraudulent addresses. No large-scale migration has been announced yet, so this remains only an emergency plan for those 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 will be made if the proposal is modified, and which client versions will agree to the new Hoodi and epoch. Application maintainers will need time to run searches for affected contracts, update estimators, raise limits when necessary, and check those hardcoded internal call quotas that may cause issues if not sufficient. If a deployed contract that may be damaged has no direct upgrade path, its team may need to explain how users will switch to an alternative before any mainnet fork.

The public evidence will include the replay method and the updated findings regarding the affected contracts, the results of the devnet process that uses the final gas schedule, an Hoodi activation agreed upon by multiple clients, as well as a separate mainnet announcement. Even if the Hoodi activation is successful, it will only be a drill and not a guarantee for any specific ETH price or final transaction fees. For users, the reality is that there is no announcement of a mainnet launch on October 26th at this time. The current actions are the responsibility of the Hoodi operators, as well as those teams that will make assumptions about the gas.

What needs attention?

• Client release: Clearly removes the execution layer and consensus layer updates from October 26th that involved the old Hoodi activation time.
• EIP-8037 Conclusion: New replay results, proposed changes to the rules, and handling of smart contracts with hardcoded restrictions or gasleft () logic.
• Replace epoch with: Restore the testable configuration of the Hoodi plan with a date after the investigation is completed.
• Application Fix: Reports from affected builders indicate whether a higher upper limit is sufficient, or whether the deployed code requires another path.
• Mainnet Notice: After the coordination of the testnet process and the client is completed, an independent production schedule will be released by the foundation.

Frequently Asked Questions

Will Glamsterdam be activated on October 26th at Hoodi?

No. The Ethereum Foundation has postponed the activation scheduled for October 26th, and no alternative date or time has yet been set for epoch.

Did anything change on the Ethereum mainnet on October 22nd?

No. This notification only changes the schedule for future Hoodi testnets; it does not revoke the existing history of Hoodi, nor does it activate Glamsterdam on the mainnet.

Why has the test been postponed?

According to the foundation, core developers wish to have more time to investigate the interaction between EIP-8037 and the existing mainnet smart contracts.

What is EIP-8037?

It increases and separately measures the gas charged for creating a persistent state, including accounts, storage slots, and deployed code. The exact cost impact depends on the transaction and the price of gas.

Does every smart contract need to be modified?

Not necessary. The foundation stated that the vast majority of contracts in their historical replay were not affected. A few contracts that contain the fixed gas assumption are worth testing directly and may also require fixing in certain cases.

Will the gas upper limit of Hoodi rise to 200 million on October 26?

No. The improvements included in this plan have been removed along with the activation of Glamsterdam on Hoodi.

Hoodi What should the validators' operators do?

Check the updated descriptions for the execution layer, consensus layer, and validator clients. Old software or custom configurations may still retain canceled activation times.

Is there a new mainnet date?

No. After the testing team and the client team reach an agreement on the schedule, a separate production announcement will still need to be issued.