Ethereum Glamsterdam Upgrade Explained: How ePBS and EIP-7732 Will Transform Block Production for Developers

Ethereum's next major hard fork has a name, a timeline, and a headliner proposal that could fundamentally reshape how blocks are built on the network. Glamsterdam, targeted for the end of August 2026, introduces Enshrined Proposer-Builder Separation (ePBS) through EIP-7732 — moving the block-production auction from off-chain middleware directly into the consensus layer.

For developers building on Ethereum, this is not a distant theoretical change. Devnet-5 testing is already underway, and the implications for MEV, gas economics, validator infrastructure, and smart contract deployment are immediate. This guide breaks down what ePBS means, how Glamsterdam changes the block-production pipeline, and what developers need to prepare for.

What Is Ethereum Glamsterdam?

Glamsterdam is the hard fork that follows Fusaka on the Ethereum roadmap. While Fusaka focused on data availability through PeerDAS and blob scaling, Glamsterdam targets the block-production layer itself. The upgrade carries two headliner EIPs confirmed by Vitalik Buterin in February 2026: EIP-7732 (Enshrined Proposer-Builder Separation) and EIP-7928 (Block-Level Access Lists for parallel transaction execution).

The fork also raises the gas limit floor to 200 million — more than quadrupling current throughput capacity — and lays groundwork for 10-second finality. But the centerpiece is ePBS, which restructures the most fundamental operation on the network: how a block gets from a set of pending transactions to a finalized entry in the chain.

The Problem ePBS Solves: Why MEV-Boost Is Not Enough

Since The Merge in 2022, Ethereum has operated with a de facto separation between proposers and builders. Validators (proposers) outsource block construction to specialized builders through MEV-Boost, an off-chain relay system maintained by Flashbots. Builders compete to assemble the most profitable block, and the winning builder's payload is delivered to the proposer through a trusted relay.

This system works, but it introduces serious trust assumptions. Relays can censor transactions, go offline, or become single points of failure. Builders must trust that relays will not steal their block contents. Proposers must trust that the relay faithfully represents the builder's bid. None of these guarantees are enforced by the protocol — they depend entirely on the reputation of a handful of relay operators.

The numbers tell the story: over 90% of Ethereum blocks currently flow through MEV-Boost relays. That means a critical piece of Ethereum's block production pipeline sits outside the protocol, governed by social trust rather than cryptographic enforcement. ePBS changes that.

How EIP-7732 Works: The Technical Breakdown

EIP-7732 splits each Ethereum block into two distinct components: a consensus block (produced by the proposer) and an execution payload (produced by the builder). The proposer no longer needs to know the contents of the execution payload. Instead, the protocol enforces a structured handoff.

Here is how the new flow works. At the start of a slot, the proposer broadcasts a beacon block that includes a builder's signed commitment — essentially a bid for the right to fill the execution portion of the block. The builder then reveals the execution payload separately. The protocol verifies that the payload matches the commitment and that payment was made. If the builder fails to deliver, the proposer still gets paid through an unconditional payment mechanism.

This design eliminates the need for trusted relays entirely. The auction moves on-chain: builders submit bids, proposers select them, and the protocol enforces delivery and payment. No middleware, no trust assumptions, no off-chain infrastructure required.

From a security perspective, the Ethereum Foundation has published a formal security analysis of the ePBS design. The key properties it enforces are: builders cannot steal proposer slots, proposers cannot extract builder payloads before commitment, and the unconditional payment mechanism prevents griefing attacks where builders bid but never deliver.

EIP-7928: Parallel Transaction Execution

The second headliner in Glamsterdam is EIP-7928, which introduces block-level access lists. Today, Ethereum processes transactions sequentially — each transaction must complete before the next one begins, because the EVM cannot know in advance which state a transaction will touch.

EIP-7928 requires transactions to pre-declare their state access patterns. This lets the execution engine identify which transactions are independent and can run in parallel without conflicts. The result is significantly higher throughput without increasing the gas limit — the same number of transactions execute faster because non-conflicting ones run simultaneously.

For smart contract developers, this means access-list-aware contract design becomes a performance optimization. Contracts that cleanly declare their storage access patterns will benefit from parallel execution, while those with unpredictable state access will continue to execute sequentially.

What Glamsterdam Means for Developers

The developer impact of Glamsterdam spans several areas. First, MEV strategies change fundamentally. Builders will interact with an on-chain auction rather than off-chain relays. Searcher-builder relationships, bundle submission, and MEV extraction all need to adapt to the new in-protocol mechanism. If you build MEV infrastructure, Glamsterdam is a hard deadline for migration.

Second, the 200 million gas limit floor opens new design space. Contracts that were previously gas-constrained can now execute more complex logic in a single transaction. Batch operations, on-chain governance votes with large voter sets, and complex DeFi composability all become more practical.

Third, EIP-7928's parallel execution rewards clean state management. Developers who structure their contracts to minimize storage slot collisions will see real performance gains. This is especially relevant for high-throughput applications like DEXs, lending protocols, and NFT marketplaces where multiple independent operations happen in the same block.

Finally, the move toward 10-second finality — while not fully delivered in Glamsterdam — reduces confirmation times for time-sensitive applications. Payment flows, oracle updates, and cross-chain messaging all benefit from faster finality.

Glamsterdam Timeline and Current Status

As of June 2026, Glamsterdam development is in active testing. Devnet-5 is live, and client teams are integrating the ePBS changes into their consensus and execution clients. The Ethereum Foundation's target is end of August 2026 for mainnet deployment, though core developers have described this as aspirational rather than confirmed.

The fork tracker maintained by ETH Daily shows EIP-7732 as the primary scheduled proposal, with FOCIL (Fork-Choice Enforced Inclusion Lists) declined for this fork cycle. The Glamsterdam scope is intentionally focused — ePBS and parallel execution are large enough changes that the core team is avoiding scope creep.

After Glamsterdam, the next fork on the roadmap is Hegota, targeted for H2 2026. Hegota will introduce Verkle trees for stateless validation and continue the infrastructure hardening that Glamsterdam begins.

How to Prepare Your dApp for Glamsterdam

Start by auditing your contract's state access patterns. If you are building contracts that will benefit from parallel execution under EIP-7928, ensure your storage layout minimizes cross-contract state dependencies. Isolate independent operations into separate storage slots where possible.

If your application interacts with MEV infrastructure — whether you are a searcher, a protocol with MEV-aware features, or a builder — begin reviewing the EIP-7732 specification and the Ethereum Foundation's ePBS security analysis on GitHub. The transition from relay-based PBS to enshrined PBS will require changes to how you submit and manage transaction bundles.

For general dApp development, the gas limit increase to 200 million means you can revisit designs that were previously constrained by per-block gas limits. Complex batch operations, on-chain computation that was previously pushed to L2s, and richer smart contract interactions all become more viable on L1.

If you are building smart contracts or full-stack dApps on Ethereum and want to ship faster, thirdweb offers developer tools and infrastructure plans that scale with your project — check out thirdweb.com/pricing to find the right fit for your team.

The Bottom Line

Glamsterdam is not an incremental patch. Enshrined proposer-builder separation rewrites the trust model of Ethereum's block production, parallel execution unlocks new throughput without brute-forcing gas limits, and the 200 million gas floor gives developers room to build things that were not previously possible on L1.

For developers, the time to prepare is now. Devnet testing is live, the EIP specifications are finalized, and the mainnet target is less than three months away. Whether you are optimizing for MEV, designing gas-efficient contracts, or building the next generation of on-chain applications, Glamsterdam changes the playing field.