Glamsterdam: Why ePBS is Delaying the Ethereum Fork

Ethereum's next hard fork, Glamsterdam, is no longer arriving this summer: the Ethereum Foundation has moved it to the second half of 2026 —late August at best, with no mainnet date officially announced— and the bottleneck has a specific name: EIP-7732, known as ePBS. ePBS (enshrined Proposer-Builder Separation) is the piece that rewrites how Ethereum blocks are constructed, and its complexity —combined with an as-yet untested interaction with new block-level access lists— is what has slowed down the timeline. For the large institutional stakers that currently concentrate much of the network —Lido with approximately 8.72 million ETH and Coinbase with nearly 4.5 million— this is not a distant technical detail: ePBS fundamentally changes who their block construction operations depend on. This article explains why it has been delayed, what changes operationally for those staking, and the actual chronology from devnets to mainnet.

What exactly is Glamsterdam and what does ePBS bring?

Glamsterdam is the code name for the hard fork (a network upgrade requiring all nodes to adopt new rules simultaneously) that succeeds Pectra, which was activated on mainnet on May 7, 2025. The package combines several improvements, but the one dominating the debate and setting the pace is EIP-7732, ePBS.

To understand ePBS, it is useful to define four terms. The proposer is the validator assigned by the protocol to propose the next block. The builder is the entity that assembles the content of that block: ordering transactions to maximize their value. MEV (Maximal Extractable Value) is precisely that value that can be captured by reordering, including, or excluding transactions within a block. And the relay is the external intermediary that currently connects builders and proposers so that the distribution is reliable without revealing the block's contents in advance.

The best analogy to capture this: the proposer chooses the menu —which slot will be served and under what conditions— but the builder is the one who cooks the dish, decides the order of ingredients, and keeps the MEV tip. Today, this distribution between the one who chooses the menu and the one who cooks is arbitrated by a trusted intermediary outside the protocol: the relay, within the MEV-Boost system. ePBS takes this arrangement and moves it inside Ethereum's rules: the builder market stops depending on external relays and becomes inscribed (hence "enshrined") in the protocol itself. The economic mechanics of why this distribution matters —and how MEV went from a plague to being enshrined and redistributed— is detailed in our analysis of MEV Era III; those starting from scratch will find the basics in what is MEV.

Alongside ePBS, Glamsterdam incorporates EIP-7928 (Block-Level Access Lists, BALs), which attach to each block the list of accounts and storage that transactions will touch, enabling more parallel execution; and a gas repricing package (where EIP-7904 is one of several involved EIPs). FOCIL (Fork-Choice Inclusion Lists), which was considered a candidate, has been moved to Hegotá, the subsequent fork, specifically to avoid overloading Glamsterdam.

Why has Glamsterdam been delayed?

The delay is not a failure: it is engineering caution. ePBS is one of the most invasive modifications to the consensus layer since the transition to Proof of Stake, as it changes the flow by which a block goes from being proposed to being confirmed. There are two specific technical causes behind the schedule slip.

The first is the intrinsic complexity of implementing EIP-7732. Having the proposer-builder distribution live within the protocol requires coordinating "trustless" payments between both parties, redefining how and when the block payload is validated, and ensuring all consensus clients implement the same logic compatibly. This is not code that can be tested in an afternoon.

The second is the untested interaction at mainnet scale between ePBS and BALs (EIP-7928). Each is manageable on its own; the problem is that they overlap. BALs signal in advance which accounts and storage each transaction will touch to allow for parallel execution, while ePBS separates the moment a block is committed from the moment its payload is validated. Combining both creates new execution paths —what is known about the block content and when— that only surface under real load and with many different clients communicating with each other. This is why the process is taking as many devnets as necessary before touching public testnets: a consensus failure here isn't just any bug; it's a chain split.

