Ethereum Glamsterdam Delay Exposes State Gas Risks

Ethereum developers have postponed the Glamsterdam upgrade on the Hoodi testnet after identifying compatibility questions involving new gas-accounting rules and smart contracts already operating on Ethereum mainnet.

The upgrade was scheduled to activate on October 26, 2026, at 17:42:48 UTC. But on October 22, the Ethereum Foundation announced that core developers had withdrawn the activation schedule to investigate interactions involving EIP-8037, a proposal that changes how Ethereum charges for creating permanent blockchain state.

No replacement date has been announced.

The decision also removes a planned increase in Hoodi’s block gas limit to 200 million, a significant capacity test associated with Glamsterdam’s broader scaling objectives.

Importantly, Ethereum mainnet has not undergone the Glamsterdam upgrade, and the postponement does not mean that Ethereum’s existing blockchain was rolled back or compromised.

The immediate issue concerns whether changes intended to make Ethereum more scalable could also change how existing smart contracts execute.

Researchers have already demonstrated that revised gas accounting can affect certain contract failure-handling mechanisms. In some cases, a contract that previously ran out of gas and reverted could behave differently after the upgrade.

That is not proof that a particular live Ethereum protocol has been exploited.

It is, however, a meaningful backward-compatibility concern.

Glamsterdam is intended to help Ethereum process more activity without imposing excessive hardware requirements on node operators. Its technical changes include new block-production architecture, parallel execution support, and revised pricing for blockchain resource consumption.

But Ethereum’s enormous collection of existing smart contracts creates a difficult constraint.

A protocol upgrade cannot be evaluated only by whether its new features work. Developers must also determine whether old financial contracts continue behaving safely under the new rules.

The Hoodi postponement illustrates that challenge.

Key Takeaways

• Ethereum postponed Glamsterdam’s October 26 activation on Hoodi. Core developers made the decision during All Core Devs Execution call #248 on October 22, 2026.
• EIP-8037 is the stated reason for further investigation. The proposal increases and separately meters the gas charged for creating permanent blockchain state.
• The planned 200-million gas-limit increase on Hoodi was also withdrawn. That capacity target should not be described as an increase already activated on Ethereum mainnet.
• Sepolia activated Glamsterdam on October 6. The later Hoodi postponement does not mean that Sepolia’s earlier activation was reversed.
• Some existing smart contracts may behave differently under the new gas model. Risks include fixed gas assumptions, out-of-gas handling, and unexpected changes in the gas available after failed calls.
• Most existing contracts are not expected to break. Earlier Ethereum Foundation transaction-replay research found that the large majority of transactions were unaffected and many identified issues could be addressed by increasing gas limits.
• Hoodi node and validator operators must follow the revised client instructions. Software still configured for the canceled activation can become incompatible with the updated testnet schedule.
• Ordinary ETH holders do not need to take action. The postponement concerns testnet deployment; no Glamsterdam mainnet activation date has been set.

What Happened to Ethereum’s Glamsterdam Upgrade?

On October 16, the Ethereum Foundation published instructions for activating Glamsterdam on Hoodi.

The scheduled activation was:

• Date: October 26, 2026
• Time: 17:42:48 UTC
• Epoch: 132,352
• Slot: 4,235,264
• Additional change: Raise Hoodi’s gas limit toward 200 million

Hoodi was intended to provide another public testing environment following Glamsterdam’s activation on Sepolia earlier in the month.

The schedule would have introduced both parts of the upgrade.

Amsterdam covers Ethereum’s execution-layer changes.

Gloas covers the corresponding consensus-layer changes.

Together, they form Glamsterdam.

However, core developers withdrew that schedule during All Core Devs Execution call #248.

The Ethereum Foundation explained that the postponement would allow additional investigation of how EIP-8037 interacts with contracts already deployed on mainnet.

The updated Hoodi configuration no longer specifies the October 26 activation.

It also removes the scheduled gas-limit increase.

What exactly was canceled?

The decision removes a future activation configuration.

It does not remove transactions from the existing blockchain.

It does not reverse blocks already produced on Hoodi.

It does not affect finalized Ethereum mainnet transactions.

The distinction matters because the term rollback is sometimes used loosely in blockchain reporting.

A network can roll back a planned configuration without rolling back its transaction history.

In this case, developers withdrew the instructions telling client software when to begin enforcing the new protocol rules.

Timeline of the postponement

Ethereum Glamsterdam: Testing and Postponement Timeline

Date	Development	Significance
August 24, 2026	Ethereum Foundation publishes contract-impact research	Historical transaction replay identifies potential gas-compatibility problems
October 6, 2026	Glamsterdam activates on Sepolia	Provides an earlier public testnet deployment
October 13, 2026	ChainSecurity publishes gas-failure analysis	Documents scenarios where new gas behavior could change contract failure handling
October 16, 2026	Hoodi activation announced	Schedules October 26 activation and a 200-million gas-limit target
October 22, 2026	Developers postpone Hoodi activation	Withdraws the scheduled fork pending EIP-8037 compatibility investigation
October 26, 2026	Original activation date passes	No Glamsterdam activation occurs under the withdrawn Hoodi schedule
October 28, 2026	Replacement date remains unannounced	Mainnet activation timing also remains unconfirmed

The timeline shows that compatibility testing began before the October 22 postponement.

The decision was not an unexpected discovery that Ethereum had already failed on mainnet.

