Ethereum Glamsterdam Delay Makes Gas Accounting a Compatibility Layer

The Ethereum Glamsterdam delay is not a routine scheduling adjustment. It is a warning that gas accounting has become part of the compatibility layer between the Ethereum protocol and the applications built above it. Core developers postponed the next Hoodi testnet activation after auditors found that EIP 8037 and EIP 8038 can invalidate assumptions used by existing smart contracts and offchain systems. The proposals are designed to price state growth more accurately and make larger block limits safer. Their economic logic is strong. Their interaction with deployed code is the difficult part.

The latest development came on 6 November 2026, when the Ethereum Foundation asked contract developers and auditors to inspect eight broken gas invariants. The Foundation said ChainSecurity had identified projects that could become vulnerable after Glamsterdam because they rely on behavior that the new state gas model changes. AllCoreDev participants therefore chose not to activate the upgrade on Hoodi until the risks are understood. ChainSecurity and Dedaub are being engaged, internal audits are continuing, and development of the later Hegota upgrade is proceeding in parallel.

This is responsible protocol governance. Ethereum is not merely replacing one number with another. EIP 8037 introduces a separate way to meter state creation, while EIP 8038 reprices access to and modification of state. Those changes can alter how much gas is available before and after a call, what a failed call leaves behind, and whether a failure handler completes or reverts. Contracts that appear unrelated to fee policy can therefore change behavior without changing their own code.

The Block2Learn assessment is that Glamsterdam has exposed a central problem in mature blockchain infrastructure. Scaling requires protocols to correct resource prices as usage changes. Compatibility requires old applications to continue behaving as their authors expected. When those goals conflict, delaying a testnet fork is less damaging than discovering the conflict after mainnet activation. The important question is not whether Ethereum can move quickly. It is whether Ethereum can change the economics of computation without silently changing the meaning of deployed software.

What the Ethereum Glamsterdam Delay Actually Changes

The immediate operational event concerns Hoodi, Ethereum’s long lived testnet, not mainnet. The upgrade had been scheduled for 26 October 2026 at epoch 132,352. It would have combined the Amsterdam execution layer changes with the Gloas consensus layer changes and raised the Hoodi gas limit to 200 million at the same epoch. Core developers removed that activation from client configurations after ACDE meeting 248. There is no replacement activation date.

The official Hoodi postponement notice is precise about what did and did not happen. Hoodi history was not reverted. The future fork configuration was removed. Operators were told to update both execution and consensus clients to releases that explicitly incorporated the postponement. Mainnet never had a Glamsterdam activation date, and ordinary ETH holders were not asked to take action.

The 6 November update adds a more important layer. The delay is no longer described only as time for further investigation. The Ethereum Foundation has published a concrete list of eight assumptions that applications may rely on and asked projects to report real breakage, preferably with a working exploit. The purpose is to give core developers evidence for the next design decision. They may retain the proposals, modify them, narrow them, or change the migration sequence.

That process matters because testnets are not ceremonial rehearsals. They are supposed to discover interactions that specifications and isolated client tests miss. A mature test environment should be allowed to stop a rollout. Block2Learn recently argued in Ethereum Public Infrastructure Turns Sovereignty Into a Procurement Test that institutions using public networks need a disciplined process for following protocol upgrades. Glamsterdam demonstrates why. The public ledger can remain available while the assumptions embedded in contracts, wallets, relayers and monitoring systems change underneath it.

Why Ethereum Wants to Reprice State

Ethereum state includes account balances, contract code, storage slots and other information that every validating client must be able to access. State is not the same as historical chain data. History can be served and reconstructed through specialized systems. Current state sits on the critical path of transaction execution. As it grows, node databases become larger and state access becomes slower.

EIP 8037 begins with a clear scaling problem. The proposal says the state database of a dedicated Geth node was about 390 GiB in January 2026. After the block gas limit rose from 30 million to 60 million, average daily new state increased from about 105 MiB to about 326 MiB. That implies roughly 116 GiB of annual growth at the observed rate. The response was more than proportional because user behavior changed when capacity became available.

