Glamsterdam’s real test: can Ethereum scale its base layer without pricing out verification?

Glamsterdam reorganizes the path from block construction to validation. Illustration created for this report.

Published 12 October 2026 — Research report

Executive summary

Ethereum’s Glamsterdam upgrade activated on the Sepolia testnet on 6 October at 13:53:36 UTC. That is a consequential public rehearsal, not a mainnet launch: the Ethereum Foundation’s announcement leaves both Hoodi and mainnet dates undecided. The distinction matters. Markets tend to translate protocol upgrades into a simple promise of more throughput or lower fees; Glamsterdam is better understood as an attempt to redesign the conditions under which Ethereum can safely raise capacity.

The upgrade’s thesis has three mutually dependent parts. Enshrined proposer-builder separation (ePBS, EIP-7732) moves the builder–proposer handoff into consensus and separates consensus validation from execution validation, giving payloads more time to propagate. Block-level access lists (BALs, EIP-7928) make a block’s state dependencies explicit, enabling parallel disk reads, execution, and state-root computation. A group of gas reforms, led by EIP-8037 and EIP-8038, prices state creation and access more deliberately so higher throughput does not quietly turn into unsustainable database growth. The package is less a turbo button than a new production line with better scheduling, a manifest of what each job touches, and a separate bill for permanent storage.

Our assessment is constructive but conditional. Glamsterdam could make a substantially larger L1 practical while reducing reliance on trusted builder relays and improving the auditability of execution. It could also lower the intrinsic cost of simple transfers and improve several developer and staking workflows. But the key evidence is not yet a headline gas-limit number. It is whether diverse clients remain stable under sustained load; whether builders reliably reveal payloads; whether BAL overhead and accuracy behave as designed; and whether repriced operations break hidden assumptions in deployed applications. Sepolia is where those claims begin to meet reality. It is not where they become proven.

The upgrade is a coordinated architecture, not a collection of features

Glamsterdam combines “Amsterdam” on Ethereum’s execution layer with “Gloas” on its consensus layer. The Ethereum Foundation’s testnet announcement lists 16 scheduled core EIPs, plus supporting networking and informational proposals. That breadth invites checklist reporting, but the upgrade is most coherent when read as a response to one constraint: increasing a block’s workload is useless if builders cannot deliver it in time, validators cannot verify it in time, or nodes cannot afford to store the resulting state.

The official Glamsterdam roadmap page therefore frames the package around parallelization, capacity, and sustainable state growth. It says ePBS expands the execution-payload propagation window from roughly two seconds to roughly nine seconds. It also describes a path toward a 200 million gas-limit floor, while noting that developers have used a 150 million reference limit to derive state pricing. Those are design targets and test parameters, not a promise that mainnet will immediately process a fixed multiple of today’s transactions or that user fees will fall proportionally.

flowchart LR
    A[Higher L1 demand] --> B{Can blocks be delivered and checked?}
    B -->|Propagation bottleneck| C[ePBS separates consensus and payload timing]
    B -->|Serial state bottleneck| D[Block-level access lists expose dependencies]
    B -->|Database-growth bottleneck| E[State creation and access are repriced]
    C --> F[More room for larger payloads]
    D --> G[Parallel reads, execution and state-root work]
    E --> H[Capacity bounded by durable resource cost]
    F --> I[Potentially higher sustainable L1 throughput]
    G --> I
    H --> I

This dependency is the central editorial point. ePBS without faster verification merely moves the bottleneck. BALs without state pricing could accelerate growth in the burden every full node carries. More punitive state pricing without added capacity could protect nodes while making applications harder to use. Glamsterdam’s value is in the combination.

ePBS moves a critical market inside the protocol

Ethereum’s block supply chain already distinguishes between the validator selected to propose a block and specialized builders that assemble transaction payloads. Today, much of that exchange is mediated by out-of-protocol software and trusted relays. EIP-7732 formalizes the relationship: a proposer includes a builder’s signed commitment, the builder later reveals the execution payload, and a payload-timeliness committee reports whether the payload and associated blob data arrived on time. Builder payments become protocol-handled rather than resting on the same relay trust assumptions.

For institutions, this has two important meanings. First, a systemically important part of Ethereum’s market structure becomes governed by explicit consensus rules. That should improve standardization and reduce the relay’s role as a trusted counterparty. Second, the execution payload is no longer forced through the same narrow validation “hot path” as consensus. More time for propagation can make larger blocks and more blob data compatible with validators reaching consensus on schedule.

