Ethereum’s Glamsterdam bargain: paying for permanence to unlock scale

Editorial illustration: Glamsterdam makes the cost of permanent state visible alongside the cost of computation.

28 August 2026 — Research report

Executive summary

Ethereum’s forthcoming Glamsterdam upgrade is often described through its headline features—enshrined proposer-builder separation, block-level access lists and a much higher gas-limit ambition. For application owners and investors, however, the consequential change may be less photogenic: the network is rewriting the price of what it must remember.

The core thesis of this report is that Glamsterdam’s gas repricing is a scaling compact. Ethereum can safely make more blockspace available only if gas prices continue to approximate the scarce resources consumed by transactions. Persistent state has grown while several of its prices have remained anchored to assumptions last substantially revised in the 2021 Berlin fork. EIP-8037 therefore prices new state by estimated bytes and introduces a separate state-gas meter; EIP-8038 reprices access and writes using contemporary client benchmarks. The Ethereum Foundation says the resulting schedule is a prerequisite for further gas-limit increases and is derived around a performance target supporting roughly three times base-layer throughput.

That bargain distributes costs unevenly. A plain transfer to an existing account remains 21,000 gas under the current draft decomposition, but creating an account, deploying bytecode and opening fresh storage slots become markedly more expensive. The proposed state-creation unit is 1,530 gas per byte: 183,600 state gas for a new 120-byte account footprint, 97,920 for a 64-byte storage slot, and 1,530 per byte of deployed code. Meanwhile, a first write that changes an existing storage slot rises from an equivalent 2,800-gas component to 10,000, while warm access and cold storage access remain unchanged. These figures are draft parameters, not promises about the final fork.

Historical replay found the large majority of transactions unchanged, according to the Foundation’s 24 August impact notice. A small set either exhaust their original gas limits or remain potentially broken even after a substantial increase. The fault line is not “old contract versus new contract”; it is hidden dependence on today’s gas schedule—fixed call stipends, hard-coded gas values, branches on remaining gas, pre-signed transactions with fixed limits, and infrastructure that assumes a universal maximum. Platåberget, a public short-term testnet that activated Glamsterdam on 20 August, moves this from theoretical debate into an active migration window.

For institutions, the most useful conclusion is not that Ethereum is simply becoming more expensive. It is that the network is distinguishing recurring work from permanent externality. State-heavy designs face a higher marginal cost; stateless interaction and reuse become relatively more attractive; node sustainability improves if the meter works as intended. The transition risk sits mainly in application and infrastructure assumptions, while the long-run risk is calibration: prices must be high enough to restrain state growth without making legitimate onchain deployment uneconomic.

Why the old meter became a scaling constraint

Gas is both a fee unit and a safety mechanism. It limits how much work a block can demand and makes users pay in proportion to resource use. That mechanism weakens when unlike resources are compressed into stale constants. Computation consumes CPU for a moment. Calldata consumes bandwidth and history. New accounts, storage slots and contract code enlarge a database that full nodes must retain, serve and traverse well after the originating transaction has settled.

The Ethereum Foundation’s repricing notice says state-operation prices were last adjusted in the Berlin fork and that subsequent state growth, amplified by recent gas-limit increases, changed the underlying workload. The issue is not that every state touch has become equally expensive. It is that some operations can create a permanent obligation far out of proportion to their one-time fee. If block capacity rises while this gap persists, throughput today can become storage and database pressure tomorrow.

Glamsterdam’s answer has two linked parts. EIP-8038 decomposes state-touching work into access, write and creation components and grounds proposed access/write prices in benchmarks run against a March 2026 mainnet-sized snapshot. EIP-8037 separately prices durable creation by a cost-per-state-byte parameter. This separation matters: the bottleneck resource, not merely the sum of all work, determines whether the block is full and informs the next base fee.

flowchart LR
    T[Transaction demand] --> X[Execution work]
    T --> S[Durable state creation]
    X --> EG[Execution-gas meter]
    S --> SG[State-gas meter]
    EG --> B{Bottleneck resource}
    SG --> B
    B --> L[Block capacity and next base fee]
    L --> N[Safer path to higher throughput]

This is not fully general multidimensional resource pricing: users still pay the sum of execution gas and state gas, and tx.gas bounds both in practical terms. Yet at block level, separating the meter prevents cheap computation from masking expensive database growth, or vice versa. It is an accounting change with architectural consequences.

What changes—and what the numbers actually mean