The proposal estimates that a 200 million block gas limit could produce about 387 GiB of state growth per year if the post increase behavior scaled proportionally. Starting from 390 GiB, the database could cross a 650 GiB threshold associated with performance degradation in less than one year. The exact path will depend on demand, client improvements and application design, but the direction is difficult to dispute. A protocol cannot treat permanent state as if its long term cost were unchanged while it expands execution capacity.

EIP 8037 therefore creates a cost per state byte called CPSB, set at 1,530 gas in the current proposal. A new storage slot is modeled as 64 bytes and receives 97,920 units of state gas. A new account is modeled as 120 bytes and receives 183,600 units. Code deposit is charged per byte at the same state gas rate. These charges are intended to harmonize the price of different ways to create persistent state.

The proposal also separates state creation gas from ordinary execution gas. A transaction still declares one total gas limit, but gas above a defined execution threshold can enter a state gas reservoir. State creation draws from that reservoir first. The design allows a transaction to create more state without forcing the execution gas available to an individual call frame to expand in the same way. In principle, Ethereum can support larger blocks while retaining a distinct limit on execution complexity.

EIP 8038 addresses the other side of the database problem. It raises the cost of cold account access from 2,600 to 3,000 gas, introduces explicit charges for writing accounts and storage, and gives some operations an additional charge when they require more than one database read. The proposal separates state touching work into access, write and creation components. That decomposition makes the gas schedule more closely reflect what clients actually do.

The economic objective is not to make Ethereum expensive for its own sake. It is to prevent applications from consuming a scarce permanent resource at a price that becomes increasingly detached from the cost imposed on every node. Underpricing state can subsidize current users by transferring storage and performance costs to future operators. Correct pricing protects the ability of independent participants to run nodes, which is part of Ethereum’s decentralization model.

Why Better Resource Pricing Can Break Existing Applications

Gas is commonly described as the fee paid for computation. That description is incomplete. Gas is also a control mechanism inside smart contracts. Developers inspect gasleft(), assign fixed gas amounts to calls, reserve enough gas for cleanup, and use the outcome of calls to decide whether an operation can be retried. Relayers and wallets estimate how much gas a transaction needs. Some systems sign messages that include fixed gas limits. Others infer success from the fact that a transaction was mined.

Changing the gas schedule can therefore change application logic. ChainSecurity’s analysis focuses on insufficient gas griefing. A contract may call an external target, catch a failure and record that an item is permanently failed. If an attacker can deliberately provide too little gas for the target while leaving enough gas for the caller to record failure, a retryable operation can become irreversible. Developers use checks and assumptions about the remaining gas to prevent that outcome.

Glamsterdam changes what the remainder can buy. The state gas reservoir travels with a call, while the familiar 63 over 64 forwarding rule applies only to execution gas. The GAS opcode and Solidity’s gasleft() report execution gas, not the separate reservoir. A call can fail and restore state gas to the caller. A failure handler may then be able to write storage even when the visible execution gas appears small.

The inverse problem also matters. State creation becomes much more expensive. A fixed gas budget that comfortably created a storage slot under the current schedule may fail after Glamsterdam. A relay may submit a transaction with a limit that was hard coded years ago. A factory deployment may depend on a presigned transaction whose gas limit cannot simply be edited. The contract code remains identical, but the execution path crosses a new economic boundary.

This is why the Ethereum Glamsterdam delay should be understood as a compatibility event. Backward compatibility is not limited to opcode names and data formats. Applications also depend on operational invariants: gas decreases monotonically, certain reserves are sufficient, a mined delegation was applied, and a failed call leaves too little gas to perform meaningful work. The protocol can preserve every instruction while breaking those expectations.

The Eight Gas Invariants Under Review

The Ethereum Foundation’s public invariants repository translates the problem into eight audit questions. The table below condenses their practical meaning without treating every affected contract as vulnerable. Each project must inspect its own call paths, permissions and recovery logic.

