The Capacity Bargain: What Glamsterdam Changes About Ethereum’s Scaling Model

Editorial systems map showing consensus, execution and state as connected parts of Ethereum’s Glamsterdam upgrade

Glamsterdam is best understood as a coordinated redesign of Ethereum’s production line—not a single speed switch. Original editorial illustration, 17 September 2026.

Executive summary

Ethereum is approaching its most consequential mainnet redesign since the rollup-centric roadmap became operational. Glamsterdam, now in devnet testing with a Sepolia activation scheduled for 6 October and mainnet still described only as “Q4 2026,” combines three changes that are more important together than separately: enshrined proposer-builder separation (ePBS), block-level access lists (BALs), and a broad repricing of state creation and access. The official status page does not yet give a mainnet date, and that uncertainty matters: this is a package whose integration risk is the story, not a footnote.

The thesis of this report is that Glamsterdam converts Ethereum’s scaling debate from a question of how much gas can a block contain? into a question of how explicitly can the protocol coordinate the work behind a larger block? ePBS separates agreement from payload execution and gives validators more time to validate; BALs describe the state dependencies of an entire block so clients can sync and process work more intelligently; repricing makes applications pay more accurately for the persistent database burden they create. Together, these mechanisms aim to make materially higher L1 throughput safe without simply assuming ever-faster home hardware.

That bargain is promising but not free. It adds a protocol-native builder role and new timing/failure states; adds data that every client must compute identically; and breaks some historical assumptions about gas. The Ethereum Foundation says replay testing found that the large majority of contracts are unaffected by repricing, yet a small set may fail or degrade without preventative changes. Meanwhile, ePBS does not abolish builder concentration or censorship concerns; it relocates trustless enforcement into consensus while leaving market structure to be solved by competition and later mechanisms such as inclusion lists.

For investors, operators and application teams, the right near-term metric is therefore not a headline gas-limit target. It is coordinated execution: stable testnets, cross-client agreement, evidence that builder participation remains contestable, and proof that applications adapt without material disruption. Glamsterdam is a capacity upgrade, but its deeper product is a more legible division of labor inside Ethereum.

Why this upgrade matters now

Ethereum’s last two upgrades expanded both usability and data capacity. Pectra activated in May 2025, introducing features including EIP-7702 and raising the maximum effective validator balance. Fusaka followed on 3 December 2025 with PeerDAS, blob-parameter-only forks and a default L1 gas limit of 60 million. The Ethereum roadmap now places Glamsterdam in Q4 2026 and Hegotá in 2027. In other words, Glamsterdam arrives after the network has already pushed the old production model harder; its job is to change that model’s structure before the next large increase.

The urgency is visible in the Foundation’s own planning. Its 7 September protocol-priorities update says that shipping Glamsterdam in December 2026 and reaching the long-horizon L* milestone by December 2029 would imply an average 7.2-month fork cadence. The same update elevates post-quantum preparation while preserving “keep mainnet safe” as priority zero. This creates a governance constraint as important as any benchmark: Ethereum wants faster iteration without normalizing rushed consensus changes.

The public milestone sequence reflects that caution. Ethereum.org lists the upgrade as testing on devnets, names Sepolia on 6 October as the next milestone, and says the mainnet date is unconfirmed. The Platåberget testnet announcement provides a public testing environment built specifically around Glamsterdam client combinations. A schedule is an intention; a testnet is evidence. Readers should treat the latter as the more informative signal.

timeline
    title Ethereum's current scaling sequence
    May 2025 : Pectra activates
             : Account features and more blob capacity
    Dec 2025 : Fusaka activates
             : PeerDAS and 60M default gas limit
    Aug-Sep 2026 : Glamsterdam devnet and dedicated testnet work
                 : Scope integration and repricing tests
    6 Oct 2026 : Sepolia activation scheduled
    Q4 2026 : Mainnet window, date unconfirmed
    2027 : Hegota follows on the roadmap

One package, three constraints

It is tempting to analyze the headlining proposals as independent features. That misses their common purpose. A higher gas limit pressures three different resources: time in the slot, the ability to discover and parallelize state work, and the long-run size and access cost of the state database. Glamsterdam addresses one bottleneck at each layer.

Mechanism	Constraint addressed	Intended dividend	New burden to watch
ePBS, EIP-7732	Block construction and validation share a tight slot	More validation time; trustless builder payment and reveal rules	New builder registry, timing committee and empty-payload state
BALs, EIP-7928	Clients learn state dependencies only while executing	Parallel disk reads, faster sync paths, a foundation for parallel execution	Extra block data; exact deterministic agreement across clients
Gas repricing, EIPs 8037/8038	Gas can underprice persistent state work	Limits state-growth externalities and supports safer capacity increases	Higher costs for state-heavy behavior; compatibility edge cases

