Pricing the State: What Glamsterdam’s Gas Reset Says About Ethereum’s Next Scaling Phase

Editorial illustration: Ethereum’s next capacity increase depends on keeping the cost meter aligned with the resources nodes actually consume.

Research date: 26 August 2026

Executive summary

Ethereum’s proposed Glamsterdam repricing is easy to misread as a collection of obscure gas-constant changes. It is more consequential than that. The network is attempting to replace an increasingly stale price signal with a resource-aware one before raising base-layer throughput again. The central policy choice is therefore not “higher fees versus lower fees.” It is whether Ethereum can sell more blockspace without silently transferring the cost of persistent state growth and slower database access to every node operator.

Two proposals scheduled for Glamsterdam, EIP-8037 and EIP-8038, address complementary problems. The first raises and harmonizes the charge for creating durable state and introduces separate accounting for state creation. The second updates the relative price of reading and changing a much larger state database. On 24 August, Ethereum Foundation research and testing teams published a historical-replay impact assessment: most transactions are unaffected; most flagged failures can be repaired by allowing more gas; a small tail may depend on hardcoded assumptions and require code or workflow changes.

Our thesis is that the repricing is a necessary scaling precondition, but not yet a finished social contract. It improves the relationship between private demand and public infrastructure cost, and it makes a higher gas limit more defensible. Yet the evidence is counterfactual, the EIPs remain in “Review,” parameters can still move, and legacy contracts are not uniformly upgradeable. The quality of the transition will be measured less by the elegance of the gas schedule than by whether wallets, estimators, application teams, and governance processes surface the compatibility tail before mainnet activation.

The scaling constraint has moved into the database

Ethereum expanded markedly in 2025. According to the Foundation’s 2026 protocol priorities update, the mainnet gas limit rose from 30 million to 60 million, while Fusaka’s PeerDAS improved the path for rollup data. The roadmap now lists Glamsterdam for the fourth quarter of 2026 and highlights block-level access lists and enshrined proposer-builder separation as its major features. This sequencing matters: data availability, execution throughput, and state sustainability are connected, but they are not the same bottleneck.

Gas is Ethereum’s internal resource meter. A transaction pays units of gas according to the operations it performs, then pays a market price for those units. If the units cease to represent underlying work, the fee market can clear while the protocol still misallocates resources. Cheap creation of persistent state is especially problematic because the buyer pays once while nodes must store and serve the result over time. Underpriced access also permits blocks whose nominal gas total understates the database work needed to execute them.

The motivation section of EIP-8037 puts numbers around the pressure. It reports that, as of January 2026, a Geth state database was about 390 GiB. After the gas limit moved from 30 million to 60 million, average new state per day rose from roughly 105 MiB to 326 MiB—more than tripling rather than merely doubling. At that observed post-increase rate, annual growth was about 116 GiB. The proposal cautions against treating the response as linear, but estimates that a 200 million gas limit, if scaled proportionally from the new baseline, could produce around 387 GiB of state growth per year and cross a cited 650 GiB performance-degradation threshold in less than a year.

Those are proposal authors’ measurements and extrapolations, not immutable network facts. They nevertheless expose the economic mismatch: raising the headline gas limit while retaining old relative prices can invite the workload that is cheapest by the meter, not the workload that is cheapest for nodes to process.

flowchart LR
    A[Higher block gas limit] --> B[More execution capacity]
    A --> C[More room for state-heavy activity]
    C --> D[Faster persistent-state growth]
    D --> E[Larger databases and slower access]
    E --> F[Higher node cost and execution risk]
    G[Resource-aligned repricing] --> H[Users internalize more of state cost]
    H --> I[Safer capacity increases]
    I --> B
    H -. reduces pressure .-> D

What the two proposals actually change

The two EIPs divide the problem cleanly enough for an institutional reader to understand without following opcode minutiae.

EIP-8037 sets a target of roughly 120 GiB of annual state growth at a reference 150 million block gas limit. Its conceptual innovation is multidimensional accounting: execution gas and state gas are tracked separately, while the user still faces one total gas payment. At block level, the binding dimension determines fullness. This is an attempt to price two resources that do not scale identically without creating a new user-facing fee asset.

