Glamsterdam’s Real Bet: Ethereum Is Redesigning the Block Pipeline, Not Merely Raising a Limit
Glamsterdam links block production, execution visibility and resource pricing into one capacity strategy. Original editorial illustration.
Published 13 September 2026 — Research report
Executive summary
Ethereum’s next major upgrade should be understood as an attempt to change the economics and engineering of verification, not as a promise of instantly cheaper transactions. Glamsterdam, now in devnet testing and expected on mainnet in the fourth quarter of 2026, combines two headline changes—enshrined proposer-builder separation (ePBS) and block-level access lists (BALs)—with a broader set of gas-accounting and state-repricing measures. The official roadmap lists a Sepolia fork for 6 October, but no mainnet date has been confirmed. That distinction matters: the upgrade has moved from research into integration, yet its final proof will be multi-client operation under public-testnet conditions.
The package has a coherent thesis. ePBS gives block builders more time to reveal large execution payloads while moving today’s out-of-protocol builder market into consensus rules. BALs make a block’s state reads and writes explicit, creating opportunities for parallel I/O, parallel execution and faster state-root computation. Repricing raises the gas charged for operations whose real burden has increased as Ethereum’s state has grown. Together, these changes aim to create safe headroom for materially higher L1 capacity without quietly transferring the cost to node operators.
That is the constructive case. The countercase is equally important. ePBS adds a two-party protocol with new timing and liveness failure modes. BALs add data and validation obligations and do not make every workload parallel. Repricing can expose contracts built around hard-coded gas assumptions. And capacity increases are a separate governance and operational decision: Glamsterdam enables them; it does not guarantee their size, timing or fee effect. For institutions, the right framing is therefore “capacity infrastructure with migration risk,” not “a throughput event.”
The thesis: scale by making hidden work explicit
Ethereum has historically bundled several jobs into a compact block-production cycle. A validator proposes; a sophisticated builder may assemble the payload through an external market; execution clients discover state dependencies while executing transactions; and gas prices approximate the hardware burden. This arrangement has scaled surprisingly far, but each implicit step becomes a constraint as blocks grow.
Glamsterdam attacks those constraints at their boundaries. According to the official Ethereum roadmap, the upgrade’s three stated goals are parallel processing, expanded capacity and sustainable control of database growth. The Glamsterdam meta-EIP currently marks 18 proposals as scheduled for inclusion, while explicitly remaining in review. The list is not incidental breadth: it shows that the headline mechanisms depend on accounting, networking, validator and EVM changes around them.
flowchart LR
A[User transactions and L2 data] --> B[Builder constructs payload]
B --> C[ePBS bid and commitment]
C --> D[Proposer selects and proposes]
D --> E[Builder reveals payload]
E --> F[Validators attest]
E --> G[BAL exposes state touches]
G --> H[Parallel reads, execution and state-root work]
I[State repricing] --> B
I --> H
F --> J[Finalized Ethereum block]
H --> JThe diagram illustrates why treating the fork as a list of unrelated EIPs misses the point. ePBS changes who does what, and when. BALs change what execution clients know before and during verification. Repricing changes which workloads can profitably fill the newly available capacity. The intended output is not raw speed at any cost; it is a larger block envelope whose worst-case resource demands remain defensible.
ePBS: more propagation time, more protocol responsibility
Proposer-builder separation already exists economically through the external MEV supply chain, but the base protocol does not fully govern it. EIP-7732 brings that division into consensus: the proposer commits to a builder’s bid, and the builder is responsible for timely payload revelation. The Ethereum.org explainer says the redesign expands the data-propagation window from roughly two seconds to roughly nine seconds. More time makes larger payloads less likely to overwhelm validation and networking deadlines.
The institutional significance goes beyond throughput. Enshrinement replaces part of an external trust and middleware dependency with explicit protocol states, duties and penalties. It may reduce reliance on trusted relays and standardize the interface between proposers and builders. But it also makes consensus responsible for disagreements and failures that middleware previously absorbed. An April Ethereum Foundation checkpoint described “partial blocks” and two-party coordination as changes touching practically the entire stack.
Evidence of progress is meaningful but not final. At the Soldøgn interoperability event, more than 100 core contributors worked on a multi-client implementation; by the end, nearly all clients were running on glamsterdam-devnet-2 and the external-builder pipeline had been tested end to end, according to the official recap. The same recap identified unresolved design questions, including how a low-stake builder design withstands peer-to-peer Sybil attacks against liveness. This is a useful signal of engineering maturity: the happy path works across implementations, while adversarial and degraded paths remain the real acceptance test.
BALs: turning execution into a schedulable workload
Today an execution client generally learns which accounts and storage slots a transaction touches by executing it. That makes safe parallelization difficult: two apparently independent transactions may collide on the same state. EIP-7928 requires a block-level record of accessed accounts and storage locations, together with post-transaction changes. Its stated benefits include parallel disk reads, parallel transaction validation, parallel state-root computation and even state updates without re-executing every transaction.
The conceptual shift is from discovery to disclosure. A BAL is not merely a performance hint: the block header commits to it, and clients validate it against execution. That commitment enables clients to schedule known work earlier and in parallel. It can also support synchronization and state reconstruction. Yet benefits will vary by workload. Transactions that touch the same popular contracts or storage remain serially dependent; parallel hardware does not repeal contention.
There is also a bandwidth trade-off. BALs are additional data whose propagation, storage and validation must be engineered carefully. Networking proposals associated with Glamsterdam address exchange and synchronization, and a separate sidecar design has been discussed to keep this data away from the payload’s critical path. The relevant investor conclusion is restrained: BALs create an execution optimization surface, but realized throughput depends on client implementations, dependency patterns and the gas-limit policy adopted after activation.
Repricing: the constraint that makes capacity credible
If ePBS and BALs only made blocks easier to process, demand could still concentrate in operations whose gas charges understate their long-run costs. EIP-8037 reprices creation of accounts, storage and code; EIP-8038 reprices access to state. The Ethereum Foundation says these categories were last broadly adjusted in the 2021 Berlin fork, while state has since grown and gas limits have risen. Its 24 August impact report says the new schedule is derived from a performance target supporting roughly a threefold increase in base throughput.
This is not the same as promising a threefold gas limit or threefold user throughput. It is a design target used to calibrate resource prices. The distinction prevents an attractive benchmark from becoming a false forecast. Gas-limit changes require evidence across the slowest supported clients, network conditions and worst-case blocks. In May, the interoperability effort deliberately benchmarked optimizations separately and focused on lifting the slowest client paths, a more decentralization-aware criterion than celebrating the fastest implementation.
Repricing also redistributes costs. Ordinary ETH transfers may benefit from EIP-2780’s lower intrinsic transaction gas, while state-heavy applications pay more accurate prices for database creation and access. The result can be lower congestion costs in aggregate and higher unit costs for particular operations at the same time. “Fees go down” is therefore an incomplete reading; the proposal aims to make fees more faithful to resource use so aggregate capacity can rise safely.
Readiness is a sequence, not a date
Public milestones separate demonstrated progress from future targets. Original editorial timeline; dates sourced from the Ethereum Foundation and Ethereum.org.
The public evidence supports a transition from component development to ecosystem preparation. It does not support treating Q4 as a guaranteed activation date. Ethereum.org describes the fork as testing on devnets, names 6 October as the next Sepolia milestone and labels the mainnet date unconfirmed. The meta-EIP’s activation table remains blank as of this report.
flowchart TD
A[Stable multi-client devnets] --> B{Public testnets remain stable?}
B -- No --> C[Fix clients, specs or timing]
C --> B
B -- Yes --> D[Security review and client releases]
D --> E{Operator adoption sufficient?}
E -- No --> F[Extend coordination window]
F --> E
E -- Yes --> G[Confirm mainnet activation]
G --> H[Measure propagation, execution and state growth]
H --> I{Evidence supports more capacity?}
I -- No --> J[Hold or stage gas-limit increases]
I -- Yes --> K[Raise capacity with monitoring]This decision structure is more relevant to risk than a countdown. A clean Sepolia fork would test public infrastructure and client diversity, but it would not eliminate mainnet-scale builder concentration, network latency or application compatibility risk. Conversely, a delay would not necessarily invalidate the design; it could indicate that Ethereum’s multi-client release process is doing its job.
Application and market implications
For L1 applications, the immediate issue is compatibility rather than redesign. The Foundation replayed historical mainnet transactions under the new pricing schedule and classified outcomes from unchanged through potentially broken. It says the large majority were unaffected and most flagged cases could be fixed by raising the supplied gas limit. The smaller high-risk group relied on fixed stipends, hard-coded call gas, branching on remaining gas or pre-signed transactions with fixed limits. This evidence is reassuring in breadth but important in the tail: high-value contracts can be operationally significant even when few in number.
Wallets, RPC providers and automation systems face a related estimation risk. Cached gas constants can underquote transactions after repricing. Institutional operators should therefore view public-testnet results, updated estimator behavior and client-release adoption as leading indicators. The report intentionally does not reduce readiness to a single “affected contract” count because the official analysis does not publish a durable aggregate here and because transaction value matters more than count.
For rollups, the effect is indirect but strategic. Glamsterdam’s additional L1 headroom can support settlement and data workloads, while Fusaka had already focused on blob scaling. Yet rollup fees depend on demand, data availability pricing, proving costs and sequencer policy, not only L1 execution capacity. Markets should resist collapsing a multi-variable cost stack into a fork-day fee prediction.
For validators and builders, ePBS changes operational roles and potentially market structure. Protocol-defined builder duties may lower relay trust, but specialized builders could remain concentrated because optimization, order flow and capital advantages do not disappear. Enshrinement standardizes the contest; it does not automatically democratize it. Monitoring builder shares, missed payloads, censorship signals and client diversity after deployment will matter more than assuming decentralization from architecture alone.
Risks and counterarguments
Risk or challenge | Why it matters | Evidence that would reduce concern |
|---|---|---|
ePBS liveness and timing complexity | A builder failure now intersects explicitly with consensus deadlines | Stable adversarial testnets, low missed-payload rates, clear recovery behavior |
Builder concentration | Specialized execution may consolidate despite open protocol access | Durable diversity in builder share and accessible entry economics |
BAL overhead and imperfect parallelism | Extra data can burden networks; shared-state workloads remain serial | Cross-client worst-case benchmarks and production dependency profiles |
Repricing compatibility | Hard-coded gas assumptions can break otherwise mature contracts | Public-testnet replay, updated estimators and remediation of high-value contracts |
State growth after capacity expansion | Higher throughput can raise storage and hardware demands | Measured state growth, home-node performance and staged limit policy |
Schedule compression | Q4 expectations can pressure testing and operator coordination | Release lead time, broad client uptake and an evidence-based activation decision |
The strongest counterargument is that Ethereum is adding protocol complexity to solve problems partly created by external markets and sequential execution. Complexity expands the attack surface and the burden on implementers. That criticism is real. The response is not that complexity is free, but that the current system already contains complexity—relays, builder APIs, hidden state discovery and mispriced resource use—without uniformly enforceable rules. Glamsterdam moves selected complexity into shared consensus and makes execution work more legible. Whether this is a net simplification can only be judged through operational data.
Another counterargument is economic: more capacity may suppress fee revenue or encourage state growth. Repricing is the package’s answer, separating cheap computation from expensive persistent state rather than treating all gas as equivalent. Still, fee-market outcomes will depend on demand elasticity, MEV and burn dynamics. This report makes no ETH price or yield forecast from the upgrade.
What institutional readers should watch
The next useful evidence is not promotional transaction-per-second figures. It is the Sepolia activation, subsequent public-testnet stability, the final client release matrix and the announced mainnet epoch. After activation, attention should shift to payload-reveal reliability, block propagation, execution time by client, BAL sizes, builder concentration, state growth and gas-estimation failures. Capacity policy should be evaluated as its own decision rather than attributed automatically to the fork.
The sources also require version discipline. Ethereum.org warns that scope is frozen but can still change before mainnet because the meta-EIP remains in draft. Therefore, a September diligence memo should not be treated as a final specification. The canonical references are the live upgrade page, meta-EIP, individual EIPs and official protocol announcements—not secondary feature lists.
Conclusion
Glamsterdam’s importance lies in coordination. ePBS expands and formalizes the block-delivery pipeline; BALs expose execution dependencies; repricing protects the resource budget that greater capacity would consume. Each mechanism has limitations alone. Together, they form Ethereum’s most concrete near-term attempt to make L1 scaling compatible with multi-client verification and home-node constraints.
The evidence as of 13 September 2026 supports cautious confidence, not completion. Multi-client devnets have demonstrated integrated progress, historical replay has surfaced a bounded but material compatibility tail, and a public-testnet milestone is scheduled. Mainnet activation remains unconfirmed, while liveness, concentration and application assumptions still require testing. The appropriate institutional conclusion is neither “routine fork” nor “instant scale.” Glamsterdam is a redesign of the block pipeline whose value will be measured by how safely Ethereum converts engineering headroom into usable capacity.