Glamsterdam’s real test: can Ethereum scale verification, not just execution?

Glamsterdam moves Ethereum’s scaling debate from a single gas-limit number to the architecture of how blocks are built, propagated, and checked. Editorial illustration.

Research date: 3 October 2026 · Upcoming milestone: Sepolia activation on 6 October 2026 at 13:53:36 UTC

Executive summary

Ethereum’s Glamsterdam upgrade is scheduled to reach Sepolia on 6 October, its first public-testnet activation. The Ethereum Foundation’s announcement fixes the Sepolia fork at epoch 353,024 and slot 11,296,768, while leaving Hoodi and mainnet dates undecided. That distinction is essential: this is a high-information rehearsal, not a mainnet launch.

The upgrade’s importance lies in the way its major components reinforce one another. Enshrined proposer-builder separation (ePBS) moves the builder-proposer exchange into consensus and lengthens the effective window for payload propagation and validation. Block-level access lists (BALs) make a block’s state dependencies explicit, opening parallel paths for disk reads, transaction validation, and state-root computation. Repricing state creation and access makes higher capacity less likely to externalize permanent database costs onto node operators. Glamsterdam is therefore best understood as a three-part attempt to scale verification capacity: more room in a block matters only if ordinary nodes can receive, understand, and validate it safely.

Our thesis is cautiously constructive. The design is more coherent than a simple throughput increase because it addresses time, data dependencies, and long-run storage together. Yet coherence on paper is not operational proof. ePBS creates new duties, timing rules, builder balances, and failure modes; BALs add data and validation work; repricing changes assumptions embedded in a small but consequential set of contracts. Sepolia should be judged by whether diverse clients and infrastructure preserve liveness and convergence under stress—not merely by whether the fork finalizes.

What is known—and what is not

Why the upgrade is architectural

Ethereum’s recent scaling narrative has often been summarized as “more blobs for rollups” or “a higher L1 gas limit.” Glamsterdam tackles a more basic constraint: the critical path by which a distributed network agrees on a block and then proves to itself that the block is valid. A larger payload is not useful if it arrives too late, serial execution overruns the slot, or state growth makes node operation progressively less accessible.

The official Glamsterdam roadmap page frames three goals: parallel processing, expanded capacity, and sustainable database growth. These are not independent feature lanes. They form a control system. ePBS changes when work happens; BALs clarify what data the work touches; gas repricing disciplines how much persistent burden demand may create.

flowchart LR
    A[Demand for more L1 capacity] --> B[ePBS: more propagation and validation time]
    A --> C[BALs: explicit state dependencies]
    A --> D[Resource-aligned gas pricing]
    B --> E[Larger payloads become more practical]
    C --> F[Parallel reads, validation, and state-root work]
    D --> G[State growth remains economically bounded]
    E --> H[Higher verifiable throughput]
    F --> H
    G --> H
    H --> I{Can diverse nodes keep up?}
    I -->|Evidence says yes| J[Candidate for later testnet and mainnet rollout]
    I -->|Evidence says no| K[Tune, fix, or delay]

That last decision node is the institutional lens. Protocol roadmaps express intent; testnets generate evidence. Investors, operators, and application teams should resist treating scheduled inclusion as equivalent to production readiness.

ePBS: replacing a trusted hand-off with protocol rules

Most Ethereum proposers already outsource execution-payload construction to specialized builders. Today that exchange depends on off-protocol software and relays. EIP-7732 changes the sequence: a builder commits to an execution payload and a payment; the proposer includes the signed commitment; the builder subsequently reveals the payload. A payload timeliness committee attests whether the correct payload and associated blob data appeared on time. The protocol can deduct the committed payment from the builder’s consensus-layer balance.

The key scaling effect is temporal. Consensus validation no longer has to wait for full execution validation in the most compressed part of the slot. Ethereum.org says the effective propagation window can expand from roughly two seconds to roughly nine. This is not a promise that throughput immediately triples or that fees mechanically fall. It is headroom: the system can contemplate larger payloads without forcing validators to complete all expensive checks in the original hot path.

There is also a trust reduction. A fair exchange between proposer and builder becomes a protocol property rather than a relay-mediated convention. But “enshrined” does not mean “complexity disappears.” It relocates complexity into consensus. Builders become in-protocol, staked entities; clients track commitments, payload availability, and pending payments; validators acquire committee duties and new interfaces. The relay trust surface shrinks, while the importance of correct client implementation and timing behavior rises.

