Ethereum’s Glamsterdam bargain: price the state to unlock the scale

Glamsterdam’s repricing is a compact expression of Ethereum’s scaling bargain: capacity can rise only if the gas schedule continues to measure the scarce resources that nodes actually consume.

Executive summary

Ethereum’s forthcoming Glamsterdam upgrade is often described through its larger architectural components—enshrined proposer-builder separation and block-level access lists. Yet the most immediate issue for applications may be less glamorous: two proposals, EIP-8037 and EIP-8038, rewrite the economics of creating, reading and changing persistent state. On 24 August, the Ethereum Foundation warned that historical replays identify a small set of contracts whose embedded gas assumptions could fail or degrade under the candidate schedule. The same notice says most flagged cases can be repaired by raising transaction gas limits and that ordinary users need take no action.

The thesis of this report is that repricing is not chiefly a fee increase. It is a capacity-control mechanism. Ethereum can lift the block gas limit only if one unit of gas remains a defensible proxy for node work. State has grown while its access prices have remained substantially anchored to the 2021 Berlin schedule. If underpriced operations are allowed to dominate larger blocks, headline throughput rises while node hardware, execution time and database growth absorb an unpriced liability. EIP-8037 makes new state more expensive and gives it a separate accounting dimension; EIP-8038 increases selected access and write costs using client benchmarks. Together, the proposals move the constraint from an undifferentiated gas bucket toward the actual bottlenecks.

The migration cost is real but bounded by the evidence now available. The official replay dashboard covers 929,731,274 transactions across four million mainnet blocks, from 3 December 2024 through 15 June 2026. Under EIP-8037, 2.69 million transactions, or about 0.29% of all replays, land in “potentially broken”; under EIP-8038, 3.04 million, about 0.33%, do. Those figures are risk flags, not forecasts: “potentially broken” means the historical transaction did not recover at a tested gas ceiling of ten times its original limit. The exercise does not model wallet, developer or market adaptation.

For institutions, the relevant conclusion is neither “nothing changes” nor “Ethereum is breaking contracts.” It is that protocol-level scaling is being financed by a deliberate transfer of responsibility. Core developers are pricing state more conservatively; application and infrastructure operators must remove brittle gas constants, improve estimation and test counterfactual execution before public-testnet and mainnet activation. Glamsterdam makes operational readiness part of the scaling dividend.

Why state, not computation alone, is the binding issue

Gas is Ethereum’s internal unit of resource accounting. It is not synonymous with the fiat price of a transaction: users pay gas used multiplied by a market-determined price. The schedule determines the relative weight of different operations. When those weights fall out of line with real client costs, fee-market pricing cannot correct the distortion. A bidder can pay the prevailing price per gas and still consume too much of an underpriced resource.

Persistent state is unusually consequential because every full node must retain and serve it. EIP-8037 reports that, as of January 2026, the state portion of a dedicated Geth database was roughly 390 GiB. After the block gas limit moved from 30 million to 60 million, average new state created per day rose from about 105 MiB to 326 MiB—more than tripling. At that post-increase rate, annual growth was around 116 GiB. The proposal’s extrapolation is deliberately cautionary: at a 200 million gas limit, state could grow by roughly 387 GiB per year, pushing a 390 GiB starting database beyond a cited 650 GiB performance-degradation threshold in less than a year.

This is not a claim that growth will follow a smooth straight line. The EIP itself notes that the response to the 30-to-60-million increase was non-linear and may reflect a one-off behavioral shift. That caveat matters. The figures are a stress case for parameter design, not a deterministic storage forecast. Still, the direction is difficult to dispute: raising capacity while keeping state creation cheap invites applications to externalize long-lived database costs onto node operators.

EIP-8037’s answer is to harmonize the charge per new state byte and target average state growth of 120 GiB a year at a reference 150 million block gas limit. It introduces a cost-per-state-byte parameter and separates state-creation gas from execution gas. Users still face one transaction gas limit and pay the sum, but block fullness is assessed against the bottleneck dimension. That design allows a block rich in computation but light on new state to use more execution capacity without granting the same latitude to a block that aggressively expands the database.

flowchart LR
    A[Higher block gas limit] --> B[More transaction capacity]
    B --> C{What resource is consumed?}
    C -->|Computation| D[Execution-gas meter]
    C -->|New persistent state| E[State-gas meter]
    D --> F[Block constrained by the busier dimension]
    E --> F
    F --> G[Throughput rises without an uncapped state subsidy]

