Glamsterdam’s Real Bet: Ethereum Scales by Making Hidden Work Explicit

Research note — 2 August 2026. All upgrade status and market observations are dated to publication; Glamsterdam is planned, not yet activated on Ethereum mainnet.

Editorial illustration of Ethereum coordinating explicit protocol work across parallel execution and state pathways

Glamsterdam’s design connects block production, execution dependencies and persistent-state accounting through protocol-visible commitments. Illustration created for Web3Research.

Executive summary

Ethereum’s planned Glamsterdam upgrade, targeted for the second half of 2026, is easy to describe as another capacity increase. That description misses its institutional significance. Glamsterdam’s two headline proposals—enshrined proposer-builder separation (ePBS, EIP-7732) and block-level access lists (BALs, EIP-7928)—convert two forms of hidden coordination into protocol-visible objects. ePBS brings the exchange between block proposers and specialist builders into Ethereum’s consensus rules. BALs require a block to expose the state it touched and the resulting changes, so clients can prepare data in parallel rather than discover dependencies serially.

The thesis of this report is that Glamsterdam is not primarily a “faster Ethereum” release. It is a redesign of how Ethereum accounts for scarce resources and delegated work. The intended scaling gains come from three linked moves: taking execution off the narrow consensus-validation path, making state dependencies explicit, and repricing permanent state creation. Together they could support materially larger blocks and more blob capacity while keeping validation within the reach of ordinary node hardware. The Ethereum Foundation’s February priorities update said the gas limit had already risen from 30 million to 60 million during 2025 and framed BALs, ePBS and repricing as the route toward and beyond 100 million gas. A May engineering update identified a 200 million post-Glamsterdam gas-limit floor as a credible target, while testing used a 150 million reference limit. These figures are engineering objectives, not promises of mainnet throughput.

The trade-off is equally important. Enshrining the builder-proposer exchange removes a relay as a required trusted escrow; it does not remove specialized builders, private order flow, maximal extractable value (MEV), or the economic forces that concentrate block construction. BALs reveal parallelism, but they also add data and validation obligations. State repricing protects decentralization over time, but makes some state-heavy activity more expensive. And fork-choice enforced inclusion lists (FOCIL), the planned mechanism most directly aimed at builder censorship, were declined for Glamsterdam and selected as the consensus-layer headliner for the following Hegotá upgrade.

For institutions, the right interpretation is therefore conditional rather than celebratory: Glamsterdam should improve the quality and scalability of Ethereum settlement if the multi-client implementation holds under adversarial load and if later censorship-resistance work catches up with the newly enshrined block market. It reduces trust in a component; it does not abolish market power.

The upgrade sequence: from cheap data to parallel execution

Glamsterdam follows a deliberate progression. Dencun introduced temporary, lower-cost blob data for rollups in March 2024. Pectra, activated in May 2025, doubled the target blob count and expanded wallet and validator capabilities. Fusaka followed in December 2025 with PeerDAS, allowing validators to sample blob data rather than download all of it, and with mechanisms for adjusting blob parameters between major forks. Glamsterdam now targets the execution and block-production bottlenecks that become more binding as data and gas capacity rise. The Ethereum roadmap dates Glamsterdam to H2 2026, while the Glamsterdam overview was last updated on 20 July.

flowchart LR
    D["Dencun · Mar 2024<br/>Blob transactions"] --> P["Pectra · May 2025<br/>More blobs and programmable accounts"]
    P --> F["Fusaka · Dec 2025<br/>PeerDAS and flexible blob scaling"]
    F --> G["Glamsterdam · planned H2 2026<br/>ePBS, BALs and state repricing"]
    G --> H["Hegotá · planning for 2027<br/>FOCIL and further protocol work"]
    G --> O1["Longer execution-data propagation window"]
    G --> O2["Parallel reads, validation and state updates"]
    G --> O3["Costs tied more closely to persistent state"]

This sequence matters because capacity is not a single dial. Raising the gas limit without accelerating validation increases the chance that less-connected or lower-specification nodes fall behind. Expanding blob throughput without widening the propagation window can increase reorganization risk. Making cheap state without pricing its lasting storage burden can turn today’s low fees into tomorrow’s hardware barrier. Glamsterdam treats these as coupled constraints.

The scope is substantial but still fluid. As of 2 August, the draft Glamsterdam Meta EIP lists ePBS, BALs, state-creation repricing, block-gas accounting changes, ETH transfer logs, a larger contract-size limit and several other proposals as “Scheduled for Inclusion.” Other measures—including lower intrinsic transaction gas and higher state-access prices—remain “Considered for Inclusion.” Both headline EIPs themselves are still marked “Review.” “Scheduled” is a governance and engineering status, not evidence of successful mainnet activation.

Design problem	Scheduled response	Intended effect	What it does not guarantee
Trusted off-protocol hand-off between proposer and builder	ePBS, EIP-7732	In-protocol commitments, payments and payload-timeliness attestations	Competitive builders, neutral ordering or censorship resistance
Serial discovery of state dependencies	BALs, EIP-7928	Parallel data reads and execution; state updates without full replay	Linear speed-up under every workload or zero bandwidth cost
Permanent state underpriced relative to long-run storage burden	State-creation repricing, EIP-8037	Cost per state byte and a separate accounting reservoir	Lower fees for every contract or workload