It was a decision to investigate known classes of risk before proceeding with another public network activation.

Is Glamsterdam Still Live on Sepolia?

Yes.

Glamsterdam activated on Sepolia on October 6, 2026.

The later Hoodi postponement did not reverse that activation.

Different Ethereum testnets can operate under different configurations while developers prepare a protocol upgrade.

That allows teams to test specific features, evaluate client behavior, and investigate issues before mainnet deployment.

A successful activation on one testnet is useful evidence.

It does not prove that every smart contract or infrastructure provider will behave correctly under all possible conditions.

Why Hoodi matters

Hoodi is another public testing environment used to prepare Ethereum upgrades.

It provides an opportunity for node operators, validators, staking infrastructure, and application developers to test compatibility before mainnet activation.

The planned October 26 deployment would have expanded testing under the Glamsterdam rules.

Postponing that deployment gives developers additional time to evaluate the identified risks without imposing the same upgrade on another test network immediately.

Where Glamsterdam Stands as of October 28, 2026

Network or Change	Confirmed Status	What It Means
Sepolia	Glamsterdam activated October 6	Earlier testing continues under its network configuration
Hoodi	October 26 activation postponed	New activation epoch, timestamp and operator instructions required
Ethereum mainnet	Glamsterdam not activated	Existing mainnet rules continue to apply
200M Hoodi gas limit	Scheduled increase withdrawn	Not an active result of the postponed Hoodi upgrade
Glamsterdam mainnet date	Not confirmed	Depends on subsequent development, testing and scheduling

This distinction also matters for anyone following Ethereum’s roadmap.

A previous schedule may remain visible in older documentation, event calendars, or third-party monitoring services.

The Ethereum Foundation’s October 22 postponement supersedes the original Hoodi activation instructions.

The previously announced date is no longer valid.

Why EIP-8037 Is Delaying the Upgrade

EIP-8037 is called State Creation Gas Cost Increase.

Its purpose is to change how Ethereum prices operations that create permanent blockchain state.

Ethereum maintains a continuously changing database containing account information, smart-contract code, storage values, and other state needed to execute transactions.

That database grows when users create new accounts, deploy contracts, and write previously unused storage locations.

As Ethereum increases its transaction capacity, it can also increase the rate at which permanent state accumulates.

That creates additional work for nodes.

More state means greater storage requirements and potentially more demanding database operations.

EIP-8037 attempts to address that problem by charging for new state more consistently.

Why Ethereum wants to change state pricing

The proposal’s technical analysis estimates that the state database used by a Geth node was approximately 390 GiB in January 2026.

It also reports that average daily state creation increased substantially after Ethereum raised its block gas limit from 30 million to 60 million.

The concern is not simply that transactions consume more computation.

It is that some transactions create data the network must continue maintaining long afterward.

If Ethereum increases throughput without adequately pricing that persistent resource consumption, the long-term cost of running nodes can rise sharply.

EIP-8037 is intended to support scaling while limiting unnecessary pressure on node infrastructure.

The new gas model is more complicated

Historically, Ethereum applications have primarily worked with one execution-gas budget.

EIP-8037 introduces separate accounting for execution gas and state gas.

Execution gas reflects the computational work associated with transaction processing.

State gas reflects the creation of permanent blockchain state.

A transaction still has a gas limit and a fee obligation.

But internally, the protocol can account for different categories of resource consumption.

This design helps Ethereum charge more appropriately for new accounts, contract code, and storage.

It also changes assumptions that existing software may have relied on for years.

Why the change affects more than transaction fees

A common interpretation of EIP-8037 is that some Ethereum operations will become more expensive.

That is true.

But it does not fully explain the current compatibility concern.

Smart contracts can inspect how much gas remains during execution.

They can forward specified amounts of gas to other contracts.

They can attempt an operation, catch a failure, and decide whether to continue or revert.

These behaviors can influence financial outcomes.

Changing gas accounting can therefore affect not only the cost of executing a contract but also which branch of its logic executes successfully.

That is a much more sensitive question.

Our earlier investigation, Ethereum’s 21,000 Gas Rule Is About to Break, explains the numerical changes to account creation, storage, and transaction gas.

The new concern involves what happens when those changes interact with established contract behavior.

How a Gas Change Can Alter Smart-Contract Logic

Ethereum smart contracts execute instructions according to defined rules.

Each operation consumes resources.

If execution exhausts its available gas, the relevant operation can fail.

Developers sometimes depend on those failure conditions.

For example, a contract may call another contract and check whether the operation succeeded.

If it fails, the calling contract might attempt to record the failure, return an error, or cancel the broader transaction.

This creates assumptions about how much gas remains after an unsuccessful call.

Glamsterdam can change those assumptions.

Example: a failed external payment

Imagine a financial contract processing a batch of payments.

It attempts to send funds to a recipient contract.

The recipient fails to complete its operation because it runs out of gas.

The calling contract now needs to decide what happens next.

One design might require the entire transaction to revert if the recipient could not execute successfully.

Another design might record a failed payment and allow other transfers to continue.

Both approaches can be valid depending on the application.

The danger arises when developers assume that the amount of gas remaining after the failed call will always indicate whether it is safe to continue.

Why gasleft() matters

Solidity provides gasleft(), which reports the execution gas remaining in the current context.

Some contracts use it to estimate whether enough gas remains to perform another action.

Others use it as part of their defense against insufficient-gas attacks.

