Ethereum’s Glamsterdam Bet: Scaling the Pipeline, Not Just the Block

Glamsterdam joins three constraints—validation time, execution visibility and state growth—into one scaling program. Editorial illustration created for this report.

Research date: 21 August 2026

Executive summary

Ethereum’s Glamsterdam upgrade, now planned for the fourth quarter of 2026, should be understood less as a conventional capacity increase than as a redesign of the machinery that makes higher capacity safe. Its core bargain is straightforward: the network can process substantially more work only if validators receive more time to check that work, clients receive a map of what the work touches, and users who create permanent state pay a price closer to its enduring hardware cost. Enshrined proposer-builder separation (ePBS), block-level access lists (BALs), and state-cost repricing are therefore complementary controls, not an arbitrary bundle of protocol features.

That distinction matters for institutions. A larger gas limit can temporarily expand supply, but without changes to propagation, execution and storage it can also increase missed attestations, reorganization risk and node requirements. Glamsterdam instead attacks those bottlenecks before—and alongside—future increases. The official Ethereum overview says the upgrade is scheduled for Q4 2026 and describes its goals as parallelization, expanded capacity and prevention of database bloat. An Ethereum Foundation engineering update reported a credible 200 million gas post-Glamsterdam floor, an end-to-end external-builder pipeline running across nearly all clients, and finalized repricing work at an April interoperability event. These are engineering targets and test milestones, not a mainnet throughput guarantee.

The upside is meaningful. ePBS removes full execution validation from the earliest, most time-sensitive part of a slot; BALs expose block dependencies that clients can use for parallel disk reads, faster synchronization and eventually parallel execution; repricing makes persistent state consumption more explicit. The costs are equally real. The block-production protocol becomes more complex, builders become native protocol actors, some state-creating operations become markedly more expensive, and implementation maturity across multiple clients remains the gating factor. The correct investment and risk posture is therefore neither “Glamsterdam solves scaling” nor “higher gas limits centralize Ethereum.” It is to watch whether the three legs mature together.

The thesis: capacity is a systems problem

Ethereum’s base layer has historically executed transactions sequentially and asked validators to perform several demanding tasks inside a narrow attestation window. Raising the gas limit without changing that pipeline is like widening a factory’s intake while leaving inspection and warehousing unchanged. More orders enter, but the slowest downstream station still determines safe throughput.

Glamsterdam’s design treats three resources separately. First is time: how long validators have to receive and validate a payload. Second is information: whether a client knows in advance which accounts and storage slots a block accesses. Third is persistence: how much permanent state the block adds to every full node’s database. The package makes each constraint more legible and manageable.

flowchart LR
    A[Higher L1 demand] --> B{Three bottlenecks}
    B --> C[Short validation window]
    B --> D[Opaque execution dependencies]
    B --> E[Persistent state growth]
    C --> F[ePBS separates commitment and payload]
    D --> G[BAL records touched state]
    E --> H[State creation repriced by footprint]
    F --> I[More credible capacity]
    G --> I
    H --> I
    I --> J[Higher gas limits with bounded node pressure]

This systems framing prevents a common analytical error. Glamsterdam is not expected to make every transaction cheaper immediately. The official overview says a separate proposal to reduce intrinsic gas could make a simple ETH transfer between existing accounts up to 71% cheaper, while BALs and ePBS prepare the network for capacity growth that may lower congestion costs over time. Conversely, operations that create accounts, storage slots or contract code are intentionally repriced upward. “Lower fees” is thus too coarse: the intended outcome is cheaper use of abundant resources and more accurate pricing of scarce, durable ones.

ePBS: buying time and removing trusted plumbing

Today, block proposers commonly outsource execution-payload construction to specialized builders through off-protocol infrastructure. The proposer commits to a blinded block, while intermediating relay software helps exchange the builder’s payload for payment. This arrangement has been economically important, but it inserts trusted middleware into a critical path and gives validators only a few seconds to process consensus, execution and data-availability work before attesting.

EIP-7732 moves this market into the protocol. A proposer includes a signed builder bid and commitment rather than the full execution payload in the initial beacon block. The builder subsequently reveals the payload; a Payload Timeliness Committee reports whether it arrived on time and whether the relevant data was available. Builder funds held in the beacon state make payment enforceable without relying on the relay to guarantee the exchange.

The crucial scaling effect is temporal. The EIP says ordinary validators currently face a four-second attestation deadline for both consensus and execution work. Under delayed validation, the next proposer receives six seconds and other validators roughly nine seconds to validate the execution payload. The ethereum.org Glamsterdam overview summarizes the propagation window as expanding from about two seconds to roughly nine seconds. The figures describe different portions of the slot, but the message is consistent: heavy execution work moves off the hottest part of consensus.

