Ethereum’s Glamsterdam Bargain: More Capacity, but Only with a Rewired Block

Editorial map of Glamsterdam’s three structural changes

Glamsterdam links block production, execution visibility and resource pricing into one scaling bargain. Original editorial illustration; status as of 15 September 2026.

Executive summary

Ethereum’s next upgrade is best understood not as a bundle of isolated efficiency tweaks, but as an attempt to change the conditions under which Layer 1 capacity can grow. Glamsterdam places three structural moves together: enshrined proposer-builder separation (ePBS) brings the exchange between block builders and proposers into consensus; block-level access lists (BALs) expose a block’s state dependencies and final state changes; and gas repricing makes creation and access of persistent state more closely reflect their burden on nodes. The thesis of this report is that these measures form a single bargain: Ethereum can raise throughput credibly only if it simultaneously reduces off-protocol trust, makes execution easier to parallelize and sync, and constrains database growth.

That bargain matters to institutions because “capacity” is not merely transactions per second. It is the amount of activity a network can absorb without degrading independent verification, making block production hostage to a narrow middleware layer, or accumulating costs that future node operators must pay. Glamsterdam is therefore an infrastructure and market-structure upgrade as much as a performance upgrade.

The upgrade remains unfinished. As of 15 September 2026, the official roadmap says Glamsterdam is being tested on devnets, targets the fourth quarter of 2026, has no confirmed mainnet date, and lists a Sepolia fork for 6 October. Scope is described as frozen but still changeable because the meta-EIP remains a draft. Those qualifications should govern every forecast in this report. The strongest evidence is architectural progress and live testing—not a guaranteed delivery date or realized mainnet performance.

Why the block, not the headline gas limit, is the story

Ethereum entered 2026 with more room than it had a year earlier. The Ethereum Foundation (EF) says Pectra and Fusaka shipped in 2025, PeerDAS enabled validators to sample rather than fully download blob data, and the mainnet gas limit moved from 30 million to 60 million. Its 2026 priorities then joined execution and blob scaling into one “Scale” track, explicitly linking further gas-limit increases to client performance, BALs and ePBS. This is an important change in framing: scaling is no longer presented as turning one numerical dial, but as redesigning the pipeline that carries the additional load.

Today’s builder-proposer division illustrates the constraint. Specialized builders assemble valuable execution payloads; a validator scheduled to propose chooses an offer. That specialization can keep sophisticated block construction from becoming a prerequisite for every validator, but the handoff has depended on off-protocol software, notably relays. The protocol cannot fully verify the surrounding market’s promises. Moreover, the current flow compresses transaction propagation and execution into what the official roadmap characterizes as a tight two-second “hot path.” Bigger payloads collide with a short distribution window.

ePBS, specified in EIP-7732 and scheduled for Glamsterdam, formalizes the separation. Builder payment and the payload handoff gain protocol rules, while a Payload Timeliness Committee and dual deadlines distinguish agreement on the consensus block from the timely arrival of its execution payload. Ethereum.org estimates that this expands the relevant propagation window from about two seconds to about nine. That figure is an approximate design consequence, not a throughput guarantee. But the qualitative gain is clear: the network gets more time to circulate a larger payload without asking validators to accept an opaque relay as the root of trust.