EIP-8038 addresses the other side: the cost of touching and updating state that already exists. Its authors benchmarked execution clients against a March 2026 mainnet-sized snapshot, isolated individual operations in synthetic blocks, and used the worst non-optimizable client result as the conservative network-wide reference. The proposal raises cold account access from 2,600 to 3,000 gas, isolates an account-write component at 9,000, and lifts the storage-write component from an equivalent 2,800 to 10,000. Cold storage access and warm access remain unchanged at 2,100 and 100 respectively. The point is not indiscriminate inflation; it is selective alignment with observed bottlenecks.

What the historical replay actually says

The headline “changed” share includes successful transactions whose gas use or trace differs. It must not be read as a failure rate.

The official divergence dashboard is unusually useful because it tests the proposals against actual historical activity rather than only synthetic workloads. Each transaction is replayed independently against its canonical pre-transaction state, first under the baseline and then under a candidate schedule. The data are pinned to the same four-million-block window for both schedules. The underlying EIP-8037 metadata and EIP-8038 metadata were generated on 24 August 2026.

The table supports three interpretations. First, repricing is economically material. Nearly half of EIP-8038 replays succeed with some changed gas use, output, log or trace. That does not imply user-visible disruption, but it demonstrates how widely state access runs through Ethereum applications. Second, a large portion of the EIP-8037 divergence is mechanically recoverable: 18.77% of all historical transactions fail at their old gas limit but complete at a higher tested limit. Estimation and transaction construction therefore matter as much as contract logic. Third, the tail is small in percentage terms but large in absolute operational terms. Millions of historical calls merit triage even when only a subset maps to live, economically important contracts today.

The dashboard’s taxonomy prevents two common analytical errors. A baseline failure is not counted as newly broken. Conversely, a transaction is “fixable” only if it completes by the tested ten-times ceiling; this does not prove that such a limit would be practical under block or protocol constraints. “Potentially broken” includes failures that a still-higher ceiling might rescue, as well as semantic divergences and contracts whose logic genuinely depends on gas remaining. The dashboard explicitly calls the replay a counterfactual, not a forecast.

flowchart TD
    A[Historical mainnet transaction] --> B[Replay at original gas limit]
    B --> C{Baseline succeeded?}
    C -->|No| D[Already failing: not a new break]
    C -->|Yes| E{Candidate schedule succeeds?}
    E -->|Yes, identical| F[No change]
    E -->|Yes, differs| G[Succeeds with changes]
    E -->|No| H[Replay up to 10× original limit]
    H -->|Succeeds| I[Fixable with gas-limit increase]
    H -->|Still fails| J[Potentially broken: investigate]

Where breakage concentrates

The Ethereum Foundation identifies a recognizable family of hazards: fixed gas stipends, hardcoded gas values in internal calls, branches based on gasleft(), and presigned transactions carrying immutable gas limits. Solidity’s long-familiar 2,300-gas transfer and send pattern is an emblem of the problem. A contract that treats a schedule-specific allowance as a permanent safety property can become brittle when the protocol corrects relative costs.

The change also reaches beyond smart-contract code. The Platåberget announcement says wallets, indexers and gas estimators that assume a hard maximum gas limit will need updates. A simple ETH transfer to an existing account remains 21,000 gas under the proposed decomposition, while a transfer that creates a new account incurs a runtime state-creation charge. Thus “plain transfer equals 21,000” stops being universally true. Cached constants can cause an otherwise valid action to be submitted with too little gas.

This creates an asymmetric institutional risk. A modern frontend with dynamic estimation may adapt without users noticing. A dormant treasury workflow, old multisig integration, exchange withdrawal engine or governance executor may be touched only rarely—precisely the system least likely to have appeared prominently in recent activity or routine testing. Historical replay improves discovery, but the absence of an address from the dashboard is not a warranty. The Foundation advises reviewing hardcoded values even for unlisted contracts.

The broader Glamsterdam sequencing

Repricing is part of a larger fork, not a standalone fee patch. According to EIP-7773, the Glamsterdam meta proposal tracks the included execution- and consensus-layer changes. Platåberget, also called glam-devnet-8, opened public participation as an early, temporary testing ground intended to run for several months. Its Glamsterdam transition was scheduled for 20 August. The Foundation’s stated sequence is to stabilize devnets, then move the fork through long-lived Sepolia and Hoodi testnets, and only afterward activate mainnet. No mainnet activation date is stated in the cited announcements.