sequenceDiagram
    participant B as Staked builder
    participant P as Block proposer
    participant V as Validators
    participant T as Timeliness committee
    B->>P: Signed bid and payload commitment
    P->>V: Beacon block with commitment
    V-->>V: Validate consensus first
    B->>V: Reveal execution payload and data
    T->>V: Attest to timely availability
    V-->>V: Validate execution over longer window
    V->>V: Extend chain or reject invalid payload

For institutional users, this is not merely a validator optimization. A longer propagation and validation budget can support larger payloads and more blobs without making geographically or computationally disadvantaged validators miss duties at the same rate. Protocol-enforced payment also reduces one category of relay trust. Yet ePBS does not dissolve builder concentration. Search sophistication, order flow, latency and capital can still favor large builders; moving builders on-chain changes the rules of the market, not necessarily its industrial organization. EIP-7732 also adds new fork-choice states—full, skipped and empty slots—and new committee behavior. That enlarged state machine is why multi-client testing matters more than a headline throughput number.

BALs: turning execution into an observable dependency graph

Ethereum cannot safely parallelize arbitrary transactions simply because multiple CPU cores are available. Two transactions may read or write the same account or storage slot, creating dependencies whose order changes the result. A client needs a reliable map before it can schedule independent work concurrently.

EIP-7928 requires each block to carry a block-level access list describing the addresses and storage locations actually accessed, including reads that do not change state. That makes the block’s working set explicit. The official roadmap presents BALs as an input to faster sync, parallel disk reads and eventual parallel execution. In the near term, the practical advantage may be less glamorous but still valuable: clients can prefetch state and execute transactions in parallel groups where the dependency map permits it.

The data is not free. An empirical analysis attached to the EIP sampled 100 historical mainnet blocks and found a median compressed BAL size of 42.6 KB when reads were included; the 95th percentile was 73.7 KB. Storage reads and writes accounted for 85.3% of compressed size. Those observations are a limited historical sample, not a forecast for 200M-gas blocks. They nonetheless show the core trade: extra network bytes purchase explicit knowledge about execution. A separate proposal, EIP-8146, explores moving BALs into sidecars so their propagation does not weigh on the execution-payload critical path.

The upgrade’s architecture is multiplicative: more validation time is useful only if execution work is visible and permanent growth remains priced.

BALs also create a new consensus surface. Builders must produce correct lists, clients must verify them, and list size must be bounded. EIP-7928 links the number of recorded items to the block gas limit rather than allowing unbounded metadata. This is a recurring Glamsterdam pattern: expose a hidden resource, then meter it.

State repricing: the sustainability leg

Throughput and state growth are different. A swap uses compute and bandwidth now; a new account, storage slot or contract can impose database costs on nodes indefinitely. If both are priced through one coarse gas schedule, raising the gas limit can accelerate permanent growth even when hardware and client optimizations improve transient execution.

EIP-8037 proposes a standardized cost per state byte and separate accounting for state creation. Its model uses 1,530 gas per state byte, derived from a 150M reference gas limit and a design target of 120 GiB annual state growth at average half utilization. The target is a model input, not a promised outcome. At different fully utilized gas limits, the EIP presents worst-case modeled growth ranging from 80 GiB/year at 100M to 240 GiB/year at 300M.

The distributional effects are deliberate. The EIP estimates that the state-gas component for a new account rises from 25,000 to 183,600 gas, a new storage slot from 20,000 to 97,920, and deployment of a 24 kB contract from about 4.95M to 37.78M. Additional execution charges may apply. These figures are proposal estimates and can evolve before activation, but they make the policy direction unambiguous: users who leave a durable database footprint should bear more of its cost.

That could change application economics. Protocols that frequently create fresh storage, deploy contracts or onboard users through new accounts will face a larger gross gas bill unless they redesign, batch, reuse storage or move activity to rollups with different schedules. Meanwhile, a proposal to reduce intrinsic gas can lower the price of simple transfers between existing accounts. Glamsterdam therefore tilts incentives from state expansion toward state reuse—an architectural signal as much as a fee change.

What the evidence does—and does not—establish

The strongest evidence is implementation progress. The Ethereum Foundation’s May protocol update says a multi-client devnet ran the external-builder flow end to end across nearly all clients. It also reports agreement on a credible 200M post-Glamsterdam gas-limit floor and completion of repricing numbers. The official overview, updated on 6 August, moved the schedule language to Q4 2026 and lists additional EIPs being tested. Forkcast’s decisions tracker remains the best public index of All Core Developers decisions as specifications move.