ePBS: internalizing the block market

Under today’s widely used proposer-builder separation, a validator can outsource construction of the execution payload to professional builders through MEV-Boost and relays. The separation lets validators compete for sophisticated block revenue without operating a search and building stack themselves. But the relay intermediates a fair exchange: the proposer wants the most valuable header without seeing and stealing the block; the builder wants the proposer committed before revealing it. The relay is therefore operationally useful and trusted in ways Ethereum’s base protocol cannot punish directly.

EIP-7732 changes the sequence. A staked builder commits to a payload and bid; the beacon proposer includes the commitment; the builder reveals the payload; and a Payload Timeliness Committee attests whether the payload and blob data arrived on time. Builder-to-proposer payment is deducted through protocol accounting. Consensus validation and execution validation become logically and temporally separated. The EIP-7732 specification says this gives the next proposer six seconds and other validators nine seconds for payload validation, compared with the much tighter work before the current attestation deadline.

sequenceDiagram
    participant B as Specialist builder
    participant P as Beacon proposer
    participant C as Ethereum consensus
    participant T as Timeliness committee
    participant V as Validators
    B->>P: Signed payload commitment and bid
    P->>C: Consensus block carrying commitment
    C->>C: Reserve builder payment for proposer
    B-->>T: Reveal execution payload and blob data
    T->>C: Attest whether reveal was timely
    C-->>V: Establish full, empty or skipped slot status
    V->>V: Validate execution on the wider path

Editorial illustration of a verifiable block handoff opening into parallel state-processing lanes

The protocol first verifies the builder–proposer handoff, then exposes state dependencies that clients can process concurrently. Illustration created for Web3Research.

The architectural gain is not that relays become illegal or necessarily disappear. It is that the minimum fair-exchange path no longer depends on them. Even researchers close to the block-building ecosystem expect relays to survive by offering auction, privacy or routing features beyond the base protocol; a June Flashbots Collective analysis argues that in-protocol payments reshape rather than erase their role. This distinction is central for institutional risk assessment. Ethereum can reduce a trusted dependency while commercial infrastructure continues to intermediate order flow.

Pipelining also links L1 execution scaling to rollup economics. Removing the full payload from the consensus block’s critical path gives more time to distribute larger execution payloads and blob data. Rollups benefit if Ethereum can raise blob targets without worsening orphan and reorganization risk. L1 users benefit if the gas limit can rise sustainably. Neither benefit arrives automatically at fork activation: client performance, network conditions, validator participation and subsequent parameter decisions determine realized capacity.

BALs: turning state dependencies into shared infrastructure

Ethereum executes transactions in an ordered state machine. A transaction can read or change an account or storage slot that another transaction also touches. When a validating client does not know these dependencies in advance, the safe baseline is to discover them while processing transactions in sequence. Hardware may have many cores, but unknown shared state keeps much of that capacity idle.

BALs change the information available to clients. EIP-7928 requires a complete, deterministic record of accounts and storage locations accessed during a block, together with post-transaction values. The block header commits to that list. A client can prefetch independent data, group non-conflicting work and calculate parts of the state transition concurrently. Because post-execution values are present, a syncing node can also apply state updates without re-executing every transaction, subject to verifying the committed data.

The strongest evidence is structural rather than a headline benchmark. The EIP-7928 rationale reports that 60–80% of transactions in its historical analysis access disjoint storage slots and estimates an average compressed BAL of about 72.4 KiB at a 60 million gas limit. That is useful headroom, but not a universal throughput multiplier. Parallel systems remain limited by their longest dependent path, data transfer and coordination overhead. Specialized benchmarking has produced multi-gigagas-per-second results on commodity multicore hardware, but those experiments use constructed “mega-block” settings and should not be read as projected mainnet throughput.

BALs also shift responsibility toward builders. The party assembling a block must produce an accurate map; validators must reject inconsistencies. This makes builders providers not only of transaction ordering but also of a reusable execution witness. The upside is a common, protocol-enforced data product that every client can optimize around. The downside is a new adversarial surface: phantom reads or oversized lists could force needless downloads and I/O before a bad block is rejected. EIP-7928 explicitly acknowledges validation overhead, larger blocks and early-rejection concerns. The security argument therefore depends on strict size and gas-feasibility bounds, not merely on average-case compression.

State economics: throughput that does not mortgage decentralization

Parallel execution solves only the immediate processing problem. Every new account, contract and storage entry adds persistent state that nodes must retain. If gas prices reflect compute but undercharge long-lived storage, higher throughput accelerates state growth and gradually raises the cost of independent verification.

Scheduled EIP-8037 addresses this by charging state creation according to bytes and separating state charges from ordinary execution through a dedicated reservoir. Ethereum’s July overview describes a target state-growth rate of 120 GiB per year and presents the change as a prerequisite for much higher gas limits. These numbers encode a governance choice: capacity should expand only alongside an explicit budget for the hardware externality imposed on all future node operators.