But the new state-gas model introduces another resource-accounting mechanism.

A transaction may have execution gas and a separate state-gas reservoir.

The amount reported through gasleft() does not necessarily describe all available state-gas capacity.

That creates cases where old assumptions about gas availability are no longer reliable.

What ChainSecurity found

On October 13, blockchain security firm ChainSecurity published research examining how EIP-8037 and EIP-8038 could affect contracts that handle failed calls.

Its analysis demonstrated several possible changes.

A contract may have enough state-gas capacity to complete a storage operation even when its remaining execution gas would previously have been insufficient.

The system can also restore certain gas capacity when state creation is undone.

These behaviors are intentional features of the proposed accounting model.

However, they can interact unexpectedly with existing application logic.

In particular, a failure handler that previously ran out of gas and caused a transaction to revert may now have enough gas to complete.

That can change the contract’s observable behavior even though its source code has not changed.

Why that could become a security concern

Consider a contract designed to retry a payment if the initial attempt fails because too little gas was provided.

If the contract incorrectly records the failed payment as permanently unsuccessful, the recipient may lose an opportunity to receive funds.

Alternatively, an accounting system might progress to the next operation even though the previous operation did not complete as intended.

The exact consequence depends on the contract.

The important issue is that some financial applications rely on failure behavior to preserve accounting and authorization guarantees.

If a protocol change alters those failure conditions, developers must determine whether their original security assumptions still hold.

This is a demonstrated class of compatibility risk, not confirmation that an exploitable mainnet vulnerability has already caused losses.

What Is the State-Gas Reservoir?

The state-gas reservoir is part of EIP-8037’s proposed multidimensional metering model.

It allows state-creation costs to be accounted for separately from ordinary execution.

Under the current proposal, a transaction’s gas budget can be divided between execution gas and a state-gas reservoir.

State-creation operations draw from the relevant available capacity according to the protocol rules.

If a transaction undoes certain state creation, the accounting can restore previously consumed state-gas capacity.

That behavior is important because removing newly created state can mean the transaction no longer contributes the same permanent database growth.

From a resource-accounting perspective, the mechanism is understandable.

But contracts written for the previous gas model may assume that gas spent earlier in execution remains unavailable.

How gas restoration changes failure handling

Suppose a contract creates a new storage slot.

Later, it clears that same slot before the transaction finishes.

Under the proposed rules, some state-gas capacity associated with that creation can be restored.

Depending on the call structure and prior charges, that restoration can affect the execution gas available for subsequent instructions.

A contract might therefore complete an error-handling operation that would previously have failed.

For certain applications, that is harmless.

For others, it can change whether a record is written, an operation is retried, or a transaction reverts.

The concern is not that gas has somehow created extra ETH or bypassed Ethereum’s authorization rules.

It is that existing contract logic may react differently when the underlying resource-accounting rules change.

Why developers cannot simply increase the gas limit

Some compatibility failures have straightforward fixes.

If a transaction now requires more gas, increasing its limit may allow it to succeed.

But other failures involve control flow.

A contract may contain hardcoded conditions based on gasleft().

It may intentionally forward a limited gas stipend.

It may assume an error handler cannot complete after another operation has exhausted its budget.

Increasing the outer transaction’s gas limit does not necessarily correct those assumptions.

The contract may need a logic change.

For immutable deployed contracts, changing that logic may not be possible without some separate migration arrangement.

That is why the current investigation deserves attention.

Ethereum Had Already Found Compatibility Issues

The October postponement builds on research published before the Hoodi activation was scheduled.

On August 24, the Ethereum Foundation published an analysis of how Glamsterdam’s repricing changes affected historical mainnet transactions.

Researchers replayed transaction activity under the proposed new rules and compared the results.

They identified four practical categories.

Some transactions behaved identically.

Others still succeeded but had different gas consumption or execution details.

Some failed at their original gas limits but succeeded when those limits were increased.

A smaller group showed potentially incompatible behavior even after significantly increasing the gas limit.

Why this research is important

The large majority of transactions were unaffected.

That provides useful reassurance about the overall scope of the changes.

However, the remaining cases matter because Ethereum hosts financial contracts that can hold substantial assets.

A relatively small number of affected contracts may still be important if they are widely used or support critical infrastructure.

The Foundation’s analysis also identified particularly relevant patterns, including fixed gas stipends, hardcoded gas limits, and logic that branches according to remaining gas.

Those findings are consistent with the broader compatibility questions now being investigated.

Four categories of risk

Smart-Contract Compatibility Risks Under Glamsterdam

Risk	What Can Change	Possible Outcome	Developer Response
Hardcoded transaction gas	A call needs more gas after repricing	Transaction failure or incorrect estimation	Recalculate gas and test with new execution rules
Fixed call stipend	A recipient needs more than its forwarded gas allowance	Previously successful operation may fail	Review external calls and fixed-gas assumptions
gasleft() checks	Remaining execution gas no longer reflects all state-gas capacity	Failure-detection logic can give a different result	Test post-call checks under the reservoir model
State-gas refill	Undoing state creation can restore usable gas during execution	A failure handler may complete when it previously reverted	Review state writes, nested calls and error paths
Account-abstraction bundling	Bundlers estimate multiple operations under the changed model	Incorrect gas attribution or transaction failure	Update bundler accounting and validation
Legacy deployment factory	Presigned deployment transaction has a fixed gas budget	Deployment can fail on a newly configured network	Test deployment procedures under Glamsterdam pricing