None of this proves that mainnet will activate on a particular day, that validators will immediately vote the gas limit to 200M, or that transaction throughput will increase in direct proportion. Ethereum upgrades require client releases, test networks, stable specifications and operator readiness. The gas limit is also a validator parameter, not simply a hard-fork constant. Institutional planning should therefore distinguish four milestones: specification inclusion, multi-client interoperability, mainnet activation and subsequent validator adoption of higher limits.

flowchart TD
    A[Specifications and EIP scope] --> B[Multi-client devnets]
    B --> C{Stable under faults and load?}
    C -- No --> B
    C -- Yes --> D[Testnet activation]
    D --> E[Mainnet fork scheduled]
    E --> F[Mainnet activation]
    F --> G{Validators raise gas limit?}
    G -- Gradually --> H[Observed capacity and fee effects]
    G -- Hold --> I[Architecture active, capacity unchanged]

Implications for institutions and the ecosystem

For asset managers, the upgrade strengthens the case that Ethereum is pursuing L1 scaling without abandoning home-node constraints. That is strategically relevant because fee revenue, ETH burn, staking economics and rollup settlement demand all respond differently to capacity. More L1 supply can reduce congestion rents per transaction while increasing the volume the chain can settle. The net monetary effect cannot be inferred from capacity alone.

For validators and staking providers, operational readiness becomes the immediate concern. ePBS introduces builder registration, payload timing and new fork-choice behavior; larger blocks increase bandwidth and execution demands even if the protocol offers more time. Performance should be assessed at tail latency, under adverse networking and across minority clients—not only at average load.

For application teams, the new price gradient matters more than the aggregate gas limit. State-heavy designs should model repricing, while payments and applications that reuse existing state may benefit from cheaper intrinsic gas and greater capacity. Rollups may gain from an expanded blob budget enabled by the longer validation window, but Glamsterdam is not a substitute for L2 scaling. It improves the settlement layer on which rollups depend.

For block builders and MEV infrastructure, enshrinement changes interfaces and settlement guarantees. It may reduce relay trust and standardize access, but the competitive advantages of superior order flow and optimization remain. Monitoring builder share after activation will be essential to determine whether protocol access translates into a more contestable market.

Risks, counterarguments and signposts

The first counterargument is that complexity itself is a decentralization cost. ePBS introduces staked builders, timing attestations and asynchronous payload handling; BALs add data and verification; multidimensional state metering complicates estimation. A theoretically safer high-capacity design can still fail its decentralization objective if only a narrow set of teams can implement, operate or audit it reliably.

Second, repricing may push activity away rather than make it efficient. A five-to-eightfold increase in the state-gas component of common creation operations could disadvantage on-chain games, account factories or protocols with unavoidable state churn. Low base fees may soften the fiat impact, but low fees are not guaranteed. Wallets and RPC providers must update estimation, and the EIP notes compatibility considerations for pre-signed deterministic deployment factories on new networks.

Third, explicit dependencies do not instantly deliver parallel execution. BAL production, transmission and verification have overhead; realized client speedups depend on workloads and implementation. Institutions should demand benchmarks on production-like blocks, including worst-case BAL sizes and reorganization behavior.

Finally, “200M” can become a misleading focal point. It is a post-upgrade engineering floor reported by the EF team, not committed mainnet capacity on activation day. Better signposts are client diversity on devnets, fault-testing results, testnet stability, home-node resource measurements, builder concentration, missed-attestation rates and actual state growth after repricing.

Conclusion

Glamsterdam’s importance lies in its architecture of constraints. ePBS creates time, BALs create visibility, and state repricing creates a budget for persistence. Any one alone is insufficient: a longer validation window without dependency information leaves execution serial; parallelism without state discipline accelerates database growth; repricing without capacity improvements merely raises costs.

As of 21 August 2026, the project has moved beyond paper design: core features are running in multi-client environments, the public target is Q4, and engineers have articulated a credible path toward a 200M post-upgrade gas-limit floor. But credible is not inevitable. The institutional-quality conclusion is conditional: if multi-client testing shows that the three controls work together under adversarial load, Glamsterdam could be Ethereum’s most consequential L1 scaling upgrade since the move to proof of stake. If coordination or complexity delays one leg, the prudent outcome is to delay capacity rather than treat a larger block as success in itself.

Direct sources

• Ethereum.org: Glamsterdam overview, updated 6 August 2026

• Ethereum Foundation: Protocol Cluster Updates, May 2026

• Ethereum Foundation: Soldøgn interoperability recap

• EIP-7732: Enshrined Proposer-Builder Separation

• EIP-7928: Block-Level Access Lists

• EIP-7928 empirical BAL size analysis

• EIP-8037: State Creation Gas Cost Increase

• Forkcast: All Core Developers key decisions