Ethereum Glamsterdam Upgrade 2026: What Validators and Stakers Need to Know

Why Glamsterdam Matters for the Ethereum Ecosystem

Ethereum's relentless upgrade cadence continues into 2026 with Glamsterdam, a hard fork set to reshape how blocks are proposed, built, and validated at a fundamental level. Coming on the heels of Pectra and Fusaka, Glamsterdam is not an incremental tune-up — it is a structural overhaul that touches validator economics, block production architecture, transaction throughput, and network security simultaneously.

For validators and stakers, the stakes are unusually high. The headline feature, EIP-7732 Enshrined Proposer-Builder Separation (ePBS), eliminates the current dependency on third-party MEV-Boost relays and moves block-building logic directly on-chain. Combined with a gas limit increase targeting 10,000 transactions per second and a suite of supporting EIPs, Glamsterdam promises to reduce MEV centralization by an estimated 70%, cut gas fees by 78.6%, and deliver more predictable, guaranteed MEV payments to validators.

Whether you run a solo validator, manage a large institutional staking operation, or delegate through a non-custodial provider, understanding what Glamsterdam changes — and what you need to do before it activates — is essential. This guide breaks down every major component so you can prepare with confidence.

What Is the Glamsterdam Upgrade? Overview and Timeline

Glamsterdam is the Ethereum hard fork planned for the first half of 2026, with a target activation window around June 2026. It follows the Pectra upgrade (which introduced EIP-7702 account abstraction improvements and validator-facing changes like increased max effective balance) and the Fusaka fork (which extends the data availability roadmap). Glamsterdam sits at what Ethereum researchers describe as the PBS completion milestone — the point at which the external MEV-Boost relay infrastructure, which has operated as a trusted off-protocol layer since 2022, is finally superseded by a native, trust-minimized protocol mechanism.

The upgrade bundles several interdependent EIPs. The core ones are EIP-7732 (ePBS), EIP-7928 (Block-Level Access Lists), EIP-7942 (Available Attestation), EIP-8045 (exclusion of slashed validators from block proposing), and EIP-7872 (Max Blob Flag). Each of these will be discussed in detail below.

On the development timeline, Devnet-5 testing is already underway as of early 2025, with client teams stress-testing the ePBS payload delivery mechanism and the new parallel execution pathways introduced by EIP-7928. Public testnets are scheduled for spring 2026, giving validators a window of several months to validate their setups before mainnet activation. The All Core Developers (ACD) calls have consistently described Glamsterdam as the most complex single upgrade since the Merge, and the testing schedule reflects that complexity.

EIP-7732: Enshrined Proposer-Builder Separation Explained

What Is Wrong with MEV-Boost Relays Today?

Since September 2022, the vast majority of Ethereum validators — at times exceeding 90% — have opted into MEV-Boost, a piece of middleware that allows external block builders to construct optimized blocks and pass them to validators via a trusted relay. This arrangement emerged because sophisticated MEV extraction (arbitrage, liquidations, sandwich trades) generates significant additional revenue beyond base staking rewards, and most validators lack the technical capacity to capture that value themselves.

The problem is structural. MEV-Boost relays are trusted third parties sitting outside the Ethereum protocol. They have no on-chain accountability. If a relay behaves maliciously — withholding a block, front-running the validator, or simply going offline — the validator has little recourse beyond switching relays. This creates a concentration risk: as of mid-2025, a handful of relays handle the overwhelming majority of MEV-Boost blocks, meaning a small number of off-chain entities exert significant influence over Ethereum's block production pipeline.

Beyond trust, the current system imposes latency costs. Validators must wait for relay responses during the tight block proposal window, increasing the risk of missed attestations and late blocks. The relay infrastructure also introduces a competitive moat: only well-resourced operators can run high-performance relays, further centralizing the ecosystem.

How ePBS Works Technically

EIP-7732 addresses these problems by moving the proposer-builder separation logic directly into the Ethereum consensus layer. Under ePBS, the protocol itself recognizes two distinct roles in block production: the proposer (the validator selected by the beacon chain to propose a block) and the builder (a specialized entity that constructs the execution payload containing transactions).

Here is how a block production cycle works under ePBS. First, builders submit signed execution payload headers to the beacon chain, committing to a specific block and a payment to the proposer. The proposer selects the best header (typically the highest payment) and includes it in the beacon block. The builder then has a short window — defined within the slot — to reveal the full execution payload. If the builder fails to reveal, the slot is treated as an empty payload block, protecting the validator from being blamed for a missed block.