These are risk categories, not a confirmed list of exploited contracts.

The distinction between potentially affected and actually exploited is essential.

A compatibility issue may result only in higher fees or failed transactions.

Another may require a contract upgrade.

A more serious case could undermine security assumptions if the contract handles failures incorrectly.

The actual impact must be established through testing.

EIP-8038 Adds Another Layer of Complexity

EIP-8037 is the stated focus of the postponement.

However, it operates alongside EIP-8038.

The two proposals address different parts of Ethereum’s resource model.

EIP-8037 increases and separately meters the creation of permanent state.

EIP-8038 revises the gas charged for accessing and modifying existing state.

This matters because a smart contract rarely performs only one isolated operation.

It may read an account, check storage, create new state, call another contract, and update records.

Those operations interact.

Changing the cost of one instruction can affect how much gas remains for everything afterward.

Why old gas assumptions become fragile

Ethereum’s state-access pricing was last substantially adjusted during the Berlin upgrade in 2021.

The network’s state database has grown considerably since then.

EIP-8038 attempts to align access costs with the resource demands of the larger network.

But a contract written years earlier may rely on the previous pricing.

For example, a developer might forward a fixed amount of gas to another contract, assuming it will be enough for a limited operation.

After repricing, the same operation may require more gas.

The call can fail despite being logically valid.

That may be resolved by increasing the forwarded amount.

But if the contract also contains failure-handling assumptions, the consequences can be more complicated.

This is why developers should test EIP-8037 and EIP-8038 together rather than evaluating each proposal only through its individual fee changes.

Why the 200-Million Gas Limit Was Postponed

The Hoodi activation was scheduled to coincide with a large increase in the network’s preferred block gas limit.

The planned target was 200 million gas.

That number is important because it reflects Ethereum’s ambition to significantly expand Layer 1 execution capacity.

But a higher gas limit does not mean Ethereum can simply process more transactions without consequences.

What a block gas limit represents

Ethereum blocks are constrained by rules determining how much work can be included.

Gas accounting helps measure and price that work.

A higher block gas limit can permit more execution activity.

That can support greater throughput.

However, more activity can also increase the burden on nodes.

Nodes must process transactions, access state, verify blocks, and maintain the data needed to participate in the network.

If capacity rises too quickly, those requirements can become more demanding.

Why resource repricing and capacity are connected

EIP-8037 is designed partly to make a larger execution capacity sustainable.

If state creation is too cheap, increasing the gas limit can allow persistent state to grow too rapidly.

EIP-8038 addresses the separate problem of how much work state access requires.

Block-level access lists and other Glamsterdam features aim to make execution and validation more efficient.

Together, these changes could support greater capacity without creating an unsustainable burden on node operators.

But that strategy depends on the new rules working safely.

The postponement demonstrates why Ethereum cannot treat higher throughput as independent of compatibility testing.

The 200-million figure is not a hard mainnet announcement

The canceled Hoodi schedule involved a gas-limit recommendation coordinated through the consensus-layer configuration.

Under the relevant proposal, this schedule provides a default preference and recommended limit for operators.

It is not simply a new universal consensus rule declaring every block above 200 million gas invalid.

Nor does its appearance in a testnet schedule establish that Ethereum mainnet has already adopted that capacity.

The correct interpretation is that the planned Hoodi test was withdrawn alongside the Glamsterdam activation.

Our coverage of Ethereum Layer 2 growth and scaling pressure provides broader context for why the network continues seeking additional execution capacity.

Glamsterdam Includes More Than Gas Repricing

Glamsterdam is not a single EIP.

It combines multiple execution-layer and consensus-layer changes.

Two of its most important architectural components are enshrined proposer-builder separation and block-level access lists.

Enshrined proposer-builder separation

EIP-7732 introduces proposer-builder separation directly into Ethereum’s protocol.

Block proposers and block builders already perform related but distinct functions in Ethereum’s broader infrastructure.

The proposal aims to formalize that relationship within consensus rules.

Builders would commit to execution payloads, with the protocol coordinating how those payloads are revealed and validated.

The objective includes reducing reliance on trusted middleware and improving the time available for block validation.

This is a consensus-layer change.

It is separate from EIP-8037’s state-creation gas model.

However, both were part of the postponed Hoodi activation schedule.

Block-level access lists

EIP-7928 introduces information about accounts and storage locations accessed during a block.

These access lists are intended to support more efficient state loading and parallel processing.

They can help clients identify which portions of state will be needed during execution.

That becomes increasingly useful as Ethereum pursues higher throughput.

Parallel processing can reduce certain execution bottlenecks.

But it also requires careful handling of dependencies between transactions.

The presence of these improvements does not eliminate the need for correct gas accounting.

Why developers postponed the package together

The planned Hoodi fork combined execution and consensus changes at one coordinated activation point.

Withdrawing the schedule therefore affected both Amsterdam and Gloas.

That does not establish that every included EIP is defective.

The Foundation identified the interaction of EIP-8037 with mainnet contracts as the reason for further investigation.

The other changes remain part of the broader upgrade package unless developers subsequently decide otherwise.

What Should Ethereum Developers Do?

The Foundation’s earlier compatibility research already provides practical guidance.

Developers should test contracts against the proposed repricing rules before assuming that existing behavior will remain unchanged.

