Ethereum Glamsterdam: What Smart Contracts Must Test

Ethereum’s Glamsterdam upgrade is not a mainnet event yet, but its proposed gas changes are already testable on the public Platåberget environment. The immediate task for smart-contract teams is not to predict a fork date: it is to find code and tooling that assume fixed gas prices, a single gas dimension or a universal 21,000-gas transfer. EIP-8037 and EIP-8038 are scheduled for inclusion, remain review-stage specifications, and can still change.

What Glamsterdam changes for developers

Glamsterdam combines consensus- and execution-layer work. For application developers, the most operationally important part is the repricing of state creation and state access:

EIP-8037 introduces a separate state-gas dimension and prices new accounts, storage slots and deployed bytecode by the amount of state they create.
EIP-8038 separates access, write and state-creation components and raises selected costs to reflect the work of operating on Ethereum’s larger state.
EIP-7928 Block-Level Access Lists are designed to record the accounts and storage locations touched by a block, enabling parallel reads, validation and state-root computation.

The change is therefore broader than “gas becomes more expensive”. It changes what a transaction, a block and an estimator need to model. The Ethereum Foundation describes the objective as aligning gas with measured resource use so that higher block limits do not degrade node performance.

The proposed gas model in plain English

Today, developers often reason about one execution-gas budget. Under EIP-8037, state creation has its own accounting. A transaction still exposes one gas limit, but the protocol tracks execution gas and state gas separately; the total paid by the user is the sum of both dimensions. The proposal also describes a reservoir model for allocating the transaction’s available gas between them.

EIP-8037 sets a proposed CPSB—cost per state byte—of 1,530, with reference sizes of 64 bytes for a new storage slot and 120 bytes for a new account. These values are part of a review-stage proposal, not a promise about the final mainnet schedule. The EIP’s examples show why deployment and account-creation paths deserve attention: a new account, a new slot and contract bytecode can receive materially different charges from today’s schedule.

EIP-8038 proposes the following changes to named parameters:

Component	Current equivalent	Proposed value	Main surface
`COLD_ACCOUNT_ACCESS`	2,600	3,000 (+15%)	Cold account reads, calls, ETH transfers
`ACCOUNT_WRITE`	6,700	9,000 (+34%)	Value-transferring calls and account writes
`STORAGE_WRITE`	2,800	10,000 (+257%)	`SSTORE` writes that change a slot
`CREATE_ACCESS`	7,000	12,000 (+71%)	`CREATE` and `CREATE2`

The “current equivalent” column is an approximation extracted from legacy composite constants, as EIP-8038 explains. The table should be used to identify review targets, not to calculate a final user fee.

Which contracts are most exposed?

The Foundation’s 24 August analysis replayed historical mainnet transactions under the candidate schedule. The large majority were unaffected. The flagged cases fall into practical categories: transactions with no change, transactions that still succeed with changed gas or traces, transactions fixable by raising the gas limit, and transactions that may remain broken even with a substantially higher limit.

The highest-risk assumptions are straightforward to search for:

Fixed stipends. Solidity’s transfer and send rely on a 2,300-gas stipend. Code that expects a recipient fallback to complete within that budget should be reviewed rather than assumed safe.
Hardcoded call gas. A literal gas value in a low-level call can become insufficient when the callee’s state-access path is repriced.
gasleft() branches. Logic that changes behavior around a remaining-gas threshold can take a different path under the new schedule.
Presigned transactions with fixed limits. A transaction prepared with a static gas limit may fail or become unnecessarily constrained.
Deployment and first-use paths. New accounts, new storage slots, contract creation and code deposit are affected by state-creation accounting.

A contract not listed by the official replay dashboard is not automatically future-proof. The dashboard is a counterfactual replay of historical activity, not a forecast of how new users, wallets, fee markets or contracts will behave.

What wallets, RPCs and indexers must change

The Ethereum Foundation explicitly calls out wallets, RPC infrastructure and node tooling. Gas estimators and eth_estimateGas handling must account for the new rules; cached gas constants can underestimate the requirement and produce failed transactions. Indexers and monitoring systems should also check assumptions about block structure and state access as Block-Level Access Lists move through client implementations.

The practical compatibility surface is wider than Solidity. Teams should inspect SDK defaults, relayers, account-abstraction bundlers, transaction simulators, explorer integrations and internal runbooks. If a component sets a maximum gas limit, assumes a single gas counter or parses only the current execution-payload shape, it belongs in the upgrade test plan.

This is the same operational principle we apply when reviewing AI agent security controls: identify the boundary, make the assumption explicit and test the failure mode instead of relying on a happy-path demo.

A pre-mainnet test checklist

1. Inventory protocol assumptions

Search application code and infrastructure for 2300, fixed gas literals, gasleft(), transfer, send, CREATE, CREATE2, SSTORE, eth_estimateGas, gas-limit caps and presigned transaction templates. Record whether each use is a safety boundary, an optimization or an accidental legacy default.

2. Replay representative transactions

Do not test only successful mints or swaps. Include first-time users, empty-account recipients, new storage writes, contract deployment, upgrade proxies, failed calls, reverts, multicalls and account-abstraction bundles. Compare outcome, gas used, logs, return data and traces against the current schedule.

3. Run on Platåberget

Platåberget is a short-term public testnet created for Glamsterdam testing. The Ethereum Foundation scheduled the testnet fork for 20 August 2026, and its 24 August repricing analysis says the network was available with the new schedule. Use the official resources and client releases rather than copying production configuration blindly.

4. Update estimation and limits

Remove cached constants where possible. Re-run gas estimation against the candidate network, test the transaction cap and state-gas behavior, and make frontends resilient to a higher or differently shaped estimate. Document which limits are protocol constraints and which are application choices.

5. Track what is still uncertain

EIP-8037 and EIP-8038 are review-stage documents. EIP-7773 lists the Glamsterdam EIPs scheduled for inclusion, but its activation table has no timestamps for Sepolia, Holešky or Mainnet. Treat current testnet behavior as a compatibility signal, not as a final promise.

What regular ETH users need to do

Nothing immediately. The Foundation’s guidance is that updated wallets and infrastructure should handle the change. The preparation burden falls on developers, wallet and RPC operators, node teams and maintainers of contracts that encode gas assumptions.

FAQ

Will Glamsterdam make every Ethereum transaction more expensive?

No universal conclusion follows from the proposals. Most historical transactions in the Foundation’s replay were unaffected, while specific state-access and state-creation paths may use more gas or behave differently. Final parameters and activation timing are not settled in the sources reviewed here.

Is Glamsterdam already live on Ethereum mainnet?

No. As of 3 September 2026, the official EIP-7773 activation table does not provide a Mainnet timestamp. The candidate schedule is being tested on devnets and Platåberget before longer-lived public testnets and a possible mainnet transition.

Should teams replace every `transfer` and `send` call now?

They should review every call that depends on the 2,300-gas stipend and test the intended failure behavior. A blanket rewrite without understanding the contract’s reentrancy and error-handling model can introduce a different risk.

Sources

If your Ethereum product needs a review of contract compatibility, gas estimation or upgrade test architecture, contact SignorCrypto to discuss the technical scope.