The Glamsterdam repricing meta-proposal, EIP-8007, consolidates the draft schedule and explicitly warns that numbers remain subject to change. Its design reference is a 150 million block-gas limit and a state-growth target of 120 GiB per year at 50% average state-gas utilization. Dividing the annual state-gas budget by that target yields the proposed 1,530 gas per state byte. The reference is deliberately between a stated current 60 million limit and an expected future 300 million—not a forecast that the mainnet limit will jump to either value on a fixed date.

The distinctions are economically important. Updating an existing slot is not the same as creating one. Reading a slot already warmed during a transaction remains cheap. A transfer to an existing account retains the familiar 21,000 total, though its pieces are made explicit; a transfer that creates a previously nonexistent account incurs the additional state charge at runtime. This rewards reuse rather than indiscriminately taxing every onchain action.

Editorial illustration: Glamsterdam raises the relative price of data every node must continue to carry.

The 120-GiB target is better understood as a policy calibration than a prediction. EIP-8037 presents worst-case annual growth of 80 GiB at a 100 million block limit, 120 GiB at 150 million, and 240 GiB at 300 million, assuming blocks are fully consumed by state creation. Real utilization and transaction mix will differ. The value of the model is that it creates a legible relationship between capacity, persistent bytes and price, so future adjustments can be argued from measurable constraints rather than inherited constants.

The compatibility problem is behavioral, not merely financial

A transaction that costs more but still completes is a budgeting issue. A transaction whose control flow changes because gas changed is a correctness issue. Glamsterdam creates both.

The Foundation’s historical replay sorts transactions into four outcomes: no change; success with changed details; failure at the original limit but success with a higher limit; and potential failure even with a substantially raised limit. It has not published a population percentage in the announcement, so “large majority” and “small set” should not be converted into invented precision. The public repricing impact checker provides contract-level evidence and failure modes, while the Foundation says it is contacting the most affected builders directly.

flowchart TD
    R[Replay under Glamsterdam prices] --> Q{Same outcome?}
    Q -->|Yes| A[No behavioral change]
    Q -->|No| G{Completes at original gas limit?}
    G -->|Yes| C[Succeeds with changed gas or detail]
    G -->|No| H{Completes with a higher limit?}
    H -->|Yes| F[Operational fix: estimation or limit]
    H -->|No| P[Potential semantic break]
    P --> D[Review fixed stipends, hard-coded gas and gasleft branches]

The notorious example is the 2,300-gas stipend used by Solidity’s transfer and send. A recipient fallback that once fit beneath the stipend can fail after repriced state work. Similar fragility appears when a caller forwards a literal amount of gas, when a contract deliberately branches on gasleft(), or when a pre-signed transaction cannot be regenerated with a larger limit. More gas does not repair logic whose meaning depends on the meter itself.

Offchain software has its own exposure. Wallets and RPC providers must estimate two kinds of charge accurately while still presenting one transaction budget to users. Indexers and simulation systems may cache opcode costs. Tooling with a hard-capped maximum gas limit will break under the new environment, according to the Platåberget announcement. The impact can therefore propagate from protocol repricing to failed user operations even when the underlying contract is sound.

Platåberget changes the status from proposal to preparedness

Glamsterdam is not yet a mainnet fact. EIP-8007 remains a draft; EIP text and parameters can move. The relevant operational fact is that testing has begun. Platåberget was introduced on 17 August as a publicly joinable, short-term testnet intended to run for several months, with the Glamsterdam fork scheduled there for 20 August. It precedes deployment on longer-lived Sepolia and Hoodi, which in turn precede mainnet.

timeline
    title Glamsterdam repricing migration window
    17 Aug 2026 : Platåberget announced
    20 Aug 2026 : Glamsterdam activated on Platåberget
    24 Aug 2026 : Historical replay impact notice published
    Next : Stabilization and specification feedback
         : Sepolia and Hoodi upgrades
    Later : Mainnet activation after testnet stability

This staged route is substantive risk management. Repricing touches deterministic execution: all clients must calculate exactly the same result. But it also touches an ecosystem of estimators, relayers, multisig services, account-abstraction systems and contract frontends that protocol conformance tests cannot fully represent. A testnet lasting months gives downstream operators time to observe failure, not merely attest that they compiled a compatible client.

For governance observers, Platåberget also exposes a healthy distinction between “scheduled for inclusion” and “final.” The Foundation identifies EIP-8037 and EIP-8038 as scheduled for Glamsterdam, while their published specifications preserve draft language. Treating the current numbers as definitive would be premature; treating the migration as hypothetical would be equally mistaken.

Strategic implications