The critical innovation is that the payment commitment is cryptographically enforced on-chain. The builder's payment to the validator is locked into the protocol, not dependent on the relay's honesty. This eliminates the trusted relay entirely. Validators no longer run MEV-Boost middleware; instead, they interact with the ePBS mechanism natively through their consensus client.

EIP-7872 (Max Blob Flag) is a supporting EIP that extends the payload header to include blob count commitments, ensuring that the ePBS header-payload split works correctly in a post-Fusaka world where blob data availability is a significant part of block content. Without EIP-7872, builders could misrepresent blob counts in their headers, creating a mismatch upon payload reveal.

Benefits for Validators

The shift to ePBS delivers several concrete advantages for validators operating on Ethereum in 2026 and beyond.

• Guaranteed MEV payments: Because the builder's payment is enforced by the protocol, validators receive their promised MEV revenue without trusting a relay. This makes MEV income more predictable and auditable.

• Timely attestations: By removing the relay round-trip from the critical path, validators can attest more reliably within the attestation deadline. This reduces the incidence of late votes, which carry reduced rewards under the current attestation scoring mechanism.

• Lower hardware requirements: Validators no longer need to run MEV-Boost software alongside their beacon and execution clients. This simplifies the infrastructure stack and may reduce the VPS or bare-metal specifications needed for a competitive validator setup.

• Reduced centralization exposure: With relays removed from the equation, the block production market becomes more open. Smaller builders can participate without needing relationships with dominant relay operators, reducing the systemic risk that a relay outage creates for the entire network.

• Protocol-level accountability: Builder behavior is now observable on-chain. If a builder consistently fails to reveal payloads, that track record is visible to all participants, enabling market-driven accountability without needing off-chain reputation systems.

EIP-7928: Block-Level Access Lists and Parallel Execution

While ePBS dominates the Glamsterdam narrative, EIP-7928 may prove to be the upgrade's most consequential change for raw network throughput. EIP-7928 introduces Block-Level Access Lists (BLALs), a mechanism that allows transactions within a block to declare in advance which storage slots and accounts they will read or write.

Ethereum's Ethereum Virtual Machine (EVM) has historically been strictly sequential: transactions execute one after another in the order they appear in the block. This design guarantees deterministic state transitions but leaves significant computational capacity on the table, because most transactions within a block touch entirely different parts of the state and could theoretically be executed in parallel without any conflicts.

EIP-7928 formalizes the access declaration pattern. Builders (now acting as the exclusive constructors of execution payloads under ePBS) annotate each block with a list of state accesses organized by transaction. Execution clients can then identify non-conflicting transaction sets — groups of transactions that touch completely separate state — and execute them simultaneously across multiple CPU cores.

The performance implications are dramatic. The Glamsterdam specification targets a gas limit increase from 30 million to 200 million gas per block, a 6.6x increase that would be technically reckless without parallel execution. By pairing BLALs with the higher gas limit, the EIP enables a theoretical throughput of 10,000 transactions per second on the base layer, a landmark figure that reduces Ethereum's dependence on Layer 2 rollups for everyday transaction volume.

For validators, BLALs have secondary benefits. Parallel execution reduces the time required to process large blocks, which matters as the gas limit rises. This keeps block processing within the slot time even as block complexity increases, preventing the kind of processing delays that can cascade into missed proposals and orphaned blocks.

For stakers monitoring network health, the gas limit expansion combined with parallel execution is expected to produce the projected 78.6% reduction in average gas fees, making Ethereum more competitive with high-throughput L2s and alternative L1 chains on a pure cost-per-transaction basis.

Other Key EIPs: 7942, 8045, and 7872

EIP-7942: Available Attestation for Improved Finality

Ethereum's finality mechanism depends on validators attesting to the head of the chain promptly and accurately. EIP-7942 introduces the concept of Available Attestation, which adjusts the attestation validity rules to account for the new two-phase block structure introduced by ePBS.

Under ePBS, a beacon block may be published with a valid header but without a revealed execution payload (if the builder fails to deliver). EIP-7942 ensures that validators can attest to such a beacon block as available — confirming that the beacon block itself is valid even if the payload is missing — without being penalized for attesting to an incomplete block. This prevents a failure by a single builder from cascading into a finality delay caused by validators refusing to attest to an uncertain chain head.