flowchart LR
  subgraph Today[Today's off-protocol handoff]
    B1[Specialized builder] --> R[Relay / middleware]
    R --> P1[Proposer]
    P1 --> A1[Validator attestations]
  end
  subgraph Glam[Glamsterdam with ePBS]
    B2[Builder commits payload and bid] --> P2[Proposer selects bid]
    P2 --> C[Consensus block deadline]
    B2 --> E[Execution payload deadline]
    C --> PTC[Payload Timeliness Committee]
    E --> PTC
    PTC --> S[Protocol settlement]
  end

The nuance is that enshrining the basic exchange does not abolish every relay or eliminate builder concentration. Ethereum.org explicitly notes that builders and proposers may still use middleware for features outside the protocol. ePBS removes a mandatory trust dependency from the core transaction; it does not decree a competitive builder market. Institutional analysts should separate protocol assurance from industrial organization.

Access lists turn hidden dependencies into usable structure

The second pillar, EIP-7928’s block-level access lists, attacks a different bottleneck. Ethereum execution has historically discovered which accounts and storage locations a transaction touches by running it. When dependencies are unknown in advance, concurrent execution risks conflicting state updates. BALs add a block-wide record of state accesses and post-execution values, with a commitment in the block header. The associated eth/71 network update (EIP-8159) lets execution clients exchange those lists.

The immediate benefit is more modest—and more concrete—than the slogan “parallel Ethereum.” Nodes can prefetch independent state and perform parallel disk reads. A syncing node can use recorded post-execution values for executionless state updates rather than replaying every computation from the beginning. The longer-term value is optionality: once conflicts are visible, clients have a map from which safe parallel execution can be organized. Glamsterdam prepares the road; it should not be reported as instantly delivering unlimited parallel transaction execution.

This distinction matters commercially. Faster state access and synchronization can lower operational friction for node providers, indexers and institutions that prefer independent verification. Yet BALs also add data to propagate and new client behavior to implement correctly. The architectural gain must be validated under adversarial blocks, diverse hardware and real network conditions. Multi-client devnets are evidence of engineering maturity, but public-testnet and mainnet behavior remain the decisive tests.

Three-part capacity bargain: propagation, dependency maps and state pricing

The capacity bargain combines an approximately nine-second propagation window, block-level dependency mapping and a 120 GiB-per-year state-growth target. Targets are not guarantees.

Pricing permanence before raising the ceiling

Higher gas limits create a political temptation: users see near-term space, while node operators inherit long-term storage and lookup costs. Glamsterdam’s repricing proposals confront that asymmetry. EIP-8037 harmonizes charges for creating accounts, storage slots and deployed bytecode and meters state creation separately. The roadmap describes a cost-per-state-byte framework targeting a predictable 120 GiB of state growth per year. EIP-8038 raises prices for state access operations whose computational cost has become understated as the database has grown. The last broad adjustment cited by the EF was Berlin in 2021.

This is less a fee hike than a correction to the unit of account. Gas is supposed to ration scarce computation and storage. If a cheap instruction forces every validating machine to perform expensive reads, the fee schedule subsidizes state-heavy designs and leaves denial-of-service headroom. Conversely, a simple transfer between existing accounts does relatively little work. Another scheduled proposal, EIP-2780, reduces intrinsic transaction gas and could make such a transfer’s gas requirement up to 71% lower, while retaining a surcharge when a new account must be created. Glamsterdam’s logic is therefore discriminating rather than uniformly restrictive: cheaper ephemeral/simple work, dearer permanent or database-intensive work.

The trade-off is compatibility. In August, EF Protocol Research, EthPandaOps and specification teams reported replaying historical mainnet transactions under the proposed pricing. They said the large majority showed no change; some succeeded with different gas use; some needed a higher gas limit; and a small potentially broken class failed even after a substantial increase. The fragile patterns include fixed gas stipends, hardcoded call gas, branches based on remaining gas, and presigned transactions with fixed limits. The teams published an affected-contract checker, opened the Platåberget testnet and began direct outreach.

That disclosure is reassuring because it converts an abstract compatibility risk into a testable inventory, but it is not proof that every dormant or privately used contract has been found. Immutability makes repricing unusually consequential: application owners may be unable to patch deployed logic, while interfaces, wallets and estimators must adapt before activation. “Most contracts are unaffected” and “the tail can matter” are simultaneously true.

flowchart TD
  G[Demand for higher L1 capacity] --> H{Raise gas limit alone?}
  H -->|Yes| X[More state growth and heavier reads]
  X --> Y[Higher node burden and DoS headroom]
  H -->|No: structural package| EP[ePBS: longer propagation and in-protocol exchange]
  H -->|No: structural package| BA[BALs: visible dependencies and faster sync]
  H -->|No: structural package| RP[Repricing: costs follow resource burden]
  EP --> C[Credible capacity increase]
  BA --> C
  RP --> C
  C --> V[Validation on diverse clients and hardware]
  V -->|Pass| M[Mainnet readiness]
  V -->|Issues| T[Revise, retest or delay]

What changes for the Ethereum economy

For Layer 2 networks, the main payoff is indirect but potentially material. ePBS’s longer payload-propagation window can accommodate more data, including blobs, while Fusaka’s PeerDAS reduced the amount each validator must download. These are complementary: sampling addresses how data is verified; ePBS addresses how a payload receives enough time to move; repricing and BALs protect the execution layer supporting settlement. No single proposal guarantees cheaper rollup fees, because demand, blob parameters and L2 pricing policies intervene. The defensible claim is that Glamsterdam improves the technical envelope within which blob capacity can grow.

For validators and staking businesses, ePBS replaces a core relay-mediated exchange with protocol settlement and revises builder selection and monitoring. Pools may need architectural changes for trustless monitoring. EIP-8061, another scheduled proposal, separates activation, exit and consolidation capacity; the roadmap estimates roughly four times current exit capacity and twice the consolidation capacity at current staking levels. The counterweight is a shorter weak-subjectivity period, estimated to fall from about 15.7 days to about seven, meaning offline nodes need a recent trusted checkpoint sooner. Liquidity improves, but operational discipline becomes more important.

For application teams, average user experience may improve while edge-case engineering work rises. Simpler ETH transfers may consume less gas; state-intensive operations will consume more; estimators and cached constants must change. Investors should not interpret an overall gas-limit increase as an equal fee reduction for every workload. The upgrade deliberately changes relative prices, favoring operations aligned with the network’s measured resource costs.

For institutional risk committees, the larger lesson is governance by measured constraint. Ethereum is choosing to expose and price bottlenecks before—or alongside—capacity growth. That is a stronger durability signal than a headline capacity number, but it also makes upgrade risk visible: consensus clients, execution clients, builders, validators, wallets and immutable applications must coordinate around a denser set of changes.

Evidence dashboard

Claim

Verified status on 15 Sep 2026

Why it matters

Mainnet timing

Q4 2026 target; no confirmed date

Forecasts must retain schedule risk

Next stated milestone

Sepolia fork on 6 Oct 2026

Public testing is the next gating event

ePBS propagation window

Approximately 2s to 9s

Creates headroom for larger payloads

BAL capability

Parallel disk reads and executionless state updates; future parallel execution foundation

Improves validation/sync architecture without overclaiming present throughput

State-creation target

120 GiB/year

Makes database growth an explicit design constraint

Repricing impact

Large majority unchanged; a small class may break

Tail compatibility risk deserves active testing

Simple ETH transfer

Up to 71% lower intrinsic gas under EIP-2780

Relative pricing can improve even as state operations get dearer

Risks and counterarguments

Schedule and scope risk. The official page simultaneously says scope is frozen and that it can still change because the meta-EIP is draft. Q4 is a target, not a promise. Sepolia is a milestone, not a rubber stamp.

Complexity risk. ePBS adds consensus machinery, including new deadlines and timeliness judgments. BALs add a new data object and networking path. Repricing changes application assumptions. A package can remove middleware trust yet enlarge the protocol surface that client teams must implement consistently.

Centralization may migrate rather than disappear. Protocol-level payment reduces relay dependence, but sophisticated builders can still concentrate through order flow, latency, capital and private integrations. ePBS changes settlement assurance more directly than it changes market share.

Capacity can refill. Lower unit costs can stimulate demand. Even well-priced state can grow, and a 120 GiB annual target is a model-based objective rather than a physical law. Hardware diversity and home-node accessibility require continuous measurement after activation.

Compatibility tails are economically nonlinear. A tiny share of affected contracts can custody disproportionate value or sit deep in composable transaction paths. Historical replay and outreach reduce risk, but inactive contracts and fixed assumptions may surface only under production behavior.

Conclusion

Glamsterdam’s most credible promise is not “Ethereum becomes faster.” It is that Ethereum is trying to earn the right to process more by restructuring how blocks are built, making their dependencies legible, and charging state according to durable cost. ePBS moves a critical exchange into consensus and lengthens propagation time; BALs create a shared map for faster reads, synchronization and eventual parallelism; repricing limits the subsidy to permanent state. Together they convert capacity from a governance vote on a number into an engineering package with explicit safeguards.

The correct institutional stance is constructive but conditional. The design directly addresses real bottlenecks and disclosed compatibility testing provides useful evidence. Yet devnet success is not mainnet proof, a target quarter is not a date, and protocol-level separation does not by itself solve builder concentration. Sepolia on 6 October, subsequent multi-client performance, contract remediation and final mainnet parameters are the evidence gates to watch. Glamsterdam should be valued as a disciplined scaling bargain—provided Ethereum demonstrates that all three sides of that bargain hold under production load.

Direct sources

Research cut-off: 15 September 2026 (UTC). Protocol parameters and schedules remain subject to change.