That qualification is crucial for decision-makers. EIP pages currently carry “Review” status and say they are undergoing peer review, even as the Foundation describes both repricing proposals as scheduled for inclusion. Specific parameters can still evolve through testing and governance. Institutions should treat the direction as committed enough to prepare for, but not mistake candidate values for an immutable production schedule.

timeline
    title Glamsterdam validation path
    2026-08-17 : Platåberget public testnet announced
    2026-08-20 : Glamsterdam fork scheduled on Platåberget
    2026-08-24 : Repricing replay impact published
    Next : Non-finality devnet and specification feedback
         : Sepolia and Hoodi transitions after stability
    Later : Mainnet activation after long-lived testnets

Implications for investors, operators and application owners

For ETH’s economic narrative, the important signal is governance discipline around supply of blockspace. Increasing a numerical gas limit is easy; preserving decentralized verification while doing so is harder. Repricing makes the capacity increase more credible because it acknowledges that state growth and slow database operations cannot be wished away. The benefit is not necessarily lower fees in every transaction class. It is more sustainable aggregate capacity and a fee schedule that discourages permanent state consumption relative to lighter computation.

For application economics, state-heavy designs become relatively less attractive. Frequent writes, creation of fresh storage slots and deployment of new code will bear more of their long-term infrastructure cost. Systems that reuse state efficiently, clear temporary changes, batch intelligently or move nonessential data away from L1 gain a relative advantage. This is an architectural incentive, not merely a one-time migration expense.

For operational risk, gas estimation becomes a control surface. Institutions should inventory transaction creators, simulation services, relayers, presigned flows and limits embedded in policy engines; replay representative actions on Platåberget; and preserve evidence of behavior across client and wallet versions. This is not a request for users to manually raise gas. It is a requirement that the systems acting for them estimate under the new rules.

Risks, counterarguments and unanswered questions

The first counterargument is that repricing can suppress useful activity or make some applications uneconomic. That is possible, especially for state-intensive L1 systems. But leaving a resource underpriced does not remove its cost; it shifts that cost to node operators and ultimately pressures decentralization. The policy question is whether the chosen parameters approximate resource burden well enough, not whether state should remain subsidized forever.

Second, the replay numbers may look alarming without context. EIP-8038 changes some aspect of a majority of working-baseline replays, while EIP-8037 marks an unusually large fixable cohort. Yet historical transactions were submitted with limits optimized for the old schedule. After activation, estimators and users will adapt, so replay failures overstate likely steady-state failure. On the other hand, adaptation is not automatic for immutable or abandoned contracts. The replay may understate risk in rarely used legacy systems outside the sampled window.

Third, multidimensional metering adds complexity. More faithful resource accounting can create new implementation, estimation and block-building edge cases. EIP-8037 explicitly discusses added block-building complexity and interactions with account-abstraction bundles. The safe case for the design therefore depends on diverse client implementations, adversarial devnet testing and unambiguous tooling behavior—not only sound economics.

Finally, the 200 million gas objective should not be read as a guarantee of threefold end-user throughput. Workloads differ, the binding gas dimension can shift, and proposer-builder or networking constraints may intervene. The Foundation describes the new schedule as derived from a performance target supporting roughly a three-times increase in base throughput; EIP-8038 separately frames its benchmark target as enabling a fivefold increase from 20 million gas per second. These are design targets under specified assumptions, not promises about transactions per second.

Conclusion

Glamsterdam’s repricing is a test of Ethereum’s willingness to make scaling costs explicit. EIP-8037 limits the subsidy to permanent state growth; EIP-8038 updates the price of accessing and modifying a database that has become much larger since Berlin. The historical replay shows broad changes in gas consumption, a substantial class recoverable through better limits, and a narrow but material tail requiring direct investigation.

The prudent reading is constructive but conditional. The proposals strengthen the economics behind higher block capacity, while their safety depends on ecosystem preparation and continued testing. The transition will be successful if users experience it as an invisible infrastructure upgrade—not because compatibility risk was trivial, but because contract owners, wallets, exchanges, custodians and RPC providers treated gas assumptions as versioned dependencies rather than eternal constants.

Direct sources

• Ethereum Foundation: Glamsterdam repricing impact, 24 August 2026

• Ethereum Foundation: Announcing the Platåberget testnet, 17 August 2026

• EIP-8037: State Creation Gas Cost Increase

• EIP-8038: State-access gas cost update

• EIP-7773: Glamsterdam hard-fork meta proposal

• Official gas-schedule divergence dashboard

Research cut-off: 29 August 2026, 00:00 UTC. Proposal status, parameters and activation sequence may change after publication.