sequenceDiagram
    participant B as Builder
    participant P as Proposer
    participant C as Consensus network
    participant T as Timeliness committee
    participant V as Validators
    B->>P: Signed payload commitment and bid
    P->>C: Beacon block carrying commitment
    C-->>V: Consensus block propagates
    B->>C: Reveal execution payload and blob data
    T->>C: Attest timely reveal and availability
    V->>V: Validate execution before next attestation deadline
    C->>P: Settle protocol-enforced builder payment

The meaningful test is adverse behavior. Does the network remain live when builders reveal late, reveal malformed payloads, or fail to reveal? Do different consensus and execution client combinations agree on edge cases? Can operators observe the new failure states quickly enough? A clean activation under normal traffic is necessary, but fault injection and client diversity provide stronger evidence.

BALs: a map of state dependencies

Ethereum transactions appear independent until they touch the same account or storage slot. Without advance knowledge of those dependencies, clients tend to discover conflicts through execution, encouraging a serial pipeline. EIP-7928 introduces enforced block-level access lists recording accounts and storage locations accessed during the block, together with post-transaction changes.

The value is not simply “parallel execution.” BALs can support parallel disk reads, transaction validation, state-root calculation, and even state reconstruction without re-executing transactions. Because the list must be complete and accurate—and missing or spurious entries can invalidate a block—it is consensus-critical metadata, not a performance hint.

That creates a trade-off. The network gains a structured account of dependencies, but blocks acquire additional data and clients must build, transmit, store, and validate it. Parallel speedups depend on workloads, hardware, and implementation quality; contended transactions will not magically become parallel. Investors should therefore treat benchmark maxima skeptically. The relevant distributions are block-level access-list size, validation latency by client, bandwidth overhead, and performance on commodity hardware.

The upgrade’s three pillars address different bottlenecks. Their value comes from working as a system, not from isolated headline performance.

Gas repricing: capacity needs a budget

Higher block limits expand demand for computation and persistent state. If gas prices undercharge costly operations, users receive a subsidy whose bill appears as larger databases, slower access, and more demanding node hardware. Glamsterdam’s repricing proposals attempt to align the fee schedule with current resource costs.

EIP-8037 targets a standardized cost per new state byte and separately meters state creation. Its motivation cites a Geth state database of roughly 390 GiB in January 2026 and daily new state rising from about 105 MiB to 326 MiB after the block gas limit moved from 30 million to 60 million. The proposal targets about 120 GiB of annual state growth at a reference 150 million gas block. These are model inputs and observed estimates, not guarantees: usage can respond nonlinearly to price and capacity.

EIP-8038 updates state-access charges that were last materially calibrated in the 2021 Berlin fork. It separates access, write, and creation components so charges better reflect database reads and writes as state grows. Together, the two proposals make an important policy statement: cheap execution should not be purchased by silently degrading the verifying edge of the network.

The transition has compatibility costs. The Foundation’s repricing impact analysis reports that the large majority of replayed historical transactions were unaffected, while a small set depended on hardcoded gas assumptions. Most flagged cases were fixable by raising the supplied gas limit; potentially broken patterns included fixed stipends, hardcoded call gas, branches on remaining gas, and presigned transactions with fixed limits. “Small set” should not be confused with “zero operational risk”: a low-frequency contract can still be economically important or deeply integrated.

Sepolia as an evidence gate

The 6 October fork should be evaluated across four layers. First is consensus health: participation, finality, reorganization behavior, and agreement among client implementations. Second is builder-market behavior: successful commitment and reveal, timeliness attestations, payment settlement, and graceful handling of missing payloads. Third is execution performance: BAL size and propagation overhead, validation latency, state-root computation, and resource use. Fourth is application compatibility: gas-estimation accuracy and transaction failure patterns after repricing.

flowchart TD
    S[Sepolia activates Glamsterdam] --> A{Consensus and finality healthy?}
    A -->|No| X[Diagnose client divergence or timing failure]
    A -->|Yes| B{Builder commit-reveal robust?}
    B -->|No| Y[Adjust duties, interfaces, or incentives]
    B -->|Yes| C{BAL overhead acceptable across clients?}
    C -->|No| Z[Optimize encoding, propagation, or validation]
    C -->|Yes| D{Repricing compatibility understood?}
    D -->|No| W[Expand testing and application remediation]
    D -->|Yes| E[Proceed to later testnet evaluation]
    E --> F[Mainnet decision only after accumulated evidence]