But “enshrined” is not synonymous with “risk-free.” It shifts complexity into the base protocol and creates new duties, interfaces, incentives, and failure modes. A builder that commits but withholds its payload can leave a slot without an execution payload. A 2025 paper, The Free Option Problem of ePBS, models an incentive for builders to do exactly that when external prices move in their favor. Using historical blocks and an eight-second option window, the authors estimate exercise would be profitable for 0.82% of blocks on average and as much as 6% on high-volatility days. Those are model-based estimates rather than observations of the final Glamsterdam network, but they identify a testable liveness risk: the architecture must be judged most carefully during volatile markets, not only in calm test conditions.

BALs turn hidden dependencies into a parallel work plan

Ethereum transaction execution is conventionally sequential because a client cannot safely run transactions concurrently unless it knows which accounts and storage slots each transaction will touch. Optional transaction access lists did not solve this because they were not enforced. EIP-7928 introduces an enforced list at block level, recording accessed addresses and storage locations together with state changes.

That record has several uses. Clients can prefetch relevant state from disk in parallel, identify transactions whose dependencies do not conflict, calculate portions of the post-state in parallel, and reconstruct state changes without rerunning every transaction. The proposal is strict: a missing or spurious entry can invalidate a block. That strictness turns the BAL from a hint into a consensus-grade execution witness, but it also makes generation, propagation, storage, and validation of the list part of the critical path.

BALs should therefore be evaluated as an enabling data structure, not an instant throughput claim. Different client teams may exploit the same list with different scheduling and storage strategies; real performance will depend on implementation quality, hardware, workload composition, and how often transactions contend for the same state. A burst of independent transfers is easier to parallelize than intense trading around the same pool. The EIP creates the possibility of parallel work; it does not repeal data dependencies.

Capacity, verifiability and state sustainability form one constraint system. Illustration created for this report.

Gas reform makes storage a first-class constraint

More execution capacity can amplify state growth—the accounts, contract code, and storage that nodes must retain. The existing one-dimensional gas schedule mixes temporary computation with durable database costs. EIP-8037 proposes distinct execution-gas and state-gas dimensions. Users still pay a total expressed through the transaction’s gas budget, but block fullness is governed by whichever resource dimension is the bottleneck. The roadmap describes a cost-per-state-byte calibration targeting a predictable 120 GiB of annual state growth.

This is economically important. A blockspace market that prices computation but underprices permanent state effectively asks future node operators to subsidize today’s applications. Separating the meters makes that externality visible and gives the protocol room to raise execution capacity without granting an equal, unpriced expansion of storage demand. It also means headline claims such as “more gas equals cheaper transactions” are incomplete. A lightweight transfer between existing accounts may become cheaper under EIP-2780—the official roadmap estimates a reduction of up to 71% in intrinsic gas—while operations that create persistent state can become more expensive.

That differentiation is a feature of the design, not a contradiction. It signals that Ethereum is trying to price transactions by the resources they consume rather than subsidize every activity equally. For application economics, however, averages will conceal distributional effects. Payments, contract deployment, account creation, calldata-heavy applications, and state-intensive protocols may experience materially different outcomes.

What Sepolia does—and does not—establish

The upgrade activated at Sepolia epoch 353,024, slot 11,296,768. The Foundation published compatible releases across six consensus clients and six execution clients, an encouraging sign of implementation breadth. It also noted that some validator clients required explicit configuration to propose a 200 million gas limit rather than defaulting to 60 million. That operational detail illustrates why observed testnet capacity cannot be reduced to a protocol maximum: validator preferences, client defaults, builder behavior, and workload all shape the blocks that are actually produced.

timeline
    title Glamsterdam evidence path as of 12 October 2026
    section Completed
      Scope frozen for testing : Core and supporting EIPs coordinated
      6 Oct — Sepolia activation : Public multi-client rehearsal begins
    section Evidence to gather
      Sustained high-load operation : Payload delivery and BAL correctness
      Adversarial and volatile conditions : Withholding, timing and recovery behavior
      Application testing : Gas estimation and fixed-stipend assumptions
    section Not yet scheduled
      Hoodi activation : Validator-focused rehearsal
      Mainnet activation : Requires a separate announcement

Sepolia can reveal consensus splits, client bugs, payload-timing failures, unexpected bandwidth pressure, inaccurate BAL generation, and application incompatibilities. It is less informative about production MEV incentives because test assets lack mainnet-scale economic value. Hoodi should add validator-focused operational evidence, but no single testnet can reproduce mainnet’s liquidity, adversarial opportunity, or heterogeneous infrastructure.