The most useful work involves identifying assumptions that depend on the old gas schedule.

Review hardcoded gas values

A contract or application may use fixed gas amounts for external calls.

These values can become inadequate when previously inexpensive operations are repriced.

Developers should identify those assumptions and determine whether they remain appropriate.

Test failure-handling paths

Successful transactions are only part of the analysis.

Developers should also test what happens when external calls fail.

Particular attention should go to logic that checks gasleft(), records failures, retries operations, or deliberately reverts when insufficient gas remains.

These paths may receive less routine testing than successful execution.

Yet they can be critical for financial safety.

Examine account-abstraction infrastructure

Account-abstraction systems and bundlers may process multiple operations within one transaction.

Their accounting can depend on the amount of gas consumed by individual operations.

EIP-8037’s separate state-gas model creates additional complexity for allocating costs correctly.

Bundlers and related infrastructure should be tested against the new rules.

Update gas-estimation systems

Wallets and RPC providers need compatible transaction simulation and gas estimation.

An application relying on hardcoded limits may reject an otherwise valid operation or submit a transaction that fails.

The Ethereum Foundation recommends using its affected-contract search tools and testing against development networks supporting the proposed repricing.

The important objective is to find problems before ordinary users encounter them.

What Should Hoodi Validators and Node Operators Do?

The October 22 postponement creates a more immediate operational task for Hoodi participants.

Node and validator software must reflect the withdrawn activation schedule.

A client that still expects the old Glamsterdam fork at epoch 132,352 can become incompatible with software following the revised Hoodi configuration.

Both client layers matter

Ethereum’s architecture separates execution and consensus clients.

Execution clients process transactions and Ethereum Virtual Machine state.

Consensus clients manage proof-of-stake duties and coordination.

Validators also use validator-client software for their assigned duties.

The Foundation advises operators to check the relevant client team’s release notes and ensure their software explicitly incorporates the postponement.

The previously published activation release tables are not sufficient evidence that a particular version supports the new schedule.

Builder infrastructure also needs attention

Glamsterdam introduces changes relevant to block builders and validators.

Operators using external block-building systems should follow the instructions provided by their software and infrastructure providers.

Custom configurations are particularly important.

A manually specified fork time or gas-limit schedule may remain in an operator’s environment even after official configurations change.

That can create avoidable incompatibility.

Glamsterdam Delay: Required Actions by Participant

Participant	Recommended Action	What to Avoid
Ordinary ETH holder	No action required because of the Hoodi postponement	Avoid fake upgrade or wallet-migration requests
Hoodi node operator	Use a client release that explicitly removes the old activation	Do not rely on superseded release tables
Hoodi validator	Review beacon node, validator client and related tooling	Keep execution and consensus configurations aligned
Smart-contract developer	Test sensitive contract paths against new repricing rules	Prioritize fixed stipends, gasleft() and nested failures
Wallet or RPC provider	Update gas estimation and transaction-validation assumptions	Avoid hardcoded limits and stale client configurations
Block builder	Review revised fork schedules and builder interfaces	Do not activate obsolete Hoodi rules

These instructions apply primarily to people operating or developing infrastructure.

Ordinary mainnet users are not being asked to install special Glamsterdam software or move ETH.

Does the Delay Affect ETH Holders or Stakers?

For ordinary ETH holders, the immediate impact is limited.

The Ethereum Foundation explicitly states that no action is required from mainnet users as a result of the Hoodi postponement.

That includes people simply holding ETH in a wallet.

They do not need to move their funds to a new address.

They do not need to exchange ETH for another token.

They do not need to connect their wallets to an upgrade website.

They do not need to approve a special migration transaction.

What about staking?

The immediate operational requirements concern participants running Hoodi validators or related infrastructure.

Someone staking ETH on Ethereum mainnet is not automatically required to change their staking arrangement because Hoodi’s testnet schedule was withdrawn.

However, professional staking providers and validator operators need to monitor upcoming client requirements as the mainnet upgrade progresses.

Glamsterdam includes consensus-layer changes that will eventually require compatible infrastructure.

The postponement delays a testing milestone rather than eliminating the need for future preparation.

For a wider view of Ethereum’s validator economics and decentralization considerations, see our analysis of Ethereum’s staking and issuance debate.

Beware of fake upgrade instructions

Major cryptocurrency upgrades can attract phishing attempts.

A message claiming that ETH holders must urgently verify a wallet or migrate assets because Glamsterdam was postponed should be treated skeptically.

The official notice says no mainnet user action is required.

An unsolicited website requesting a seed phrase, private key, or wallet signature is not a legitimate requirement created by the postponement.

Does the Delay Mean Ethereum’s Scaling Roadmap Is Failing?

Not necessarily.

A postponed testnet activation is evidence that developers have identified an issue requiring further review.

It is not proof that the upgrade’s overall design has failed.

It also does not guarantee that the remaining work will be completed quickly.

Both interpretations would go beyond the available evidence.

The importance of public testing

Large blockchain networks cannot rely exclusively on theoretical specifications.

They need implementation testing across different clients, contract behaviors, and operational environments.

A technically sound proposal can have unexpected interactions with code deployed years earlier.

Those interactions may not appear in simple performance benchmarks.

Transaction replay, targeted testing, public testnets, and independent security research can reveal problems before mainnet activation.

From that perspective, postponing deployment can be a responsible response to uncertainty.

Why the delay still matters

Testing delays have real consequences.