This framework also prevents a common category error: Sepolia success does not determine a mainnet date. The Foundation explicitly says Hoodi and mainnet activation remain to be decided. Sepolia’s lower economic stakes, different activity mix, and smaller builder ecosystem limit how fully it can reproduce mainnet conditions. Hoodi and targeted stress testing are therefore not ceremony; they are part of the evidence chain.

Implications for institutions and ecosystem participants

For validators and staking providers, Glamsterdam expands the operational surface. Both execution and consensus clients must be compatible, and builder-related monitoring becomes mission-critical. Client diversity matters even more when a large consensus change introduces shared edge cases. Service-level agreements should distinguish consensus uptime from successful payload duties rather than hiding both behind a single validator-performance number.

For builders and relays, ePBS changes the business boundary. Relays may lose their role as trusted exchange intermediaries, but specialized block construction does not vanish. Competitive advantage shifts toward reliable payload delivery, capital efficiency for builder balances, and robust connectivity. Market concentration remains a concern: protocolizing the exchange makes it safer, but it does not guarantee a competitive builder market or censorship resistance.

For applications, wallets, and RPC providers, the immediate issue is estimation rather than headline fee direction. A simple ETH transfer may become cheaper under the broader gas changes, while state-heavy actions become more expensive. Aggregate “gas is down” claims will conceal this dispersion. Systems that cache constants or assume a 2,300-gas transfer stipend are the obvious review targets.

For ETH’s investment case, the upgrade strengthens the credibility of an L1 scaling path that takes decentralization constraints seriously. It does not settle fee-accrual debates. More capacity can lower unit fees even as it supports more activity; repricing redistributes costs among transaction types; builder economics and MEV remain material. The investable conclusion is not a deterministic revenue forecast but a reduction—or increase, if testing disappoints—in protocol execution risk.

Risks and counterarguments

The strongest counterargument is complexity risk. Glamsterdam couples a substantial consensus redesign with new execution metadata and a broad gas-schedule change. Even when each component has a clear rationale, interactions can create failure modes absent from isolated tests. A phased philosophy does not eliminate the blast radius of the combined fork.

Second, parallelism can be overstated. BALs expose dependencies and enable parallel work, but real blocks may contain hotspots, and additional list data consumes bandwidth. Performance should be measured across client implementations and realistic state sizes, not inferred from architecture alone.

Third, ePBS removes trusted relay dependence from the core exchange without solving every political-economy problem around block building. Builder concentration, private order flow, censorship, and latency advantages can persist. The Ethereum security roadmap places inclusion-list work in the later Hegotá upgrade, underscoring that ePBS is foundational rather than the final censorship-resistance design.

Finally, the gas model encodes forecasts about hardware, state growth, and user response. EIP-8037’s target is a policy calibration, not a natural constant. If demand shifts or clients improve, parameters may prove too restrictive or too permissive. Sustainable scaling requires continued measurement after activation.

Conclusion

Glamsterdam’s most important idea is that throughput is a verification problem. ePBS creates time, BALs create visibility into dependencies, and repricing creates a budget for persistent resource use. The combination is more credible than raising capacity in isolation because it recognizes the costs borne by validators and node operators.

But the upgrade has not yet earned a mainnet victory lap. On 3 October, the defensible statement is narrower: Ethereum has assembled a coherent scaling architecture and is about to expose it to its first public-testnet fork. The signal to watch on 6 October is not a single successful epoch. It is whether heterogeneous clients, builders, validators, and applications behave predictably when the new pipeline is stressed. Mainnet confidence should be accumulated from that evidence, not borrowed from the roadmap.

Primary sources

• Ethereum Foundation: Glamsterdam Testnet Announcement

• Ethereum.org: Glamsterdam roadmap overview

• EIP-7732: Enshrined Proposer-Builder Separation

• EIP-7928: Block-Level Access Lists

• EIP-8037: State Creation Gas Cost Increase

• EIP-8038: State-access gas cost update

• Ethereum Foundation: Glamsterdam repricing impact

• Ethereum.org: Security roadmap