Added to this was a strategic decision. The engineering team at Base (Coinbase's L2) warned that including FOCIL in addition to ePBS would have pushed the fork beyond 2026. The response was to remove FOCIL from the package and move it to Hegotá, the following fork. This logic has guided the entire redesign of Glamsterdam: instead of including everything desirable and risking an impossible-to-close fork, the scope is limited to ePBS plus the two supporting EIPs (BALs and gas repricing), postponing the rest. Cutting ambition to protect the date is, in itself, a sign of process maturity.

It is important to clarify the timeframe to avoid misleading headlines. ethereum.org already classifies Glamsterdam as an update for the second half of 2026. The aspirational internal target is around late August 2026, with no mainnet date announced, and a real risk of sliding into the fourth quarter if ePBS requires more iterations on testnet. This is not a delay relative to the planned window: the fork remains within its H2 2026 slot, but with its heaviest component still hardening.

What changes operationally for Lido and Coinbase?

This is the true differentiator, as it affects those who concentrate the network. Today, more than 90% of the builder market operates through MEV-Boost, using external relays from actors like Flashbots or bloXroute (with Commit-Boost gaining ground, at around 20% adoption as a middleware alternative). This means that a large staking operator, when it is their turn to propose a block, does not construct the content: they auction it to builders via a relay and keep the highest bid. Block construction —and the associated MEV capture— is outsourced to a handful of intermediaries outside the protocol.

ePBS rewrites that dependency. By enshrining the builder market in the protocol, the proposer-builder distribution no longer requires a trusted relay: Ethereum itself guarantees that the proposer gets paid and the builder delivers. For Lido, Coinbase, and any large operator, this changes the control point and risk profile of their block construction operations —less dependence on third-party infrastructure, more predictable distribution rules— although the redesign introduces new requirements (for example, staked capital for enshrined builders) whose effect on builder market competition is one of the points of contention.

The context of why this carries so much weight: Ethereum staking is at all-time highs, with the market closely watching the architecture of who validates. Lido leads with approximately 8.72 million ETH (around 24% of total staking) and Coinbase manages nearly 4.5 million (around 12%, Q1 2026 data). We covered this record staking context in the staking-ETF paradox, and Lido's specific status in institutional staking with stETH. The fact that the validator cap rose from 32 to 2,048 ETH with Pectra (EIP-7251) only served to concentrate more stake per node, making it more urgent to resolve the block construction centralization that ePBS aims to tackle.

Who is most affected by the change and how?

The impact is not uniform. It is useful to separate it by type of actor, as each approaches ePBS from a different position.

The unequal distribution has a nuance worth highlighting for builders. Today, a handful of professional builders capture most of the MEV flow because they control the relationship with relays and the auction infrastructure. ePBS does not eliminate the advantage of the specialized builder —ordering transactions to extract value remains a business of scale— but by enshrining the rules in the protocol and requiring staked capital from enshrined builders, it changes the levers of competition. Whether this capital barrier consolidates the giants or, conversely, opens space for new entrants by removing the relay as a gatekeeper, is exactly the point that no one can yet state with certainty and which the Sigma Prime debate itself left open.

For the investor who does not operate nodes, the relevant takeaway is that the market watches the Glamsterdam date as a signal of the health of Ethereum's roadmap. Bearish analyses like JPMorgan's on ETH's structural underperformance use roadmap execution as one of their core arguments: an orderly and communicated delay is not the same as a chaotic one, and the teams are choosing the former. The staker delegating to Lido or Coinbase does not notice any of this in their day-to-day yield; what changes is the robustness of the infrastructure upon which that yield rests.

Is there consensus on including ePBS in this fork?

Not entirely, and the tension is instructive. The most cited debate originated from Sigma Prime, the company behind the Lighthouse consensus client, and it is worth portraying accurately because the firm's position was not monolithic. Internally, there was disagreement: Dapplion argued against enshrining EIP-7732 in Glamsterdam, maintaining that enshrining proposer-builder separation today is unnecessary —MEV-Boost works with minimal incidents, some scaling benefits are achieved with "payload split + delayed execution" without the need for trustless payments, and the network has room to wait one more fork cycle. His nuance: "if we have to ship some form of ePBS now, I will vote to schedule EIP-7732 for Glamsterdam," recognizing it as the most mature specification available.

Opposing that position, Mark Mackey defended it as the fork's headliner, and the company ended up supporting its inclusion. In other words: it is not "Sigma Prime against it," but an internal debate resolved in favor, with serious arguments on both sides that are worth knowing before reading oversimplified headlines. The core of the discussion —should ePBS be enshrined now or should we wait?— is exactly what an outside analysis cannot distill without having read the primary sources. CleanSky does not take sides: it highlights that the schedule's caution and the very existence of this debate explain why the fork is moving slowly and is well-supported by technical review.

What is the actual chronology from devnets to mainnet?

The path of an Ethereum consensus change has well-defined phases: first devnets (internal test networks for client teams), then public testnets (Sepolia, Hoodi), and finally mainnet. Glamsterdam is still in the first phase.

• Throughout 2024 — MEV-Boost consolidates its dominance in block construction (over 90% of the builder market).
• May 7, 2025 — Pectra activates on mainnet; validator cap rises from 32 to 2,048 ETH (EIP-7251).
• Early 2026 — Glamsterdam takes shape as the next fork, with ePBS (EIP-7732) as the centerpiece.
• ~First week of May 2026 — Soldøgn devnet concludes (client interoperability phase); Devnet-4 is complete.
• June 2026 (Current) — Glamsterdam devnets active (the ePBS+BALs line still in testing); public testnets (Sepolia, Hoodi) still pending.
• Late August 2026 (Best case) — Aspirational activation target, with no confirmed mainnet date.
• Q4 2026 (Risk) — Alternative window if ePBS requires more testnet iterations.

The honest reading of this chronology is that progress is real but uncertainty lives in the final stretch: the jump from devnets to public testnets is the next milestone to watch, and its smoothness will determine if late August remains plausible or if the fork slides into autumn.

What is the takeaway for the staker?

Three ideas for those staking or investing in ETH. First, the Glamsterdam delay is a sign of discipline, not decay: the team prefers to harden ePBS in devnets rather than shipping a block flow rewrite with untested interactions to mainnet. Second, the fundamental operational change is that the builder market moves from depending on external relays —where over 90% of flow is currently concentrated— to being enshrined in the protocol, reducing third-party dependency for Lido, Coinbase, and independent validators. Third, the date is not set in stone: late August 2026 is the best case, Q4 is the risk, and the indicator to follow is the transition from devnets to public testnets (Sepolia and Hoodi).

For those wishing to delve deeper into the economic mechanics of MEV that ePBS reorders, the full breakdown is in our analysis of MEV Era III. Glamsterdam is not the end of that story: it is the moment Ethereum decides to bring the builder market within its own rules.

Sources and links: ethereum.org — Glamsterdam roadmap · Ethereum Foundation — Checkpoint #9 · Sigma Prime — debate on EIP-7732 · Everstake — Glamsterdam explained · Figment — what it means for institutional stakers