Ethereum’s Glamsterdam Bargain: Scaling the Base Layer Without Pricing Out Its Verifiers

A stylized Ethereum diamond connecting block building and state economics

Lead illustration: Glamsterdam links three constraints that are often discussed separately—block propagation, execution parallelism, and the cost of permanent state.

Research date: 5 September 2026

Executive summary

Ethereum’s next planned protocol upgrade, Glamsterdam, is best understood not as a collection of isolated efficiency improvements but as a new capacity bargain. The protocol would make blocks easier to propagate, their data dependencies easier to inspect, and permanent state more expensive to create or access when those operations impose durable costs on node operators. The bargain is straightforward: Ethereum can raise useful throughput only if it simultaneously protects the ability of ordinary hardware to verify the chain.

That thesis matters because the upgrade is now moving from design into operational reality. Ethereum.org lists Glamsterdam as being tested on devnets, targets mainnet for the fourth quarter of 2026 without a confirmed date, and identifies the Sepolia fork on 28 September as the next milestone. Scope is described as frozen, although the meta-EIP remains a draft and can still change. Those qualifications should temper any investment or capacity forecast: Glamsterdam is near enough to demand preparation, but not final enough to treat every parameter as settled.

Three mechanisms carry most of the strategic weight. Enshrined proposer-builder separation (ePBS) brings the exchange between block builders and proposers into Ethereum’s consensus rules and expands the payload propagation window from roughly two seconds to about nine. Block-level access lists (BALs) provide an upfront map of state touched by a block, enabling parallel disk reads and creating a foundation for parallel execution and executionless state updates. Finally, gas repricing for state creation and access aligns fees more closely with storage and hardware work, making higher gas limits less likely to convert directly into uncontrolled database growth.

The near-term risk is equally important. On 24 August, Ethereum Foundation research and testing teams warned that historical transaction replay had identified a small set of contracts that may fail or degrade under the new gas schedule. The large majority were unaffected, and many flagged cases can be repaired by raising supplied gas limits. But contracts that embed fixed gas assumptions, as well as wallets, indexers and estimators built around hard maximums, face genuine migration work. Glamsterdam’s promise is therefore conditional: infrastructure must absorb a deliberate breaking change before users receive the capacity dividend.

The upgrade in context

Glamsterdam follows Fusaka, which activated on 3 December 2025 and introduced PeerDAS as its flagship scaling feature. PeerDAS reduced the requirement for every node to hold all blob data, allowing nodes to sample and custody subsets instead. Fusaka primarily enlarged Ethereum’s data-availability runway for rollups; Glamsterdam turns attention toward the base layer’s execution and verification pipeline. This is an evolution from “how much data can the network make available?” to “how much work can the network safely coordinate and verify?”

The distinction is essential for institutions. Rollup capacity alone does not eliminate L1 settlement congestion, state growth, synchronization costs, or dependencies in the block-building market. A high-value settlement layer must remain reliably auditable under stress, not simply advertise a high nominal gas ceiling. Glamsterdam’s architecture recognizes that propagation time, database access, block construction, and validator participation are coupled constraints.

flowchart LR
    F[Fusaka: PeerDAS<br/>more blob headroom] --> G[Glamsterdam]
    G --> P[ePBS<br/>longer payload propagation]
    G --> B[Block-level access lists<br/>visible dependencies]
    G --> S[State repricing<br/>resource-aligned fees]
    P --> C[Safer capacity increases]
    B --> C
    S --> C
    C --> O[Institutional outcome:<br/>higher capacity with verifiability]

This is why the upgrade should not be reduced to a transaction-per-second claim. Ethereum.org frames its three goals as parallelization, capacity expansion, and sustainable database growth. Each is a check on the others. Larger payloads without enough propagation time increase centralization pressure; parallel execution without dependable dependency information creates correctness risks; higher limits without state pricing transfer today’s cheap transactions into tomorrow’s node costs.

Evidence table: what changes, and why it matters

Layer or constituency	Scheduled change	Direct effect	Institutional interpretation
Block market	ePBS / EIP-7732	Protocol-level builder–proposer exchange; roughly 2-to-9-second propagation-window expansion	Less reliance on trusted relays for the core exchange and more room for larger payloads
Execution and sync	BALs / EIP-7928 plus eth/71 exchange	Declares state accesses and post-execution values; enables parallel reads and faster state updating	Better scaling path, but new data and networking behavior must be supported consistently by clients
State sustainability	EIP-8037	Prices state creation by its durable footprint; targets 120 GiB annual growth under the described model	Capacity becomes explicitly constrained by the cost of keeping verification accessible
State access	EIP-8038	Reprices storage and account-access operations to reflect contemporary state size and hardware performance	Narrows denial-of-service and underpricing risk, while changing application gas assumptions
Staking liquidity	EIP-8061	Separates lanes and expands exit and consolidation churn	At current staking levels, ethereum.org estimates about 4× exit and 2× consolidation capacity, with a shorter weak-subjectivity period
Transaction pricing	EIP-2780	Decomposes the flat intrinsic charge into resource-based components	A plain ETH transfer to an existing account remains 21,000 execution gas; creating a new account adds state gas, while simpler zero-value paths can cost less