Developers may need to revise project schedules.

Node operators may need to update software more than once.

Applications preparing for new gas rules may need to maintain compatibility with multiple environments.

Mainnet planning becomes less predictable.

The upgrade’s benefits also remain unavailable until a safe deployment is completed.

The appropriate assessment is therefore balanced.

The postponement is evidence that Ethereum’s deployment process identified a reason to stop and investigate.

It is also evidence that Glamsterdam’s compatibility requirements are demanding enough to affect the schedule.

Neither fact should be ignored.

TrendCrypt Research Notes

Ethereum’s Glamsterdam delay illustrates a challenge that becomes more important as blockchains mature.

A new network can change its technical rules while relatively few applications depend on its previous behavior.

Ethereum faces a different environment.

Years of smart contracts, financial applications, development tools, and infrastructure have accumulated assumptions about how the Ethereum Virtual Machine operates.

Those assumptions can be just as important as the formal protocol specification.

1. Backward compatibility is becoming an economic security requirement

A smart contract may be immutable after deployment.

Its developer cannot necessarily change it when Ethereum introduces new execution rules.

That creates a responsibility for protocol developers to evaluate how changes interact with previously deployed applications.

TrendCrypt’s assessment is that backward compatibility should be considered part of Ethereum’s financial security model.

A change that is logically sound at the protocol level can still create economic risk if existing contracts interpret its execution behavior incorrectly.

The relevant question is not only whether upgraded nodes agree on the correct state.

It is whether established financial applications continue enforcing their intended rules.

2. The most dangerous gas changes may not involve higher fees

The most visible part of EIP-8037 involves larger state-creation charges.

But higher fees are relatively straightforward for users and developers to understand.

Unexpected execution behavior is more complicated.

A contract that previously reverted may now continue.

An error handler may receive different gas capacity.

A security check based on remaining gas may no longer behave as its developer expected.

Those changes can affect financial logic without altering the contract’s source code.

We consider these control-flow implications more important than a simple comparison of old and new gas prices.

3. The state-gas reservoir creates a new testing requirement

Separate execution and state-gas accounting is a significant architectural change.

It is intended to help Ethereum price different resources more accurately.

But it also introduces interactions between transaction-level accounting and nested contract calls.

Developers who previously treated gasleft() as a simple indicator of all remaining transaction capacity may need to reconsider that assumption.

Testing must therefore include cases where gas is consumed, restored, and forwarded between calls.

Ordinary successful transactions may not expose these problems.

Failure conditions often provide more revealing evidence.

4. A large majority of unaffected transactions does not make the remaining risks irrelevant

Ethereum Foundation research found that most historical transactions did not experience material compatibility problems under the proposed repricing.

That is positive.

But the importance of a contract is not measured solely by how many transactions it executes.

A contract responsible for substantial collateral or critical settlement infrastructure can be economically important even if it accounts for a small share of transaction volume.

We therefore consider both frequency and consequence relevant when prioritizing compatibility testing.

A rare failure mode involving high-value assets may deserve more attention than a common but harmless change in gas consumption.

5. Testnet postponements can improve security while increasing coordination costs

Withdrawing Hoodi’s activation provides time for additional investigation.

But it also means client teams, validators, and developers must update their plans.

Different environments may temporarily operate under different protocol configurations.

That increases coordination requirements.

The quality of communication becomes important.

Superseded activation instructions must be clearly identified.

Operators need reliable release notes.

Infrastructure providers must avoid activating old fork schedules.

A safe technical decision still requires effective operational execution.

6. Ethereum’s scaling strategy depends on sustainable node requirements

The proposed 200-million gas target is part of a broader effort to increase Layer 1 capacity.

But scaling is not only about processing more transactions.

It is also about ensuring that nodes can continue validating the network without unreasonable hardware costs.

EIP-8037 and EIP-8038 attempt to align gas prices with resource consumption.

Block-level access lists aim to improve execution efficiency.

These changes address different parts of the same objective.

Increasing capacity without adequate safeguards could make the network harder to operate independently.

The postponement reinforces the need to evaluate performance improvements alongside the costs imposed on the network.

7. Security research before activation is different from an exploited vulnerability

ChainSecurity documented technically meaningful scenarios involving gas restoration and failure handling.

That research deserves attention.

But a demonstrated possibility under a proposed execution model is not evidence that attackers have already stolen assets from mainnet contracts through the same mechanism.

The distinction matters for accurate reporting.

The correct conclusion is that certain contract patterns require further review.

Whether a particular production application is exploitable depends on its code, transaction paths, controls, and the final implementation.

Presenting every possible incompatibility as an active exploit would misinform readers.

8. The long-term cost may be accumulated technical assumptions

Ethereum has evolved through years of protocol upgrades.

Developers have built software around the behavior available at each stage.

Some assumptions are explicit in code.

Others are embedded in library defaults, deployment scripts, infrastructure configuration, and application testing.

Changing protocol behavior can expose those assumptions.

The Glamsterdam postponement shows how technical debt can accumulate even when individual applications appear to operate correctly.

Future upgrades may need stronger tools for identifying and testing these dependencies before activation.

9. Transparent postponements can be a sign of mature governance

The Ethereum Foundation publicly identified the postponed activation, the affected components, the technical area requiring investigation, and the absence of a replacement date.

It also provided specific guidance for affected operators.

That does not resolve the underlying compatibility questions.