First, state efficiency becomes a more direct product decision. Applications that create a new slot for every user action, deploy many unique contracts, or use chain state as inexpensive permanent storage will face a clearer cost signal. Factory patterns that reuse implementation code, storage lifecycle discipline and designs that keep verifiable data outside active state gain relative appeal. This does not mean “move everything offchain.” It means permanence should be bought where its trust benefit justifies its network-wide carrying cost.

Second, higher L1 throughput is not free capacity. EIP-8037’s calculation makes the trade explicit: as the block gas limit grows, state pricing must constrain how quickly durable bytes accumulate. The institutional case for scaling therefore depends on two linked claims—that users receive more execution capacity and that node operation does not become progressively less accessible. Repricing is an attempt to preserve that balance, not proof that it has been achieved.

Third, gas abstraction remains incomplete at the edges. Ordinary users should need no action if wallets and infrastructure update correctly, as the Foundation states. Yet user experience will reveal whether the abstraction holds. A first payment to a new address may require substantially more gas than a payment to an existing one. Estimators need current state information; sponsored-transaction systems need adequate policy buffers; fixed-fee business models need to understand the changed transaction mix.

Fourth, the proposal establishes a precedent for empirical repricing. EIP-8038 describes tests across clients using a mainnet-sized state snapshot and selects conservative worst-client results that cannot simply be optimized away. That methodology is important beyond any single constant: gas schedules can become maintained performance models rather than constitutional numbers. The cost is governance complexity and the possibility that benchmark design, client selection or resource targets embed debatable judgments.

Risks and counterarguments

The strongest counterargument is that sharply higher state-creation costs may discourage useful L1 activity before alternative designs are mature or equally composable. A roughly 7.6-fold increase in code-deposit price per byte and nearly fivefold increase for a fresh slot are not marginal adjustments. Deployment-intensive systems and applications onboarding new users could bear costs unrelated to their immediate revenue. If base fees are also high, the combined user bill may concentrate activity in large operators or L2s.

Calibration also rests on estimates. “Bytes of state” are an abstraction over database implementation, trie overhead, pruning, history and future state architectures. The 120-GiB annual target and 150-million reference limit are governance choices. Client benchmarks reduce guesswork but do not eliminate it. An overly conservative worst-client anchor may tax everyone for a lagging implementation; an optimistic model may externalize costs onto node operators.

Separate metering adds cognitive and implementation complexity. New failure modes can appear in estimation, refunds and resource accounting. The proposal’s benefit depends on clients and infrastructure converging before mainnet. That is why the public replay data and a long-lived-enough test environment matter as much as elegant specification text.

Finally, repricing cannot solve state growth alone. Historical state, synchronization, database layout and proof systems remain relevant. Nor does a higher nominal gas limit automatically translate into proportional end-user throughput under all demand conditions. Glamsterdam’s cited roughly threefold target is an engineering objective, not a guaranteed threefold reduction in fees or latency.

Conclusion

Glamsterdam’s repricing asks Ethereum users to pay more accurately for permanence so the network can safely do more. Its most defensible feature is conceptual clarity: execution that ends and state that persists are different burdens and should not hide behind one stale schedule. Its hardest feature is transition risk, because applications and tools have quietly turned today’s gas constants into behavioral assumptions.

The immediate evidence is encouraging but intentionally incomplete. Historical replay indicates that most activity is unaffected, most flagged exhaustion can be repaired with a higher limit, and a narrower set needs code-level attention. Platåberget supplies the venue to challenge those findings before Sepolia, Hoodi and mainnet. The prudent reading is neither alarmist nor complacent: the economic direction is coherent, the parameters remain draft, and compatibility must be demonstrated across the application stack.

If Glamsterdam succeeds, the lasting outcome will not be any particular gas number. It will be a more honest meter—one that makes the cost of permanent shared memory visible, gives developers incentives to economize on it, and turns future scaling into an explicit bargain rather than an accumulating liability.

Direct sources

• Ethereum Foundation, “Glamsterdam Repricing Impact for Smart Contract Developers,” 24 August 2026

• Ethereum Foundation, “Announcing the Platåberget Testnet,” 17 August 2026

• Ethereum Improvement Proposals, EIP-8007: Glamsterdam Gas Repricings

• Ethereum Improvement Proposals, EIP-8037: State Creation Gas Cost Increase

• Ethereum Improvement Proposals, EIP-8038: State-access gas cost update

• Ethereum Foundation / EthPandaOps, Glamsterdam repricing impact checker

Research cutoff: 28 August 2026. EIP status and parameters should be treated as provisional until the fork specification is finalized.