Invariant under review	What Glamsterdam changes	Main application risk	Safer design direction
An out of gas call makes the whole transaction fail	Reservoir gas can let the caller continue and write state	A retryable item can be marked permanently complete or failed	Revert on inadequate gas and preserve retries
Clearing temporary state returns no usable gas immediately	State gas can be refilled during the transaction	Locks and flags can change the gas available around calls	Use transient storage or stable nonzero patterns
Gas spent by a reverted call is gone	Reverted state creation can restore gas	Callers may misclassify why a target failed	Check return values and explicit error conditions
A fixed gas amount remains enough	State creation and writes become much more expensive	Relayers, factories and signed operations can fail	Make limits adjustable and estimate against new rules
gasleft() only decreases	Refills can increase visible execution gas	Cost accounting can underflow, wrap or misbill	Avoid billing from differences between two gas readings
The retained fraction after a failed call is harmless	Repricing can make the remainder sufficient for a failure handler	Insufficient gas griefing can become persistent state	Validate available gas before the call and keep failures retryable
Existing stipends and reserves are sufficient	Storage writes require larger reserves	Cleanup, transfer and nonce logic can fail unexpectedly	Remove rigid reserves and consume nonces only after success conditions
A mined EIP 7702 delegation was applied	A failed delegation can roll back while the transaction remains mined	Signed authorization may be reusable	Bind initialization to the signature and verify account code afterward

The repository says the most common findings so far concern fixed gas amounts and fixed reserves. That is intuitive. Hard coded limits are easy to miss because they can live outside contract source code. A bot, relayer, wallet configuration, signed message or deployment script may carry the relevant number. Auditing only Solidity is therefore insufficient.

Offchain systems deserve equal attention. A monitoring service may mark a transaction complete because it was included in a block. A wallet may assume eth_estimateGas reflects only one resource dimension. A deployment tool may expect a factory at a canonical address and use a presigned transaction with an immutable gas limit. Indexers may interpret receipts according to existing accounting. Compatibility testing must follow the entire transaction lifecycle.

Gas Estimation Is Part of the User Interface

Most users never call gasleft(). They rely on wallets, account abstraction providers, exchanges and applications to estimate gas correctly. That abstraction works only when tooling understands the protocol’s resource model. EIP 8037 explicitly requires wallets and node software to account for the new state creation costs and the two dimensional metering design.

An underestimated transaction can fail even when the user’s intended action is valid. An overestimated limit may lock more funds temporarily or produce confusing warnings. Bundlers under ERC 4337 must reason about several operations inside one package. Relayers need to protect themselves against operations that consume a different mix of state and execution gas than expected. Simulation services must use a client and fork configuration that actually implements the proposed rules.

The application layer therefore needs more than a protocol specification. It needs compatible RPC behavior, reliable simulators, upgraded SDKs, revised deployment scripts and tests that include failure paths. This resembles the lesson from Base Denim 200ms Blocks Turn Speed Into an Application Risk Test. A faster or more efficient protocol changes the operating environment of applications even when their business logic appears unchanged.

The difference is that Glamsterdam reaches into resource assumptions accumulated across Ethereum’s history. Some applications are immutable. Some have governance controlled upgrade paths. Some are abandoned but still hold assets or serve as dependencies. The ecosystem cannot assume every affected project will patch quickly. Core developers need to understand whether the risky assumptions are rare edge cases, common but repairable patterns, or structural dependencies that require specification changes.

The Delay Is a Governance Strength, Not Proof of Failure

A protocol upgrade can fail in two ways. It can ship slowly and disappoint a schedule, or it can ship quickly and break an application that users believed was reliable. The second outcome is usually more expensive. Ethereum’s governance process is valuable when it makes that tradeoff visible before mainnet activation.

The delay also shows the limits of informal coordination. No single organization knows every contract and offchain service that depends on Ethereum. Auditors can scan verified code and known systems, but private code, proxies, custom relayers and operational scripts remain outside a complete inventory. The Foundation’s call for action is an attempt to turn a distributed ecosystem into a temporary compatibility testing network.

That process resembles the governance problem examined in Polygon PIP 93 Turns Upgrade Speed Into a Security Council Test. Faster decisions can reduce exposure to known risks, but concentrated authority and incomplete visibility can create different risks. Ethereum uses open specifications, multiple client teams, public developer calls and broad application testing. The model is slower, yet it can surface conflicts that a narrower upgrade committee might miss.

The decision should not be romanticized. Delay creates costs. Client teams must maintain changing branches. application developers face uncertainty about which gas schedule to target. Infrastructure providers postpone testing plans. Other upgrades may compete for attention. If the specification changes repeatedly, teams can tire of testing provisional behavior.