The correct milestone framework is therefore evidence-based rather than calendar-based. A mainnet-readiness case should include stable finality across clients; high payload-reveal rates at elevated load; no persistent client outliers; manageable CPU, memory, disk, and bandwidth requirements; correct BAL production across diverse transactions; and application evidence showing that gas estimation and contract behavior survive repricing. The absence of a mainnet date is prudent, not a sign of failure.

Implications for the Ethereum ecosystem

For validators and staking providers, ePBS changes core duties and monitoring. Operators will need compatible consensus and execution clients and must understand builder selection, payload attestations, and gas-limit configuration. Longer propagation time can reduce one source of timing pressure, but the system also introduces more protocol states to observe. Client diversity becomes even more valuable because a bug in BAL handling or payload logic can have consensus consequences.

For builders and relays, the economic center of gravity changes. Relay trust is reduced, but sophisticated block construction remains. Builders may need protocol registration, capital, and robust reveal infrastructure. The open question is whether enshrinement broadens contestability or whether operational and capital requirements reinforce concentration among a small set of builders. Builder count alone will not answer that; order-flow access and winning-block share matter.

For application teams, repricing is the near-term risk. The Foundation explicitly warns that contracts relying on fixed gas stipends, hardcoded gas limits, or assumptions about remaining gas may need changes. Teams should interpret cheaper simple transfers as a narrow claim, not a universal fee cut. They also gain useful features beyond the headline architecture, including ETH transfer logs, a deterministic deployment factory, and a higher maximum contract size, but those benefits do not eliminate the need to test.

For rollups, stronger L1 execution does not reverse Ethereum’s rollup strategy. ePBS’s longer payload window can accommodate more blob data, while a more capable settlement layer can serve rollups and direct L1 activity simultaneously. The relevant question is not “L1 or L2?” but whether base-layer capacity, data availability, and rollup execution scale without compromising independent verification.

For ETH holders, the Sepolia activation requires no asset conversion or mainnet action. Any request to “upgrade” ETH for Glamsterdam is a scam. The investment implication is similarly restrained: an upgrade can improve the network’s long-run productive capacity, but testnet activation is not evidence of immediate fee revenue, demand, or price impact.

Risks and counterarguments

The strongest counterargument is complexity. Glamsterdam changes block construction, consensus timing, execution metadata, networking, gas accounting, and developer-visible behavior in one coordinated fork. Each component may be defensible while their interaction enlarges the space for implementation bugs. Multi-client testing reduces this risk but does not eliminate correlated misunderstandings of a shared specification.

Second, protocolizing proposer-builder separation may harden today’s builder model before the market’s decentralization problems are solved. Removing trusted relays is valuable, yet builder concentration, private order flow, and censorship pressures can persist at a different layer. The protocol can make the auction more credible without making the market competitive.

Third, BALs impose overhead. Their benefits must exceed the cost of building, transmitting, checking, and storing them. Workloads with heavy contention may yield limited parallelism. The correct comparison is end-to-end validation time and node resource use, not an isolated benchmark of parallel execution.

Finally, state pricing is politically and economically difficult. Durable storage is genuinely costly, but repricing changes who pays. Protocols designed around old gas relationships may face higher costs even as simple transfers get cheaper. If calibration is too low, state growth remains a threat; if too high, useful applications are discouraged. The 120 GiB annual target is a governance choice expressed through engineering, and it should be monitored as such.

Conclusion

Glamsterdam is important because it treats Ethereum scaling as a systems problem. It aligns the block-production market, the execution dependency graph, and the economics of permanent storage around a larger capacity envelope. No single component delivers the thesis: ePBS creates time, BALs create a plan for parallel work, and multidimensional gas protects the database that makes verification possible.

Sepolia’s activation moves that design from specification toward observable engineering. The next question is not whether Ethereum can display a 200 million gas limit on a testnet. It is whether a diverse, permissionless network can deliver large payloads on time, verify them across independent clients, keep state growth bounded, and preserve credible participation under adversarial economic conditions. Until Hoodi and mainnet are separately scheduled—and until sustained test evidence accumulates—Glamsterdam should be regarded as a promising architectural bet in public trial, not a completed scaling victory.

Direct sources

• Ethereum Foundation — Glamsterdam Testnet Announcement

• Ethereum.org — Glamsterdam roadmap and overview

• EIP-7732 — Enshrined Proposer-Builder Separation

• EIP-7928 — Block-Level Access Lists

• EIP-8037 — State Creation Gas Cost Increase

• EIP-2780 — Resource-based intrinsic transaction gas

• Mazorra et al. — The Free Option Problem of ePBS