Glamsterdam rewrites app economics: separate state creation from execution budgets

The Ethereum Foundation said on November 6 that compatibility issues had delayed the Glamsterdam hardfork process, with Hoodi awaiting resolution. This is not a mainnet activation announcement. Foundation notice

For product teams, the exposure involves both cost and business correctness. A new-user action that previously succeeded may exceed its old budget. A failed operation that previously reverted completely may instead leave a permanent failure record. Multiplying every gas budget by a blanket factor neither produces accurate quotes nor proves that funds or message-processing flows remain safe. This analysis uses the proposals and testing material retrieved as of November 7; parameters and specifications may still change.

What users pay versus what fits in a block

EIP-8037 proposes separate metering for state creation. Users still pay the sum of execution gas and state gas, but block capacity and the next block's base-fee calculation depend on the larger of the two cumulative dimensions. This does not create an independent bidding market for each dimension or make state storage free. It aims to constrain long-term state growth while reducing competition between state creation and execution within a single counter. EIP-8037

That distinction changes the meaning of operational dashboards. Transaction fees charged or subsidized by an app and the network's remaining execution capacity can no longer be explained by one cumulative figure. Treating cumulative receipt gas as block congestion may misread capacity: the proposal explicitly distinguishes cumulative paid gas in receipts from the block gas metric. Our inference is that sponsors should track expenditure, operation success and resource use separately, rather than setting subsidies solely from gas used per block.

The economic choice is to assign more of the burden of long-lived node data to its creators. That may make scaling more sustainable while concentrating some costs in deployment and first-use journeys. Accommodating more execution and making each user action cheaper are separate outcomes that require separate evidence.

New users need their own cost model

Under the current draft, changing an originally zero, cold storage slot to a nonzero value costs 64 × 1,530, or 97,920 state gas. Adding 2,100 for access and 10,000 for writing produces 110,020 in total. This is the modeled charge for one particular write, not the price of an entire transfer or a universal multiplier for application costs. EIP-8037, EIP-8038

For example, the same token-transfer entry point may follow different state paths when updating an existing holder's balance and creating a balance slot for a first-time holder. In our analysis, a fixed acquisition subsidy based on average successful-transaction costs would hide this distinction. Teams should replay first claims, first approvals, first wallet deployments and repeat operations as separate groups, then assess whether product margins cover the most expensive legitimate path.

Avoiding new slots is not enough. EIP-8038 also changes access and write charges, so updating existing state may become more expensive. Batching can amortize some overhead, but where it involves more external accounts, proxies or failure retries, savings must be demonstrated across the complete call path. A lower transaction count alone proves little. EIP-8038

gasleft() is not a complete invoice

EIP-8037's reservoir model sets aside part of the budget for state creation. The GAS opcode, exposed as Solidity's gasleft(), reports only gas_left, excluding the reservoir. Undoing state creation can also trigger immediate refills. Subtracting two gasleft() readings therefore cannot reliably represent the user's complete cost, and readings cannot simply be assumed always to decrease. EIP-8037

This matters to relayers, sponsors and on-chain charging contracts. A fee routine that treats the difference as proof of expenditure may omit state costs or encounter arithmetic problems when the reading rises. A stronger engineering direction separates the user-agreed charging rule, verifiable execution outcomes and off-chain reconciliation. A cap can bound losses; it cannot turn incorrect measurement into correct measurement. The official audit material specifically flags billing based on gasleft() differences. Invariant inventory

The costliest mistake may follow a failure

A subtler issue is what the outer contract can do after a target call fails. From the refill rules in EIP-8037, we infer a hypothetical scenario that requires testing: state-gas refills or a reservoir could allow some failure handlers to complete. Suppose a flow previously reverted because it lacked gas to write a failure record. It could instead mark a task permanently complete even though the target did not execute. The required property is that retry rights survive, not merely that the function returns without an error. Security analysis

Critical release tests should therefore work backward from business outcomes: deliberately underfund a subcall, then inspect claim rights, message status, nonces and retry entry points. Batches that must catch failures need an explicit recovery path. Remaining gas or empty revert data alone should not determine the inferred cause of failure. This does not claim that every contract catching failures is vulnerable; exposure depends on the full path and state.

Temporary locks deserve separate attention. Flags needed only within one transaction can be evaluated for EIP-1153 transient storage, which is discarded at transaction end and suits some temporary cross-call state. Migration still requires checking proxy context, rollback behavior and reentrancy protection. Persistent balances and permissions needed across transactions do not belong there. EIP-1153

Make outcomes part of acceptance criteria

A practical preparation plan pins a testing-specification version and covers new and existing accounts, new and existing slots, sufficient and insufficient state budgets, and successful and reverted paths. It should include contracts, bots and RPC-adjacent components. Official guidance explicitly warns that off-chain software may also be affected; contract unit tests alone are insufficient. Official audit repository

Product teams should clarify adjustable budgets, sponsorship caps and responsibility for recovery. Budget headroom helps legitimate users avoid getting stuck; recoverable business state prevents mistakes from becoming permanent. The useful window created by Glamsterdam's delay is an opportunity to replace historical gas estimates with verifiable constraints on both cost and failure outcomes. Passing those tests should precede promises of lower fees or greater throughput.