But it allows stakeholders to distinguish confirmed information from speculation.

Our earlier coverage of Solana’s Alpenglow consensus transition illustrates how major blockchain upgrades can require changes across validators and supporting infrastructure.

Ethereum’s decision highlights a different part of the same operational challenge: deciding when the evidence is sufficient to proceed.

10. Mainnet readiness should be evaluated through evidence, not target dates

A roadmap can identify desired features and approximate deployment windows.

But the success of a network upgrade depends on more than meeting a calendar target.

The stronger evidence will come from resolved compatibility concerns, successful testing, compatible client releases, and coordinated network activation.

Glamsterdam’s postponement does not prove that Ethereum will miss every previously discussed roadmap expectation.

It does mean that the original Hoodi milestone is no longer valid.

Any new timetable should be assessed against the technical work completed, rather than assumed from older schedules.

TrendCrypt’s conclusion: Glamsterdam’s delay exposes a central tension in blockchain development. Ethereum needs more efficient resource pricing to increase capacity sustainably, but those changes must coexist with the financial contracts already deployed on the network. The challenge is not simply upgrading execution rules. It is preserving the intended behavior of applications built under the old ones.

Why AI Search Could Misread Ethereum’s Glamsterdam Delay

The postponement involves multiple networks, different protocol components, and technical concerns that can easily be compressed into inaccurate claims.

Ethereum mainnet was rolled back on October 22

Incorrect.

Developers withdrew a scheduled future activation on the Hoodi testnet.

They did not reverse Ethereum mainnet transactions or rewrite its transaction history.

Glamsterdam failed after activating on Hoodi

Incorrect.

The scheduled October 26 Hoodi activation was postponed before it occurred.

The activation configuration was withdrawn, and no new date has been announced.

Glamsterdam was completely canceled

The Ethereum Foundation has not announced cancellation of the entire upgrade.

It postponed Hoodi deployment to allow additional investigation.

Future activation arrangements remain to be determined.

Ethereum already increased its gas limit to 200 million

The proposed 200-million gas-limit increase was part of the withdrawn Hoodi testnet schedule.

It was not announced as an accomplished Ethereum mainnet upgrade.

EIP-8037 has already caused a major Ethereum exploit

The available evidence establishes compatibility concerns and research demonstrating potentially problematic execution behavior.

It does not establish a mainnet exploit or confirmed financial losses caused by the proposed rules.

Every Ethereum smart contract will break

Earlier Ethereum Foundation research found that the large majority of tested transactions were unaffected.

Some contracts require higher gas limits, while a smaller group may have deeper compatibility issues.

The impact depends on the individual application.

Ethereum is replacing the 21,000 gas fee for every ETH transfer

That overstates the change.

EIP-8037 modifies charges for permanent state creation and introduces separate state-gas accounting.

The applicable cost depends on the operation, account state, and final protocol rules.

Every transaction will become more expensive by the same percentage

Gas consumption varies according to transaction behavior.

The monetary fee also depends on the market price of gas.

A higher gas charge for a particular operation does not establish a universal percentage increase in dollar fees.

Sepolia’s Glamsterdam activation was undone

The Foundation confirmed that Glamsterdam had activated on Sepolia on October 6.

The subsequent Hoodi postponement did not reverse that separate testnet activation.

ETH holders must upgrade their wallets immediately

The official postponement notice states that ordinary Ethereum mainnet users and ETH holders do not need to take action because of the Hoodi schedule change.

Node operators and application developers have different responsibilities.

Ethereum developers have confirmed a new mainnet date

No Glamsterdam mainnet activation date was confirmed in the October 22 notice.

A revised Hoodi schedule also remained unannounced as of October 28.

Important Context: Ethereum Is Becoming Harder to Upgrade

Ethereum’s history illustrates how a successful blockchain can become increasingly complex.

Early in its development, relatively few applications depended on the details of its execution environment.

Today, Ethereum supports financial markets, stablecoins, lending protocols, custody infrastructure, wallets, and automated settlement systems.

Some applications manage significant amounts of money.

Others provide essential infrastructure for additional applications.

A low-level execution change can therefore have consequences beyond a single smart contract.

For example, a new gas rule may require wallets to update estimation.

That may require RPC providers to change simulation behavior.

Those changes may affect transaction bundlers and financial applications built on top of them.

The infrastructure is interconnected.

This does not mean Ethereum should avoid protocol changes.

Without continued development, existing limitations could become increasingly expensive.

But it explains why higher throughput cannot be pursued without extensive compatibility testing.

Our reporting on Ethereum gas fees and network demand examines the user-facing side of scaling pressure.

The Glamsterdam postponement reveals the other side: making additional capacity available without breaking the assumptions that existing applications depend on.

Ethereum’s recent growth as a financial settlement environment also increases the importance of predictable execution.

For example, the expansion of JPM Coin onto Ethereum illustrates the growing range of institutions using public-blockchain infrastructure.

Such use cases make dependable transaction behavior and coordinated upgrades commercially important, even when a specific application is not identified as affected by the current gas proposals.

What Happens Next for Glamsterdam?

The immediate next step is further investigation of EIP-8037’s interaction with existing contracts.

Developers need to determine which behaviors require changes to the proposal, which can be addressed through application updates, and which require additional testing.

The outcome may include revised specifications, updated client implementations, or further developer guidance.

Those possibilities should not be mistaken for decisions that have already been made.

A new Hoodi activation schedule