The numbers above are proposal and roadmap parameters, not observed mainnet outcomes. That distinction is especially important for the 120 GiB state-growth target, the 200 million gas-limit floor discussed in roadmap material, and “up to” transaction-cost reductions. Markets often capitalize prospective capacity before engineers validate behavior in public testnets. A disciplined reader should instead treat Sepolia and Hoodi performance, client diversity, and application replay results as gates.

ePBS changes the critical path

Today’s specialized block-building supply chain is economically useful but partly mediated by software outside Ethereum’s protocol. Builders assemble valuable execution payloads, relays transmit bids and blocks, and proposers select offers. Enshrining the essential exchange does not abolish specialization or every relay. It makes the basic payload-for-payment relationship enforceable through the protocol, while optional middleware may continue to provide richer features.

The capacity implication comes from timing. The existing hand-off compresses transaction dissemination and execution into a roughly two-second “hot path.” EIP-7732 introduces separate consensus and execution-payload deadlines and a Payload Timeliness Committee, letting validators attest to the beacon block and payload timeliness separately. Ethereum.org says this expands the propagation window to about nine seconds. More propagation time permits larger payloads without assuming that every validator has elite connectivity.

Comparison of the current hot path and the wider ePBS propagation window

Editorial comparison: ePBS moves the core exchange into protocol logic and gives execution payloads a materially wider distribution window; it does not guarantee that all off-protocol middleware disappears.

sequenceDiagram
    participant B as Builder
    participant P as Proposer
    participant C as Consensus validators
    participant T as Payload Timeliness Committee
    B->>P: Commit bid / payload relationship
    P->>C: Propose consensus block
    C-->>C: Attest to consensus block
    B->>T: Reveal and propagate execution payload
    T-->>C: Attest to payload timeliness
    Note over B,T: Dual deadlines widen the payload window<br/>and separate consensus from execution timing

For staking providers, this is not purely beneficial abstraction. Pool architectures must support trustless monitoring and revised builder selection. For builders, protocol inclusion may lower relay trust risk while raising the importance of precise consensus compliance. For institutions buying blockspace, the improvement is indirect but meaningful: a block market with fewer mandatory trusted intermediaries and a less compressed propagation path is a better foundation for predictable settlement.

BALs turn hidden dependencies into a scaling primitive

Ethereum execution is difficult to parallelize because a node does not know in advance which accounts or storage slots a transaction will touch. Two apparently independent transactions may collide on the same state. BALs attach a block-wide account of accesses and final values, with a commitment in the block header. Nodes can preload relevant data, run non-overlapping work concurrently, and update state from declared results rather than always replaying every operation during synchronization.

The immediate benefit is parallel disk access and improved syncing, not magical infinite execution. Ethereum.org explicitly describes BALs as setting the stage for validators to process transactions in parallel. The eth/71 networking extension matters because a data structure that peers cannot efficiently exchange does not improve distributed verification. Institutional analysis should therefore watch client interoperability and the size and propagation behavior of these lists, not just benchmark results from a single implementation.

BALs also change the shape of verification. Executionless state updating could reduce the work needed to reach current state, but users that require full semantic assurance may still choose execution. The architecture creates a spectrum of synchronization strategies rather than replacing verification with trust. That optionality can broaden participation if it is implemented consistently.

State repricing is the political economy of scaling

Capacity increases are attractive because their benefits are immediate and visible. State growth is the liability that remains. New accounts, storage slots, and deployed code become part of a database that nodes must maintain. If gas prices understate that burden, application users receive a subsidy financed by future node operators through storage, memory, and access latency.

EIP-8037 creates more uniform state-creation pricing and a separate accounting reservoir. Ethereum.org says its fixed cost per state byte targets a predictable 120 GiB per year growth rate, while the roadmap discusses scaling toward a 200 million gas-limit floor and testing at a 150 million reference limit. EIP-8038 updates prices for state access based on measured performance, addressing operations whose database work is no longer reflected by constants last broadly adjusted in 2021.

This is not simply a fee increase. The current EIP-2780 draft decomposes the old flat intrinsic charge into resource-based components. A plain ETH transfer to an existing externally owned account remains at 21,000 execution gas, while a transfer that creates an account additionally consumes state gas; lighter zero-value or self-transfer paths can cost less. The coherent principle is “price the resource, not the transaction category”: lightweight actions become cheaper where appropriate, while durable database creation and expensive reads become dearer. This current specification is more precise than the broader “up to 71%” language still visible on the overview page.