In practical terms, EIP-7942 improves finality robustness. Epochs complete on time even when individual builders misbehave, because validators have a clean protocol path to continue attesting without ambiguity. This benefits all stakers by reducing the frequency of non-finality events, which are periods of uncertainty that increase risk for active validators.

EIP-8045: Excluding Slashed Validators from Proposing

EIP-8045 closes a subtle but meaningful security gap in the current protocol. Under the existing rules, a validator that has been slashed — meaning it has been penalized for a provably malicious or contradictory action — continues to be eligible for block proposals during the withdrawal delay period, which can last up to 36 days.

This creates an incentive problem. A slashed validator that knows it will be exited and heavily penalized has nothing further to lose from misbehaving as a proposer during that window. EIP-8045 simply removes slashed validators from the proposer selection set entirely. Once a validator is marked as slashed by the beacon chain, it can no longer be chosen to propose a block.

For honest validators and stakers, this change improves the overall safety of block proposals and removes a potential attack vector. For ChainLabo and other professional staking operators, it reinforces the importance of maintaining validator health, since a slashing event now has immediate and broader consequences beyond the direct financial penalty.

EIP-7872: Max Blob Flag

As noted in the ePBS section, EIP-7872 extends the execution payload header format to include a Max Blob Flag. This flag allows builders to specify the maximum number of blobs their payload will contain when the full execution payload is revealed. Validators and the beacon chain can then verify that the revealed payload does not exceed the committed blob count.

This seemingly small addition is critical for the integrity of the ePBS commitment mechanism in a world where blob transactions (EIP-4844 type transactions carrying data for rollups) represent a significant and growing share of block content. Without the Max Blob Flag, builders could commit to a low-fee header while later revealing a payload packed with expensive blob data, disrupting fee market equilibria and potentially gaming validator MEV payments.

How Glamsterdam Affects Staking Rewards and Validator Economics

The combined effect of Glamsterdam's EIPs on validator economics is substantial and largely positive for active, well-maintained validators.

The elimination of MEV-Boost relays under ePBS means that all validators automatically participate in the MEV market through the native protocol mechanism. Today, a validator that does not run MEV-Boost software forgoes MEV income entirely. Post-Glamsterdam, MEV payments are delivered through the consensus layer itself, so validators receive builder payments regardless of whether they have historically engaged with MEV infrastructure.

The guaranteed payment structure also changes the variance profile of validator rewards. Under MEV-Boost, a validator might occasionally miss a high-value block because the relay was slow or offline. Under ePBS, the builder's committed payment is locked in as soon as the header is included in the beacon block. If the builder fails to reveal, the validator still receives a default base reward, and the failed builder faces protocol-level consequences. This reduces the tail-risk of unexpected reward gaps.

The gas limit increase to 200 million, combined with lower average gas fees, may initially seem to reduce per-transaction priority fee income for validators. However, the projected 10,000 TPS throughput means dramatically more transactions per block. Even if each transaction pays a smaller priority fee, the total priority fee revenue per block grows substantially with volume. Early modeling from Ethereum researchers suggests that high-throughput blocks under Glamsterdam could yield meaningfully higher priority fee totals than current low-throughput, high-fee blocks.

The 70% reduction in MEV centralization has long-term implications too. As the builder market becomes more competitive and accessible under ePBS, the premium paid by builders to win block auctions should reflect true market competition rather than oligopolistic pricing. For validators, this means more competitive MEV payments over time as the builder ecosystem matures.

What Validators Must Do to Prepare for Glamsterdam

Preparing for a hard fork of this complexity requires action on multiple fronts. Below is a comprehensive preparation checklist for validators.

✓ Monitor client release schedules: All major consensus clients (Lighthouse, Prysm, Teku, Nimbus, Lodestar) and execution clients (Geth, Nethermind, Besu, Erigon, Reth) will need to ship Glamsterdam-compatible releases. Subscribe to release channels and plan upgrade windows in advance.

✓ Test on public testnets: Public Glamsterdam testnets are expected in spring 2026. Run your full validator stack — consensus client, execution client, and validator client — on the testnet environment before mainnet activation. Pay special attention to the ePBS flow, as the payload reveal mechanism introduces new timing requirements.

✓ Remove MEV-Boost from your stack: After Glamsterdam activates, MEV-Boost middleware becomes redundant and potentially disruptive. Plan a clean removal of MEV-Boost from your validator infrastructure. Do not attempt to run MEV-Boost alongside ePBS, as the two mechanisms will conflict.