Still, a postponement before Hoodi is evidence that the safety process worked. It is not evidence that Ethereum mainnet suffered a failure. There is no Glamsterdam mainnet date to miss, no chain history to unwind and no user migration to reverse. The correct standard is whether developers use the additional time to produce a clearer specification and credible compatibility evidence.

What the Delay Means for Ethereum Scaling and ETH

EIP 8037 exists because Ethereum wants higher throughput without allowing state growth to make ordinary node operation progressively harder. If the proposal is weakened without an alternative, scaling pressure does not disappear. It moves back into database growth, hardware requirements and client performance. A temporary delay can therefore protect decentralization if it leads to a safer way to price permanent state.

The upgrade also illustrates why network improvement and token value capture must be separated. More accurate gas pricing can strengthen Ethereum’s resource discipline. It does not guarantee a higher ETH price. Expensive state creation could encourage applications to reduce storage, move data elsewhere or use rollups more efficiently. Those responses may lower some forms of layer one demand while improving the network’s long term sustainability.

Fee effects are similarly ambiguous. Higher gas units for state operations do not translate mechanically into proportionally higher ETH fees. The final cost depends on base fee conditions, application redesign, transaction composition and whether activity migrates to systems that use state more efficiently. EIP 8037’s own examples assume a low base fee when estimating ETH costs. Gas units measure resource allocation; ETH fees add a market price for inclusion.

For ETH holders, the most important signal is not the calendar delay. It is whether Ethereum can increase capacity while preserving credible node economics and application safety. A network that never updates resource prices accumulates hidden infrastructure costs. A network that changes them carelessly creates hidden application risks. Long term value depends on managing both.

Risks and Limits

The first risk is overstating the vulnerability. The Foundation identified assumptions that can break, not proof that every contract relying on gas behavior is exploitable. Access controls, retry logic, upgradeability and surrounding business rules can prevent a theoretical invariant change from becoming a loss.

The second risk is incomplete discovery. Verified source repositories do not cover private contracts, offchain code or every proxy implementation. The most important affected system may not respond publicly because disclosure could reveal an exploit before a fix is available.

The third risk is specification drift. Audits performed against one version can become obsolete if EIP 8037 or EIP 8038 changes. Testing must identify the exact specification and client implementation used.

The fourth risk is false confidence from successful transactions. Compatibility failures often live in rare paths: first time account creation, empty recipients, reverted nested calls, contract deployment, nonce consumption and emergency recovery. Normal transfers can work while the dangerous branch remains untested.

The fifth risk is migration inequality. Large protocols can hire auditors and run fork simulations. Smaller applications may depend on maintainers with limited time. A technically repairable change can still strand software whose governance or development process is inactive.

The sixth risk is indefinite delay. State growth is a real cost. Postponing a difficult repricing without choosing an alternative would preserve short term compatibility by weakening the long term scaling plan.

The seventh risk is confusing Hoodi with mainnet. The current pause applies to a testnet activation. It should not be presented as an Ethereum outage, a mainnet rollback or a requirement for ordinary users to move funds.

Three Scenarios for Glamsterdam

Base case: targeted specification changes and a revised Hoodi schedule

In the base scenario, audits find that most affected projects rely on fixed gas limits or reserves that can be updated. Core developers adjust the most disruptive accounting details, publish clearer guidance and retain the core objective of pricing state growth separately. Wallets, RPC providers and major applications complete compatibility tests. A new Hoodi date is announced after client releases converge.

This path preserves the scaling rationale while accepting a moderate delay. The proposals may emerge with different constants or refill behavior, but the separation between execution and state costs remains recognizable.

Favourable case: the audit campaign produces a reusable compatibility standard

In the favourable scenario, the eight invariants become a durable testing framework for future forks. Tooling automatically scans contracts and offchain systems for rigid gas assumptions. Major protocols publish results, affected projects fix their code, and client simulations include adversarial failure paths rather than only successful execution.

Glamsterdam then delivers more than a resource repricing. It improves the ecosystem’s ability to evaluate backward compatibility. Later upgrades can reuse the methodology, reducing the chance that economic changes surprise deployed applications.

Adverse case: structural dependencies force a larger redesign