EIP-8038 decomposes state-touching work into access, write, and creation. Its current draft leaves warm access and cold storage access unchanged, while raising cold account access and adding clearer write charges. The most conspicuous draft change is the modeled storage-write component, from an extracted equivalent of 2,800 to 10,000 gas, although the proposal explicitly notes that some “current” component values are approximations derived from composite charges. This is not a blanket multiplication of every transaction’s gas. It shifts relative prices toward operations that impose more database work.

The distinction between price level and price structure is crucial. A higher block limit can increase supply and reduce congestion; repricing can make particular state-heavy actions consume more units. Both can happen simultaneously. Users care about the product of gas used and the market price of gas, not either term in isolation. It is therefore premature to claim that Glamsterdam will simply make Ethereum “more expensive” or “cheaper.” The distributional effect depends on workload, congestion, application design, and adaptation.

Replay evidence: reassuring in aggregate, actionable in the tail

The Foundation’s announcement says historical mainnet transactions were replayed under the candidate schedules and compared with their original execution. The associated gas-schedule divergence dashboard separates outcomes into no change, success with changes, fixable with a larger gas limit, potentially broken, already failing, and unknown. “Potentially broken” means a previously successful replay did not recover even when tested with up to ten times its original gas limit; it does not prove that the contract will fail in future production.

That definition is important. Each transaction is replayed independently against canonical pre-transaction state. The method catches deterministic incompatibilities in observed historical paths, but it cannot model future wallet estimation, user behavior, fee-market response, contract upgrades, or traffic composition. An “unknown” result may also reflect a diagnostic coverage cap rather than an execution outcome. This is a screening instrument, not a forecast.

Editorial illustration: aggregate reassurance and tail-risk triage are compatible conclusions; the replay is designed to find the small set that needs attention.

The practical failure modes are revealing. The Foundation identifies fixed gas stipends, hardcoded gas values in calls, branching on remaining gas, and presigned transactions with fixed limits. These patterns convert a mutable protocol price into an application invariant. Most “fixable” transactions merely need frontends or infrastructure to supply a more realistic limit. The harder category comprises behavior whose control flow or authorization has embedded the old schedule.

flowchart TD
    A[Historical transaction succeeds under baseline] --> B[Replay under candidate schedule]
    B --> C{Outcome}
    C -->|Same trace and result| D[No change]
    C -->|Still succeeds, execution differs| E[Review but no immediate failure]
    C -->|Out of gas at original limit| F[Test with higher limit]
    F -->|Completes within tested ceiling| G[Estimator or supplied-limit fix]
    F -->|Still fails| H[Potentially broken]
    H --> I[Inspect hardcoded gas, gas-dependent logic, signatures]
    I --> J[Test mitigation on Platåberget]

The chart does not publish a stable headline percentage in its rendered landing text, and this report does not infer one. The responsible conclusion is qualitative but useful: the large majority is unchanged, most surfaced failures are limit-fixable, and a small but meaningful tail deserves direct testing. Precision without a pinned schedule, block range, and coverage denominator would be false comfort.

Why Platåberget changes the governance quality

On 17 August, the Foundation introduced Platåberget, a public, short-term testnet intended to remain available for several months before Glamsterdam reaches longer-lived testnets. It also warned that tools relying on a hardcoded maximum gas limit—including wallets, indexers, and gas estimators—will break and need updates. This broadens the issue beyond contract bytecode.

The network’s compatibility boundary includes the software that constructs, simulates, estimates, signs, submits, and indexes transactions. A contract can be semantically sound while a wallet underestimates its gas. An application can raise a limit while an RPC cache retains old constants. A presigned workflow can be operationally frozen even if its underlying contract is upgradeable. Platåberget provides a shared environment in which these linked components can fail together, which is exactly what isolated unit tests often miss.

This is also a stronger form of protocol governance. Ethereum does not pass upgrades through a legislature; it coordinates standards authors, client teams, node operators, application builders, and users around executable software. Public replay evidence, an address-search interface, direct outreach, and a durable early testnet convert “rough consensus” from an abstract norm into a falsifiable migration process.

Implications for investors, builders, and the network

For ETH and infrastructure investors, the repricing should be read primarily as capacity-risk management. A network that raises throughput without bounding its node burden may boost short-run activity while weakening the decentralization and reliability that make its blockspace valuable. Conversely, a network that never updates prices can allow legacy assumptions to veto scaling. Glamsterdam’s approach attempts to preserve the option to raise capacity by making costly resource use visible.