The Ethereum Foundation has said the replacement schedule will be announced separately.

The revised activation will need coordinated client support.

Node operators and validators should follow the updated network configuration rather than relying on the superseded October 26 instructions.

Further smart-contract compatibility testing

Ethereum developers have already published tools and research for examining the effects of gas repricing.

Further testing can help distinguish contracts that simply require higher gas limits from those whose control flow changes under the new rules.

Independent security researchers can also contribute by identifying affected execution patterns.

A mainnet decision

The mainnet activation date remains unconfirmed.

Developers will need to assess the technical evidence before announcing a schedule.

A successful Hoodi activation would provide useful evidence, but it would not eliminate the need for final release coordination and readiness checks.

The important milestone is a safe and well-supported mainnet upgrade.

No reliable replacement date should be inferred solely from earlier roadmap expectations.

Final Thoughts

Ethereum postponed Glamsterdam on Hoodi because developers need more time to investigate how new gas-accounting rules interact with existing smart contracts.

The decision affects a planned testnet activation and its associated 200-million gas-limit increase.

It does not represent a mainnet rollback, a canceled blockchain, or confirmation of stolen funds.

But the underlying concern is significant.

Ethereum wants to increase execution capacity without allowing permanent state growth and resource consumption to become unsustainable.

EIP-8037 and related proposals are intended to help achieve that objective.

At the same time, those changes can affect contract behavior in ways that go beyond transaction fees.

A failed call may leave a different amount of usable gas.

An error handler may complete when it previously reverted.

A legacy assumption about execution limits may no longer hold.

Those possibilities explain why developers are investigating compatibility before moving forward.

The postponement is therefore neither an obvious failure nor an insignificant scheduling adjustment.

It demonstrates the difficulty of evolving a mature blockchain that already supports substantial financial activity.

Ethereum’s next scaling challenge is not merely making room for more transactions. It is making that room without changing the financial guarantees users and developers already depend on.

Frequently Asked Questions

Why was Ethereum’s Glamsterdam upgrade delayed?

Core developers postponed the scheduled October 26 activation on Hoodi to investigate interactions between EIP-8037’s state-gas changes and smart contracts already deployed on Ethereum mainnet.

When was the delay announced?

The Ethereum Foundation announced the postponement on October 22, 2026, following All Core Devs Execution call #248.

Was Glamsterdam supposed to launch on October 26?

October 26 was the scheduled activation date for the Hoodi testnet, not Ethereum mainnet.

Has Ethereum mainnet been upgraded to Glamsterdam?

No. Glamsterdam had not activated on Ethereum mainnet as of October 28, 2026.

What is the new Glamsterdam launch date?

No replacement Hoodi activation date or confirmed mainnet launch date had been announced as of October 28.

Did Ethereum roll back transactions?

No. The postponement removed a future activation configuration. It did not reverse Ethereum’s blockchain history.

Is Glamsterdam completely canceled?

No cancellation of the full upgrade has been announced. The Hoodi activation was postponed pending further investigation.

What is EIP-8037?

EIP-8037 is an Ethereum improvement proposal that increases and separately accounts for gas used to create permanent blockchain state, including accounts, contract code, and storage.

Why can EIP-8037 affect existing smart contracts?

It changes gas accounting, including the resources available during nested calls and failure handling. Contracts relying on older gas assumptions may execute differently.

What is the state-gas reservoir?

It is a mechanism in EIP-8037’s proposed accounting model that tracks gas available for state-creation operations separately from ordinary execution gas.

Does EIP-8037 create a security vulnerability?

The change introduces compatibility concerns that require investigation, including potentially unsafe behavior in some contract failure-handling patterns. That is not equivalent to confirmation of an exploited mainnet vulnerability.

What is EIP-8038?

EIP-8038 is a related proposal that updates the gas pricing of state-access and state-modification operations. Its interaction with EIP-8037 contributes to the need for compatibility testing.

Did Glamsterdam already activate on Sepolia?

Yes. The Ethereum Foundation confirmed Sepolia activation on October 6, 2026. The subsequent postponement concerns Hoodi.

What happened to Ethereum’s 200-million gas limit?

The planned 200-million gas-limit increase on Hoodi was removed from the activation schedule. It is not a confirmed Ethereum mainnet limit.

Will Ethereum transaction fees increase after Glamsterdam?

Some operations may consume more gas under the proposed repricing rules, particularly those creating permanent state. Actual monetary fees depend on transaction behavior and the market price of gas.

Will all Ethereum smart contracts need to be rewritten?

No. The Ethereum Foundation’s earlier replay testing found the large majority of transactions unaffected. Some contracts may require updated gas limits or more extensive changes.

Do ETH holders need to move their funds?

No. The Ethereum Foundation explicitly states that no action is required from ordinary mainnet ETH holders because of the Hoodi postponement.

What should Ethereum validators do?

Operators participating in Hoodi should use client releases and configurations that explicitly reflect the postponed activation. Ethereum mainnet validators should follow future official upgrade instructions when issued.

What are enshrined proposer-builder separation and block-level access lists?

They are separate Glamsterdam components intended to improve block-production architecture and execution efficiency. Both formed part of the wider upgrade package scheduled for Hoodi.

Is Ethereum abandoning its scaling roadmap?

There is no evidence of that. The postponement concerns further compatibility investigation before deployment. Its effect on the final mainnet schedule remains uncertain.