The migration window is the story now

The public schedule makes September a decision month. The stable Platåberget testnet, announced on 17 August, is intended to give the community several months to test post-Glamsterdam behavior. Sepolia is scheduled for 28 September; mainnet remains an unconfirmed Q4 target. The correct operational posture is readiness without false precision.

Ethereum Foundation teams replayed historical mainnet transactions under the proposed repricing and grouped outcomes into unchanged, successful with differences, fixable with a higher gas limit, and potentially broken. Most transactions were unchanged. Potentially broken contracts commonly depend on fixed stipends, hard-coded call gas, branching on remaining gas, or presigned transactions with fixed limits. Infrastructure using cached constants or a hard-capped maximum can underestimate required gas.

flowchart TD
    A[Replay or test L1 behavior] --> B{Outcome under new pricing}
    B -->|Unchanged| C[Monitor testnet and client releases]
    B -->|Succeeds differently| D[Review accounting and user experience]
    B -->|Out of gas at old limit| E[Raise supplied limits and retest]
    B -->|Still fails| F[Refactor fixed-gas assumptions]
    E --> G[Validate on Platåberget / public testnets]
    F --> G
    G --> H{Client and application readiness}
    H -->|Adequate| I[Mainnet activation candidate]
    H -->|Defects remain| J[Fix, delay, or revise parameters]

Implications by stakeholder

For asset managers and allocators, Glamsterdam strengthens the case that Ethereum’s base layer is being engineered as durable settlement infrastructure rather than surrendering all scale to rollups. Yet it also enlarges protocol-change risk in the near term. Exposure models should distinguish sustainable capacity from temporary fee compression and should not assume the mainnet date.

For exchanges, custodians, and payment providers, gas estimation and transaction construction are the priority. Simple transfers may become cheaper, but withdrawal pipelines often interact with contracts, batching systems, and fixed policy limits. Successful historical behavior is not sufficient evidence when gas semantics change.

For staking operators, ePBS monitoring changes and EIP-8061’s faster exits reshape operations. Ethereum.org estimates roughly fourfold exit capacity and twofold consolidation capacity at current staking levels, but notes a security trade-off: the weak-subjectivity period falls from about 15.7 days to about seven. Faster liquidity therefore raises the premium on checkpoint hygiene for nodes returning after downtime.

For application teams, the lesson is narrower than “rewrite everything.” Most contracts appear unaffected; indiscriminate migrations create their own risk. Teams should prioritize contracts with fixed gas behavior, state-intensive workloads, account creation, or reliance on outdated estimation infrastructure.

Risks and counterarguments

First, enshrining a market structure can fossilize assumptions. ePBS reduces mandatory trust in relays, but specialized builders may remain concentrated, and off-protocol middleware may persist. Protocolization improves enforceability; it does not automatically decentralize economic supply.

Second, declared access lists add bandwidth, implementation, and correctness complexity. Their long-run parallelization benefit depends on interoperable clients and honest, efficiently validated declarations. Gains measured on controlled devnets may not translate linearly to diverse mainnet workloads.

Third, repricing can strand immutable contracts. “A small set” is reassuring at ecosystem scale but irrelevant to a user whose critical application is in that set. Raising frontend gas limits does not repair logic that fundamentally assumes a stipend or signs fixed-limit transactions.

Fourth, a higher gas limit is not equivalent to sustainable demand. If L1 activity does not use the capacity, validator costs may rise without commensurate fee or utility gains. Conversely, a sudden demand response could expose bottlenecks in networking, builders, RPC services, or state growth that component tests missed.

Finally, the timeline is provisional. The official roadmap says Q4 2026 and no confirmed date. Scope can still change. Any claim that Glamsterdam “will launch” on a specific mainnet day exceeds the evidence available on 5 September.

Conclusion

Glamsterdam’s importance lies in coupling expansion with constraints. ePBS buys propagation time and reduces a core relay trust dependency; BALs expose the state relationships needed for parallel work; repricing makes permanent storage and costly access pay closer to their resource burden. Together they form a plausible architecture for increasing L1 capacity without quietly converting decentralization into a hardware luxury.

But the bargain has an entrance fee: a controlled compatibility break. The decisive evidence over the coming weeks will not be promotional throughput figures. It will be whether clients exchange and validate BALs consistently, whether the new block-production path behaves under public-testnet stress, and whether affected applications eliminate fixed-gas assumptions before activation. Sepolia on 28 September is therefore more than a calendar milestone; it is the first widely visible test of whether Ethereum can scale its base layer while keeping verification economically open.