For application teams, gas efficiency becomes more multidimensional. Compact storage, fewer durable writes, access-aware transaction design, and robust estimation are no longer merely fee optimizations; they are compatibility and reliability disciplines. Applications that subsidize user gas will feel changes directly in unit economics. Protocols with immutable contracts or off-chain signed instructions face a different risk profile from upgradeable systems with actively maintained frontends.

For node operators, the intended benefit is indirect but fundamental: blocks whose gas totals better approximate real execution and storage costs. The proposal cannot eliminate state growth, hardware variance, or client-performance differences. It can reduce the subsidy to workloads that create long-lived obligations.

For rollups, the immediate impact is mixed. The repricing discussed here concerns Ethereum L1 execution; ordinary L2 execution uses each rollup’s own fee rules. Yet rollups and bridges still settle, prove, and manage contracts on L1. Their operational exposure depends on how state-heavy those L1 interactions are and whether relayers and estimators adapt. The broader upside is a healthier, higher-capacity settlement layer.

Risks, counterarguments, and unresolved questions

First, empirical pricing can create an illusion of objectivity. Benchmarks depend on client implementations, hardware, database structure, cache behavior, and the chosen workload. “Cost per state byte” is a governance parameter informed by measurement, not a natural constant. Publishing methods and revisiting them as the network evolves will matter as much as the first calibration.

Second, backward compatibility is uneven. “Just increase the gas limit” is straightforward only when the submitting software remains under active control. Immutable contracts, abandoned applications, long-lived presigned transactions, and integrations with fixed policy ceilings may not be repairable. The economic value at risk, not simply the number of affected contracts, should guide outreach.

Third, multidimensional metering adds protocol and block-building complexity. EIP-8037’s separate execution and state accounting is designed to remove an artificial coupling, but more dimensions create more implementation surface and new edge cases. Client interoperability and adversarial testing must establish that the cure does not introduce consensus risk.

Fourth, the present evidence is provisional. As of this report date, both EIP pages label the proposals “Review,” even though the Foundation describes them as scheduled for inclusion. EIP-8037 itself says some values are not final. The Ethereum roadmap lists Glamsterdam for Q4 2026, but Ethereum correctly describes roadmap timing as changeable. Readers should distinguish upgrade intent, current draft parameters, testnet behavior, and final mainnet specification.

Finally, repricing is not state expiry. It changes incentives at the margin; it does not remove the installed state database or guarantee that annual growth meets a target. If demand is insensitive to cost—or if capacity increases dominate the new price signal—growth can still exceed expectations. Measurement must continue after activation.

A decision framework for the remaining runway

Three indicators deserve attention before mainnet: whether the potentially broken set shrinks after outreach and retesting; whether major wallets and RPC providers correctly estimate under the candidate schedule; and whether multiple execution clients converge on performance and state-growth assumptions. A fourth, less visible indicator is documentation discipline: published dashboards should pin schedule version, replay range, denominators, and coverage gaps so that headline claims remain reproducible.

The correct success criterion is not zero changed transactions. Any meaningful repricing changes some behavior. Success is a bounded, understood compatibility tail; credible remediation for economically important systems; client agreement; and evidence that the revised meter supports higher throughput without shifting unpriced burdens onto node operators.

Conclusion

Glamsterdam’s repricing marks a maturation in Ethereum’s scaling strategy. The network is moving beyond treating the block gas limit as a single accelerator and toward asking what kind of work fills the block, what persists afterward, and who bears that cost. EIP-8037 makes durable state creation legible; EIP-8038 updates the price of interacting with a larger database. Together they aim to make future capacity increases safer rather than merely larger.

The early evidence supports cautious confidence, not complacency. Historical replay says the aggregate compatibility impact is limited and mostly manageable, while deliberately exposing a tail that aggregate statistics could hide. Platåberget gives the ecosystem time to turn those signals into fixes. The remaining uncertainty—draft parameters, benchmark representativeness, immutable dependencies, and implementation complexity—is precisely why the test period matters.

Ethereum’s wager is that honest resource pricing can reconcile growth with credible neutrality and broad node participation. If the migration is executed transparently, the repricing will be remembered less for making certain operations cost more and more for preserving the network’s ability to offer more capacity without disguising its infrastructure bill.

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-8037: State Creation Gas Cost Increase

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

• Ethereum testing teams, Repricing Impact — Gas Schedule Dashboard

• Ethereum Foundation, Protocol Priorities Update for 2026

• ethereum.org, Ethereum roadmap