ePBS: separating agreement from construction

Today, much block construction is already outsourced through an off-protocol proposer-builder market. EIP-7732 does not invent specialization; it proposes bringing the separation and its enforcement into Ethereum’s consensus rules. Builders become protocol-recognized, staked actors. A proposer can commit to a builder’s bid without receiving the full payload at the same moment, while a Payload Timeliness Committee attests whether the payload arrived on time.

The critical scaling move is delayed validation. The specification removes full execution-payload validation from the hottest part of the slot, giving the next proposer about six seconds and other validators about nine seconds to validate. More time in the validation budget can support larger blocks without demanding that every node finish all work at the earlier deadline.

But “more time” is not equivalent to “less complexity.” EIP-7732 distinguishes full, skipped and empty slots. An empty slot contains the beacon block but not the promised execution payload; the proposer can still receive payment under the protocol’s rules. The EIP documents a “free option” problem in which a rational but malicious builder might withhold a payload when profitable, degrading user experience. It also makes transaction perception more nuanced: a transaction in slot N is not widely validated until the following slot builds and votes on top of it. These are manageable design choices, not reasons to reject ePBS—but they are why latency, empty-slot frequency and builder diversity belong on the post-fork scorecard.

BALs: turning execution into a declared dependency map

A block-level access list records the accounts and storage touched by a block, including reads and post-transaction changes. Under EIP-7928, the list is committed in the block and independently regenerated during execution; a mismatch makes the block invalid. The conceptual shift is powerful: instead of discovering every dependency serially, a client receives a map of the work.

That map enables parallel disk reads and creates a route toward parallel execution, while also allowing state updates to be applied with less re-execution in some synchronization settings. The official EIP’s empirical appendix examined 100 historical blocks and reported an average compressed BAL of 42.7 KB when storage reads were included, with a median of 42.6 KB and a 95th percentile of 73.7 KB. Storage writes and reads represented 85.3% of compressed size. This is not a forecast for all future, larger blocks; it is a bounded sample that shows the metadata is meaningful rather than free.

The same evidence illustrates the trade. The study estimated roughly 300.2 MB per day of additional node bandwidth at the observed block cadence. Better structure can reduce computation on one axis while increasing propagation and storage obligations on another. Ethereum’s design challenge is not to eliminate resource consumption but to make it explicit, measurable and priceable.

flowchart LR
    U[Users submit transactions] --> B[Builder assembles payload]
    B --> C[Proposer commits to builder bid]
    C --> R[Builder reveals payload and BAL]
    R --> T[Timeliness committee checks arrival]
    R --> V[Clients execute and regenerate BAL]
    T --> F{Timely?}
    V --> M{BAL matches?}
    F -->|Yes| H[Consensus can advance]
    F -->|No| E[Empty or failed payload path]
    M -->|Yes| H
    M -->|No| I[Block invalid]
    H --> N[Next-slot validation broadens confidence]

Repricing: state is not a one-time expense

The third component is less visually dramatic but economically essential. State persists. Creating an account, contract or storage slot imposes costs on future node operation that a one-dimensional gas schedule may not capture well. EIP-8037 proposes separate metering for state creation, while EIP-8038 updates state-access charges using cross-client benchmarks and a target performance model.

The proposed changes are deliberately material. EIP-8037’s examples estimate that the state-gas component for a new account rises from 25,000 to 183,600 gas, a new slot from 20,000 to 97,920, and a 24 KB contract deployment from about 4.95 million to 37.78 million. Its illustrative ETH costs assume a 0.08 gwei base fee, so they should not be read as stable fiat or ETH forecasts. The ratios, rather than the quoted ETH amounts, express the policy: persistent new state should become relatively more expensive even if abundant capacity keeps the absolute fee low.

The Foundation’s 24 August compatibility notice says historical transaction replay identified a small group of contracts whose assumptions may shift. Most flagged issues can be fixed by raising supplied gas limits, and the large majority of contracts are unaffected, according to the notice. Yet one class is more awkward: EIP-8037 notes that contracts measuring work by subtracting two gas readings can encounter a negative result under reservoir refills. Already-deployed contracts with that pattern may not be repairable. This is precisely why “gas repricing” is not merely a fee-policy change; gas is also an observable input embedded in application logic.

Balanced editorial chart contrasting Glamsterdam’s capacity dividend with its coordination costs

The upgrade’s benefits and risks are paired: each removed bottleneck creates a new coordination surface that must be measured.

The strategic interpretation

Glamsterdam is a bet on specialization with verification. Builders specialize in payload construction, but consensus enforces payment and reveal behavior. Blocks carry an explicit account-and-storage map, but every execution client verifies it. Applications can use more aggregate capacity, but state-heavy actions face prices tied more closely to their long-term burden. The design does not ask participants to trust specialists; it tries to make specialization auditable.