✓ Review hardware and disk provisioning: The gas limit increase to 200 million means larger blocks. Ensure your storage I/O and CPU capacity can handle higher block processing loads, particularly if you run multiple validators on shared infrastructure.

✓ Verify withdrawal credentials and validator status: EIP-8045 immediately disqualifies slashed validators from proposing. Audit your validator set for any edge cases. Ensure all validators have current 0x01 or 0x02 withdrawal credentials.

✓ Understand the new attestation rules: EIP-7942 changes how available attestations are handled. Review updated client documentation on attestation behavior under ePBS to ensure your validator votes correctly during the transition period.

✓ Track Devnet-5 outcomes: Follow the Ethereum Magicians forum and ACD call notes for Devnet-5 findings. Known issues discovered in devnet will inform the final mainnet release, and early awareness allows you to anticipate any last-minute configuration changes.

✓ Coordinate with your staking provider: If you use a managed or non-custodial staking service, confirm their upgrade timeline and client support schedule. Ensure there is no gap between mainnet fork activation and your infrastructure running a compatible client version.

Glamsterdam and Non-Custodial Staking

For stakers who prefer to retain full control of their withdrawal keys while outsourcing validator operations, Glamsterdam reinforces the advantages of non-custodial staking architectures. Under the post-Glamsterdam protocol, MEV payments are delivered natively to the validator's fee recipient address — an address that, in a non-custodial setup, belongs exclusively to the staker, not the operator.

This is an important distinction. In custodial staking arrangements, the operator controls the fee recipient and distributes MEV income according to their own accounting logic. In non-custodial setups, ePBS payments flow directly and transparently to the staker's designated address, fully auditable on-chain. The elimination of trusted MEV-Boost relays under ePBS thus strengthens the non-custodial value proposition: stakers gain both improved MEV capture and greater payment transparency simultaneously.

The hardware simplification brought by ePBS also benefits non-custodial operators. Removing MEV-Boost from the validator stack reduces the surface area for operational errors and software conflicts. Professional providers who have historically maintained complex MEV-Boost configurations across multiple relays can streamline their infrastructure, improving reliability and potentially reducing costs passed on to stakers.

ChainLabo's non-custodial staking platform is actively tracking the Glamsterdam upgrade timeline and client compatibility requirements. As a provider committed to validator sovereignty and transparent reward delivery, ChainLabo will ensure full Glamsterdam-compatible client deployments are in place ahead of public testnet milestones, giving stakers confidence that their validators will transition smoothly without reward disruption.

The broader lesson of Glamsterdam for the staking industry is that Ethereum's protocol upgrades are progressively encoding trust minimization into the base layer. Features that previously required trusting third-party middleware — relays, external builders — are being absorbed into the consensus protocol itself. For non-custodial stakers, this trajectory is consistently positive: each upgrade reduces the number of external parties whose honesty must be assumed for rewards to flow correctly.

Conclusion

The Ethereum Glamsterdam upgrade represents one of the most ambitious single hard forks in the protocol's history. By enshrining proposer-builder separation through EIP-7732, Ethereum eliminates a four-year dependency on trusted MEV-Boost relays and replaces it with a cryptographically enforced, on-chain block auction mechanism. By pairing this with EIP-7928's Block-Level Access Lists and a 200 million gas limit, the upgrade simultaneously targets a 6.6x increase in base-layer throughput, with projected gas fee reductions that could fundamentally change Ethereum's competitive position.

For validators, the upgrade brings guaranteed MEV payments, simplified infrastructure, better attestation reliability, and improved security through EIP-8045's slashed validator exclusion. For stakers, it means more transparent reward flows, a more competitive builder market, and a protocol that is structurally less dependent on trusted intermediaries.

The preparation window is real and finite. With Devnet-5 underway and public testnets targeting spring 2026, validators have roughly six to nine months to audit their infrastructure, plan client upgrades, and familiarize themselves with ePBS's new timing requirements. Those who act early will navigate the fork smoothly; those who wait may find themselves scrambling during a high-stakes transition period.

Glamsterdam is not just another incremental Ethereum upgrade. It is the completion of an architectural vision — trust-minimized block production at scale — that the Ethereum research community has been working toward since the Merge. For everyone with skin in the game as a validator or staker, now is the time to understand it deeply and prepare accordingly.