That choice creates distributional effects. Simple transfers may become cheaper if the separately considered EIP-2780 is ultimately included, while contracts that create large amounts of durable state may pay more. “Glamsterdam lowers fees” is therefore too broad. The likely outcome is better total capacity and more accurate relative prices. Applications that use computation efficiently but leave substantial state behind could face a different cost curve from applications dominated by ephemeral computation.

Implications for institutions and the Ethereum stack

For validators and staking providers, ePBS reduces the need to trust a relay for basic payment-versus-payload exchange, but it adds new protocol duties and more complex failure states. Operators must evaluate client readiness, builder selection, payload-timeliness behavior and fallback performance. Client diversity becomes more valuable, not less, when both consensus and execution pipelines change simultaneously.

For builders and MEV infrastructure, the moat moves. Relay operation alone may become less essential, while low-latency order flow, simulation quality, capital and distribution remain powerful advantages. Protocol access may become fairer without the builder market becoming economically diffuse. Investors should avoid treating “enshrinement” as “decentralization.”

For rollups, ePBS is upstream infrastructure. A longer propagation and validation window supports more data, while Fusaka’s PeerDAS reduces the burden of verifying availability. Yet rollup fees also depend on demand, blob-parameter governance and each rollup’s own compression and sequencing choices. Glamsterdam strengthens the supply side of blob space; it does not repeal congestion.

For application developers and exchanges, BALs and standardized ETH transfer logs can improve observability and synchronization. State repricing, however, means historical gas assumptions deserve economic review. The relevant strategic question is not whether every application should return to L1, but whether a cheaper and more predictable L1 changes where high-value settlement, liquidity and composability are best located.

For Ethereum governance, Glamsterdam raises the cost of future mistakes as well as the benefit of future tuning. Once the protocol owns the builder exchange and a canonical access-list format, those interfaces become difficult to change. The gain is enforceability; the liability is ossification. Careful testnet evidence and conservative activation remain part of the scaling design, not bureaucratic delay.

Risks, counterarguments and what to monitor

Builder concentration can survive relay removal. MEV depends on information, latency, capital and exclusive order flow. ePBS makes the auction’s core exchange trustless but does not equalize those inputs. A 2026 academic simulation of ePBS under MEV found sharply more concentrated modeled builder profits. Its assumptions are not an observation of a live Glamsterdam network, but the direction of the warning is credible: an open protocol market can still converge on a small group of superior firms.

Censorship remains a sequenced, not simultaneous, fix. MEV Watch continues to classify payload deliveries from relays that filter sanctioned transactions, demonstrating that content policy is a live block-production variable. EIP-7732 is compatible with inclusion lists but does not itself require builders to include users’ transactions. The Meta EIP records FOCIL as declined for Glamsterdam; Forkcast’s Hegotá tracker lists it as that upgrade’s scheduled headliner. Until then, the protocol internalizes builder exchange faster than it internalizes a strong inclusion guarantee.

The builder “free option” can harm liveness. A committed builder may prefer to withhold a payload when external prices move sharply. The EIP itself flags this risk. A 2025 study estimated exercise in 0.82% of historical blocks under an eight-second option window on average, rising as high as 6% on high-volatility days. Those are model-based counterfactuals, not a forecast; they nevertheless identify exactly when delayed or empty blocks would be most costly to DeFi users.

Parallelism can be oversold. Independent transactions parallelize well; a hot application or shared liquidity pool creates dependencies. BAL data consumes bandwidth, and verification remains necessary. Success should be measured through worst-case block propagation and validation across multiple clients and ordinary hardware—not peak laboratory execution.

Scope and timing may move. The upgrade is planned for H2 2026, but the authoritative Meta EIP remains a draft and several proposals remain merely considered. The May Protocol Cluster update reported multi-client devnets and an external-builder pipeline tested across nearly all clients, which is meaningful progress, not a mainnet readiness certificate.

The key monitoring framework is consequently simple: multi-client correctness under adversarial BALs; empty-slot and payload-withholding behavior on ePBS testnets; builder and order-flow concentration; validator hardware requirements; realized block and blob propagation; final EIP scope; and the delivery path for FOCIL after Glamsterdam.

Conclusion

Glamsterdam’s importance lies in what Ethereum chooses to make explicit. The builder-proposer exchange becomes a consensus object. Transaction dependencies and state changes become a shared execution object. Permanent state becomes a separately budgeted resource. This is a coherent response to the central problem of decentralized scaling: more capacity is valuable only if ordinary participants can still verify the system and users do not have to trust an opaque intermediary to obtain it.

The upgrade’s limits follow from the same logic. Protocol visibility is not market competition; parallelizable work is not infinite throughput; accurate storage prices are not universally lower fees; and trustless exchange is not censorship resistance. Glamsterdam should therefore be judged as infrastructure for a higher-capacity Ethereum, not as the completion of that project. If implementation matches design, it will widen Ethereum’s operating envelope. Whether that envelope remains credibly neutral will depend on builder-market outcomes and on the inclusion guarantees scheduled to follow.