That has three broader implications.

First, L1 and L2 scaling are complements, not rival ideologies. Fusaka’s PeerDAS expanded Ethereum’s ability to serve rollup data. Glamsterdam targets L1 execution, state sustainability and block construction. Rollups still need a credible settlement layer, and a stronger L1 can host proofs, bridges and high-value state transitions more reliably. Conversely, cheaper blob capacity keeps every retail transaction from competing directly for scarce L1 execution.

Second, throughput should be evaluated as a resource vector, not a single transactions-per-second number. Execution time, bandwidth, state growth, latency and builder concentration can move in different directions. A gas-limit increase is healthy only if the slowest dimension remains within the tolerance of geographically and economically diverse nodes.

Third, protocol ossification remains distant. The September priorities document links the post-Glamsterdam roadmap to fast finality, post-quantum readiness, privacy, state and zkEVM research arcs. Glamsterdam is infrastructure for further change, particularly because BALs and native builder separation create hooks for later parallelism and censorship-resistance mechanisms. Institutional users should price Ethereum as an actively changing platform, with both the upside of adaptation and the operational cost of repeated upgrades.

Risks and counterarguments

Builder concentration may survive enshrinement. Protocol-native settlement can remove trusted relays and make failure rules explicit, but it does not guarantee a competitive builder market. Economies of scale in order flow, latency and optimization may remain. ePBS should be judged by participation distribution and entry costs, not by the mere existence of a registry.

Censorship resistance is not fully delivered here. ePBS is designed to be compatible with inclusion lists, but the roadmap places fork-choice-enforced inclusion lists later. Separating builders from proposers can clarify accountability while still leaving a powerful builder able to omit transactions. Enshrinement makes the market safer to use; it does not automatically make market power disappear.

BALs may exchange compute savings for network overhead. Historical-size analysis is encouraging, but future blocks can be larger and structurally different. A commitment that all clients must regenerate also expands the cross-client consensus surface. Testing needs adversarial blocks, not only representative ones.

Repricing creates concentrated pain. The statement that most contracts are unaffected can coexist with serious impact on a few important contracts, factories or tools. Legacy assumptions about fixed gas behavior are difficult to inventory comprehensively. The right response is neither alarmism nor complacency: publish affected patterns, replay broad histories, and watch whether remediation lands before mainnet.

The calendar can become a risk factor. Ethereum’s ambition for a faster multi-fork cadence is strategically understandable, especially with post-quantum work moving forward. But the official mainnet date remains unconfirmed. A delay after weak test evidence would be a sign of functioning governance; adherence to a target despite unresolved client divergence would not.

What to watch before mainnet

The upgrade should be assessed through a compact evidence dashboard rather than a countdown clock:

Testnet stability: Sepolia activates on schedule only if client combinations are ready; Hoodi and subsequent milestones should run without unexplained finality or payload-availability incidents.
Cross-client determinism: BAL generation and verification must agree across execution clients under adversarial state-access patterns.
Payload outcomes: Empty, withheld and late payload rates should remain low in realistic ePBS conditions.
Builder contestability: Participation should not collapse into a smaller effective set merely because registration and collateral become protocol-native.
Application remediation: Public repricing tests should narrow, rather than expand, the list of materially affected production systems.
Node accessibility: Higher capacity should not cause sustained bandwidth, storage or validation requirements to outrun the hardware assumptions underlying Ethereum’s decentralization claim.

These indicators also explain why a single “maximum gas” number is an inadequate success criterion. Capacity that exists only under ideal builders, uniform clients or data-center hardware is not the same product as capacity that remains robust under ordinary network variance.

Conclusion

Glamsterdam’s importance lies in the way its components reinforce one another. ePBS creates time and an enforceable division of labor. BALs turn hidden execution dependencies into verifiable block data. Repricing constrains the state burden that higher throughput would otherwise compound. The resulting architecture is an attempt to scale through coordination, not brute force.

The strongest case for the upgrade is therefore not that it makes Ethereum “faster.” It is that it makes the costs of speed more explicit and assigns them to mechanisms that can be tested: builder bonds and timing, access-list bytes and client agreement, state-gas charges and application behavior. The strongest case against premature celebration is exactly the same. More explicit machinery produces more observable failure modes, and the system has not yet cleared public testnets or received a confirmed mainnet date.

As of 17 September 2026, the rational stance is constructive scrutiny. Glamsterdam has a coherent answer to the bottlenecks exposed by larger blocks, and its evidence base is advancing. But the capacity dividend becomes real only when independent clients, diverse operators, competitive builders and legacy applications all pass through the same transition. Ethereum is not merely raising a ceiling; it is rebuilding the supports beneath it.