In the adverse scenario, auditors find widely used immutable contracts or deployment infrastructure that cannot adapt. A change that looks local to gas accounting threatens core bridges, wallets, account abstraction flows or settlement systems. Core developers must defer one proposal, redesign the reservoir or sequence the repricing over multiple upgrades.

The main cost would be slower progress toward higher gas limits and better state pricing. Even then, deferral would be preferable to activating a known compatibility hazard. The failure would lie in leaving the resource problem unresolved, not in refusing to ship a dangerous schedule.

Indicators That Will Show Which Scenario Is Developing

The first indicator is the response to the public invariants repository. Reports should identify affected contracts, the relevant invariant, a reproducible test and whether the project can repair the issue. Counts without severity and exposure will be less useful.

The second is specification movement. Changes to reservoir behavior, gas refill rules, cost constants or call frame accounting will reveal which risks core developers consider structural.

The third is independent audit output. ChainSecurity, Dedaub and internal Ethereum reviews should distinguish exploitable behavior from incompatible but harmless assumptions. Coordinated disclosure may delay public detail when funds are at risk.

The fourth is client convergence. Execution clients need consistent implementations, and consensus clients must agree on the revised fork schedule. A new Hoodi date matters only when releases and test vectors support it.

The fifth is tooling readiness. Wallets, RPC providers, bundlers, relayers, simulators and deployment systems should demonstrate accurate estimation under the two dimensional model. Tests should include new accounts, fresh storage, contract deployment and nested reverts.

The sixth is application migration. Major DeFi protocols, bridges, multisignature wallets and account abstraction providers should disclose whether they rely on the eight assumptions and how they tested fixes.

The seventh is the fate of the 200 million Hoodi gas limit. If the increase returns alongside revised state pricing, the scaling plan remains intact. If the gas limit proceeds without an effective state growth control, the economic tradeoff has shifted rather than disappeared.

The Block2Learn Assessment

The Ethereum Glamsterdam delay is a positive safety decision because it treats gas accounting as application behavior rather than protocol bookkeeping. EIP 8037 and EIP 8038 address a real problem. Ethereum cannot raise throughput indefinitely while charging permanent state according to assumptions formed around a smaller database and lower block limits.

The proposals also change more than prices. A separate reservoir, gas refills and repriced writes alter the meaning of signals that contracts use to classify failure. That is where a resource reform becomes a compatibility event.

Ethereum should preserve the objective of aligning gas with client costs. It should not preserve every implementation detail merely because the proposals reached Last Call. The correct outcome is the smallest design change that protects the state growth objective while removing dangerous ambiguity from call behavior and estimation.

The wider lesson is that mature blockchains inherit software history. Immutability protects users from arbitrary changes to deployed code, but it also prevents developers from repairing every old assumption. Protocol governance must therefore treat the installed application base as part of the system being upgraded.

Hoodi is the correct place to discover this tension. A testnet pause is cheaper than a mainnet incident, and an open audit campaign is more credible than pretending one team can inspect the entire ecosystem. Success will not be measured by how quickly the original date is replaced. It will be measured by whether the revised upgrade makes state growth more sustainable without converting hidden gas assumptions into new security failures.

Continue Through the Block2Learn Learning Path

The Block2Learn Crypto Layer provides the structure needed to evaluate upgrades such as Glamsterdam. Begin with Ethereum’s execution model: transactions consume gas, calls create nested frames, state changes persist only when execution succeeds, and the fee market prices access to limited block capacity.

Then separate three layers of analysis. Resource economics asks whether gas prices reflect the burden placed on nodes. Compatibility asks whether existing contracts and tools retain their expected behavior. Governance asks who decides when the evidence is sufficient to activate a change. A strong upgrade must survive all three tests.

Finally, evaluate protocol claims through failure paths, not only headline capacity. Ask what happens when a call runs out of gas, a storage write is reverted, a delegation fails, an estimator uses the wrong fork rules or an immutable deployment transaction carries an obsolete limit. Systems reveal their real security properties when assumptions stop holding.

Glamsterdam is attempting to make Ethereum state more expensive to create because permanent data is a real network cost. The delay shows that changing that price can also change application logic. Understanding both sides is the difference between following an upgrade calendar and understanding the infrastructure being upgraded.

Information is abundant. Structure is rare.