Glamsterdam is no longer just an upgrade name on Ethereum’s distant roadmap. It is emerging as the network’s most consequential 2026 technical package, with EIP-7732 for enshrined proposer-builder separation and EIP-7928 for Block-Level Access Lists at the center of the plan. That matters because Ethereum is trying to solve two problems at once: block production has become too dependent on off-chain intermediaries, and execution needs to become more parallel and efficient if the base layer is going to keep scaling.
The hype around Glamsterdam is easy to understand. The harder part is understanding what it actually changes. This is not another user-facing narrative about cheaper fees next week. It is a deeper rewrite of how Ethereum organizes block construction, state access, and the trust assumptions that sit between validators and the transactions they include. The real question is whether that rewrite makes Ethereum cleaner, faster, and more decentralized — or simply more complicated.
The Core Event Is That Glamsterdam Has A Real Technical Center Of Gravity
For months, “Glamsterdam” sounded like a placeholder for whatever came after Fusaka. That changed once core developer discussions and implementation work began converging around a smaller, more coherent set of headline items. QuickNode’s March overview described EIP-7732 and EIP-7928 as the only proposals clearly confirmed at the center of the fork, while All Core Devs notes in January and February showed active work around ePBS devnet-0 and bal-devnet-2. The point is not that everything is finalized. It is that the fork now has a direction.
EIP-7732 tackles one of Ethereum’s most uncomfortable truths: in practice, block building today depends heavily on relays and off-chain coordination under the proposer-builder separation model introduced by MEV-Boost. That architecture helped Ethereum scale block construction after the Merge, but it also created new trust assumptions and centralization pressure. Enshrined PBS tries to move the most important parts of that market back into the protocol itself.
EIP-7928 addresses a different bottleneck. Ethereum execution is still constrained by the fact that clients do not know in advance which accounts and storage slots a block will touch. Block-Level Access Lists change that by committing those accesses at the block level, opening the door to parallel disk reads, faster validation, and executionless state updates. The data tells a different story from the old assumption that scaling is only about blobs and Layer 2s. A lot of Ethereum’s next efficiency gains depend on making block processing itself less wasteful.
“Separates the ethereum block in consensus and execution parts, adds a mechanism for the consensus proposer to choose the execution proposer.” — EIP-7732 abstract
Epbs Is Really About Who Controls Block Building
To understand why ePBS matters, ignore the acronym for a moment and focus on the power structure. Today, validators often outsource the economically important part of block construction to external builders, typically coordinated through relays. That has improved efficiency and MEV extraction, but it means Ethereum’s supposedly neutral block market relies on a narrow middleware layer that is not fully inside the protocol. When people talk about relay risk, censorship pressure, or builder concentration, this is what they mean.
EIP-7732 tries to reduce that dependency by formalizing proposer-builder separation inside Ethereum itself. The proposer remains responsible for the beacon block, while the execution payload gets organized through an in-protocol mechanism that narrows the trust placed in relays. Supporters argue this improves censorship resistance, decentralization, and liveness. Critics respond that “enshrining” the architecture does not eliminate complexity; it merely moves complexity into the base protocol, where mistakes are more expensive.
This debate matters beyond the validator set. If Ethereum wants to become the settlement layer for large-scale tokenized markets, its block-building process cannot look like a semi-outsourced black box forever. Institutional users may tolerate complexity, but they do not like invisible dependencies. In that sense, ePBS is not just a MEV reform. It is part of the infrastructure clean-up required for Ethereum to look credible as a financial base layer. That is why it fits naturally alongside the Foundation’s newer governance and infrastructure posture (https://theethereum.wiki/news/ethereum-foundation-mandate-crops-framework-governance/) and with the broader demand for Stage 2-grade trust assumptions across the ecosystem.
Block-Level Access Lists Could Be The Less Flashy Bigger Deal
If ePBS is the political reform inside Glamsterdam, Block-Level Access Lists may be the engineering one. EIP-7928 proposes recording all accounts and storage locations touched during block execution, along with their post-execution values. That sounds dry until you consider the consequence: clients gain a map of state access before or alongside execution, which makes several forms of parallelization and optimization much more practical.
According to the EIP text, BALs enable parallel disk reads, parallel transaction validation, parallel state root computation, and even executionless state updates in some workflows. In plain English, Ethereum gets better at not doing the same expensive work serially and blindly. That matters because block production has tight time constraints, and those constraints become even tighter when the network wants faster confirmations and larger throughput. BALs do not make Ethereum magically “fast” in the way centralized chains advertise. They make Ethereum less inefficient at the client level, which is exactly what a mature network should be chasing.
There is also a roadmap effect here. Multiple newer proposals reference BALs directly, including work on delayed state roots and BAL-based state healing. That suggests EIP-7928 is not an isolated optimization. It is becoming a building block for how clients, sync mechanisms, and future execution improvements fit together. Readers who followed the Verkle and FOCIL story in Hegota (https://theethereum.wiki/news/hegota-upgrade-verkle-trees-2026/) will recognize the pattern: the most important upgrades are often the ones that make later upgrades easier.
| Glamsterdam component | Core idea | Why it matters |
|---|---|---|
| EIP-7732 (ePBS) | Moves proposer-builder separation deeper into the protocol | Reduces relay dependence and cleans up block-market trust assumptions |
| EIP-7928 (BALs) | Commits block-level state access information | Enables parallel execution-related optimizations and faster processing |
| Devnet work | ePBS devnet-0 and bal-devnet-2 discussed by core devs | Shows the fork is transitioning from theory into implementation |
Why Glamsterdam Matters For Ethereum’S 2026 Roadmap
Glamsterdam also sits inside Ethereum’s broader technical roadmap for the second half of 2026, where protocol changes are increasingly about reducing hidden fragility rather than chasing simple headline throughput.
Ethereum’s 2026 roadmap is increasingly about reducing hidden fragility. That means faster confirmations, easier node operation, cleaner L2 trust models, more resilient governance, and a better-organized execution pipeline on L1. Glamsterdam sits right in the middle of that agenda. It does not compete with the scaling roadmap. It is the part of the scaling roadmap that deals with the messy internals of block production and state processing.
This is why Glamsterdam should be read together with Ethereum’s new fast-confirmation work (https://theethereum.wiki/news/ethereum-fast-confirmation-rule-13-second-deposits/) and with the post-Hegota conversations around Verkle trees, FOCIL, and validator ergonomics. Faster deposits and better confirmation rules only matter if the underlying block path remains robust. More throughput only matters if clients can handle it without centralizing around a tiny number of super-operators. The real question is not whether each change sounds good in isolation. It is whether the stack remains credibly decentralized after all of them are combined.
What’s striking here is how different this feels from earlier Ethereum upgrade cycles. Dencun was easy to explain because users saw cheaper blobspace almost immediately. Pectra had cleaner retail hooks around account abstraction. Glamsterdam is more technical and arguably more important. It goes after the machinery that determines who builds blocks, how clients process them, and whether Ethereum can keep increasing capacity without outsourcing trust to middleware or hardware-heavy operators.
The Bull Case And The Bear Case Are Both Serious
The timing matters even more because Ethereum’s record staking rate is already reshaping network dynamics, which means any change to block building or validator incentives will be scrutinized more intensely.
The bullish case is compelling. ePBS could reduce one of Ethereum’s biggest post-Merge centralization anxieties by making the block market more native to the protocol. BALs could unlock meaningful client-side efficiency gains that compound with other roadmap items. Together, they could make Ethereum more coherent as a base layer precisely when institutions, rollups, and treasury strategies are asking more from it. For supporters, Glamsterdam is what responsible scaling looks like: not just more throughput, but better internal architecture.
The bearish case is not anti-innovation. It is anti-complexity for complexity’s sake. Every time Ethereum moves important market structure into the protocol, it increases design surface area and implementation risk. ePBS must preserve liveness, fairness, and censorship resistance under adversarial conditions. BALs must be integrated without introducing new pathological edge cases for clients and tooling. None of that is impossible. But none of it is free.
There is also a perception problem. Crypto markets often reward immediate narrative clarity, while Glamsterdam is the opposite of immediate. If users do not instantly feel the benefit, some will dismiss the fork as another round of developer navel-gazing. That would be a mistake. Ethereum’s real moat has always depended on invisible engineering improvements eventually compounding into visible trust. The question is whether the market still has patience for that model in 2026.
| Supporters say | Critics say |
|---|---|
| ePBS reduces dependence on relays and cleans up MEV-era trust assumptions | Protocol-level PBS can still be complex and difficult to implement safely |
| BALs make execution and validation more parallel and efficient | New execution primitives can create fresh client complexity and edge cases |
| Glamsterdam strengthens Ethereum as institutional settlement infrastructure | Users may not reward technical fixes that do not produce obvious short-term UX gains |
Final Thoughts On What Glamsterdam Must Prove
Glamsterdam will matter because it touches something Ethereum cannot fake anymore: the quality of its internal market structure. The network has already proven that it can attract builders, rollups, stablecoins, and institutions. Now it has to prove that the machinery underneath those use cases can evolve without drifting toward hidden centralization or client fragility. That is a harder challenge than marketing a faster chain. It is also the one that matters more.
The tension at the heart of Glamsterdam is simple. Ethereum wants to remain credibly neutral while becoming materially more efficient. ePBS and BALs are serious attempts to do both. If they land well, Glamsterdam could end up being remembered as the upgrade that cleaned up the block market before the next growth wave arrived. If they do not, the fork will become another reminder that scaling a decentralized system is never just a technical puzzle. It is always a governance choice about which forms of complexity the network is willing to live with.
