If you have used Ethereum at any point in the last two years, there is a good chance that the block containing your transaction was not built by the validator who proposed it. Instead, it was assembled by a specialized entity called a “builder,” passed through a trusted middleman called a “relay,” and only then handed to the validator for signing and broadcasting. This system is known as MEV-Boost, and it currently handles over 90% of Ethereum’s blocks.
The problem is the word “trusted.” A compromised relay can censor transactions, withhold blocks, or become a single point of failure for the entire network. The Ethereum protocol itself has no visibility into who built the block, what they committed to, or whether they honored that commitment. All of that happens off-chain.
EIP-7732, titled Enshrined Proposer-Builder Separation (ePBS), changes this. It moves the entire proposer-builder exchange into the Ethereum protocol, replacing relay trust with cryptoeconomic guarantees enforced by the beacon chain. It is the headline feature of the upcoming Glamsterdam hard fork, targeted for 2026, and one of the most structurally significant changes to Ethereum since The Merge.
This article explains what ePBS is, how it works, why it matters, and what it means for different types of Ethereum users — from beginners to validators to DeFi traders.
The Problem: How Block Building Works Today
To understand ePBS, you first need to understand how Ethereum blocks are currently produced.
Since Ethereum moved to proof-of-stake in September 2022, validators are randomly selected to propose blocks in each 12-second slot. In theory, the selected validator could build the block themselves — collecting transactions from the public mempool, ordering them, and packaging them into a block. In practice, almost no one does this.
The reason is MEV, which stands for Maximal Extractable Value. MEV refers to the profit that can be captured by strategically ordering, inserting, or excluding transactions within a block. Common examples include front-running large DEX swaps (buying before a large order pushes the price up), sandwich attacks (placing trades on both sides of a victim’s swap to extract value), and liquidation sniping (being the first to liquidate an undercollateralized DeFi position for a reward).
Extracting MEV requires specialized infrastructure: powerful hardware, access to private order flow, and sophisticated algorithms. A home validator running standard software cannot compete with professional MEV searchers and builders. So instead, approximately 90% of Ethereum validators outsource block construction to specialized builders through a system called MEV-Boost, developed by Flashbots.
MEV-Boost works as follows. Builders construct blocks optimized for MEV extraction. They submit these blocks to relays — trusted intermediaries that hold the builder’s payload and the proposer’s signed header. The relay runs an auction: the proposer receives the block header with the highest bid (the fee the builder offers to pay), signs it without seeing the block contents, and the relay then releases the full block to the network.
This system works, but it has three critical weaknesses. First, relay trust: the proposer must trust the relay to actually release the block and not steal MEV. A malicious or compromised relay could withhold the payload, censor specific transactions, or collude with builders. Second, centralization: as of 2025-2026, a small number of relays process the vast majority of MEV-Boost blocks. The MEV-Boost dashboard (mevboost.pics) shows that approximately 92.7% of Ethereum blocks are MEV-Boost blocks, with a handful of relays dominating the market. Third, protocol blindness: the Ethereum protocol has zero knowledge of this entire process. From the protocol’s perspective, the validator built the block. There is no on-chain record of the builder, the bid, or the relay.
ePBS addresses all three problems by making the proposer-builder relationship a first-class protocol feature.
What ePBS Changes: The Core Mechanism
EIP-7732 fundamentally restructures how an Ethereum block is produced by splitting it into two distinct phases — consensus validation and execution validation — separated in both logic and time.
Here is how the new slot timeline works under ePBS.
At t = 0 seconds (slot start), the proposer broadcasts a BeaconBlock. This block no longer contains the full execution payload (the transactions, state changes, etc.). Instead, it contains a SignedExecutionPayloadBid: a signed commitment from a builder specifying the block hash, the value (payment to the proposer in Gwei), and blob KZG commitments.
At t = 4 seconds (attestation deadline), validators attest to the beacon block. They only need to validate the lightweight consensus state transition — not execute any transactions. This is dramatically faster than the current system, where validators must execute the full payload before attesting.
At t = 4-6 seconds, the builder broadcasts the full ExecutionPayloadEnvelope containing the actual transactions, execution requests, and state root.
At t = 6 seconds (PTC deadline), 512 randomly selected validators from the beacon committee — called the Payload Timeliness Committee (PTC) — attest to whether the builder revealed the payload on time and whether the blob data is available. PTC members do not execute the block. They only check that the payload arrived, that the block hash matches the earlier commitment, and that blob sidecars are available.
At t = 9 seconds, execution validation is complete across the network. All validators have had 9 seconds to validate the full payload — nearly double the current 4-second window.
At t = 12 seconds, the next slot begins.
How Payment Works Without a Relay
In the current MEV-Boost system, the relay acts as escrow. In ePBS, the beacon chain itself is the escrow.
Under EIP-7732, builders become staked entities on the beacon chain. They deposit ETH using a new withdrawal credential prefix (0x03), and their balance is tracked directly in the BeaconState. The minimum stake for a builder is just 1 ETH — far lower than the 32 ETH required for validators, because builders do not participate in consensus duties.
When a builder submits a bid for a slot, the moment that bid is included in a beacon block, the committed value is immediately deducted from the builder’s beacon chain balance and queued as a BuilderPendingPayment. This happens before any execution payload arrives.
From that point, the proposer’s payment is guaranteed regardless of what the builder does next. This produces three possible slot outcomes.
A “Full” slot is the normal case: both the beacon block and the execution payload are included on-chain. The builder paid the proposer, and the payload is canonical.
An “Empty” slot occurs when the beacon block is included but the builder fails to reveal the execution payload. The proposer still receives payment. The builder forfeits the bid value. The slot has no transactions, but the chain progresses.
A “Skipped” slot means no beacon block was proposed at all (the validator was offline). No builder is involved.
The “Empty” slot case is the key innovation. It is the cryptoeconomic replacement for relay trust. A builder who withholds their payload does not escape payment — they have already been charged. The only way for a builder to avoid payment is if the beacon block itself is withheld first, which is an attack on the proposer, not the builder.
The Payload Timeliness Committee (PTC)
The PTC is arguably the most elegant part of EIP-7732. The protocol needs a way to determine whether the builder revealed the payload on time, but it cannot force all 500,000+ validators to make that determination within the attestation window.
The solution is to designate exactly 512 validators per slot — drawn randomly from the beacon committee — whose only job is to attest to payload timeliness. They check two things: did the SignedExecutionPayloadEnvelope arrive with the correct block hash? And are the blob sidecars available?
That is it. No EVM execution. No state root verification. The checks take milliseconds. The threshold for a PTC decision is 60% — 307 of 512 members must agree.
The security margins are substantial. According to the EIP specification, an attacker controlling 35% of total stake would need, on average, approximately 205,000 years to achieve majority control of the PTC for a single slot.
Why ePBS Matters: Five Key Benefits
The shift from off-chain relay trust to on-chain protocol enforcement has cascading effects across the Ethereum ecosystem.
The first benefit is the elimination of relay trust. After ePBS, no trusted middleman is required for the proposer-builder exchange. The Ethereum protocol enforces the deal directly. Relays do not disappear overnight — they may persist as convenience layers — but they are no longer the trust anchor for block production.
The second benefit is censorship resistance. Under the current system, a relay can censor transactions by refusing to include blocks that contain them. With ePBS, the builder commits to a block hash on-chain, and the PTC verifies the reveal. Combined with future inclusion list proposals (like FOCIL in the Hegotá upgrade), ePBS creates the foundation for protocol-level censorship resistance.
The third benefit is fairer MEV distribution. Today, MEV profits accrue disproportionately to sophisticated builders and the relays they work with. Under ePBS, the competitive auction for block space happens transparently on-chain, and the payment flows directly to the proposer (validator). This means MEV rewards are distributed more evenly across the validator set, including home stakers.
The fourth benefit is faster attestation. By decoupling consensus validation from execution validation, ePBS removes the full execution payload from the “hot path” of block validation. Validators attest based on the lightweight consensus state transition alone. This reduces missed attestations, strengthens fork choice weight, and opens the door to including more blobs per block without increasing reorg risk.
The fifth benefit is a foundation for future upgrades. ePBS gives the Ethereum protocol visibility into who built the block and what they committed to. This makes it much easier to design future mechanisms like FOCIL (Fork-Choice Enforced Inclusion Lists), encrypted mempools, MEV-routing changes, and builder penalty systems.
ePBS and Block-Level Access Lists (BALs): The Glamsterdam Pair
ePBS does not arrive alone. The second confirmed EIP in Glamsterdam is EIP-7928, which introduces Block-Level Access Lists (BALs).
While ePBS restructures how blocks are built and proposed, BALs restructure how blocks are executed. Under the current system, Ethereum clients discover which accounts and storage slots a block touches only during execution. This forces sequential transaction processing — each transaction must complete before the next begins, because the client cannot predict state conflicts in advance.
EIP-7928 requires builders to include a verifiable map of all state accesses (accounts, storage slots read, storage slots written) in each block. The hash of this map (the BAL root) is committed in the block header. Receiving nodes can then prefetch all required state data from disk before execution begins, eliminating mid-execution storage round-trips and enabling the foundation for parallel transaction execution.
Together, ePBS and BALs address both sides of Ethereum’s block production pipeline: ePBS fixes how blocks are constructed and verified at the consensus layer, while BALs fix how blocks are executed at the execution layer. The gas limit target rises from 60 million to 200 million per block, enabling approximately 10x throughput improvement.
Development Status: Where Things Stand
As of May 2026, ePBS implementation is “slow but steady,” according to the Ethereum Foundation’s April 2026 Checkpoint update. The key milestones include the following.
The ePBS devnet has been stabilized. Multi-client Glamsterdam devnets are running with external builder pipelines tested end-to-end across nearly all clients, as confirmed in the May 2026 Protocol Cluster update from the Ethereum Foundation.
A 200 million gas limit floor has been established as a credible post-Glamsterdam target, derived from the convergence of ePBS, BAL optimizations, and EIP-8037 repricing work.
Client implementations are progressing in Prysm, Nimbus, Lodestar, and Lighthouse on the consensus side, with Reth, Geth, and other execution clients handling the BAL integration.
The first generalized Glamsterdam devnet launched in mid-April 2026, with subsequent devnets iterating to include more non-headliner features. The path to mainnet involves several more devnets, client releases, final security reviews, and testnet deployment before a mainnet fork date is announced.
The current target remains H1 2026, though the Ethereum Foundation’s April checkpoint noted that “Glamsterdam in Q2 seems unlikely.” A Q3 2026 mainnet activation appears more realistic based on current progress.
What ePBS Means for Different Users
For beginners and holders: you will not need to take any action. ePBS is a consensus-layer change that happens behind the scenes. The practical effects you will notice over time include potentially lower gas fees (from the paired BALs and gas repricing), fairer trade execution on DEXs (reduced MEV extraction), and a more robust and censorship-resistant network. If you hold ETH or use DeFi protocols, the network you rely on becomes structurally stronger.
For validators and stakers: the attestation workload becomes lighter (consensus-only validation in the hot path), and MEV rewards are distributed more transparently through the on-chain auction mechanism. If you run MEV-Boost today, it will eventually become optional rather than necessary. Your validator software will need to be updated for the Glamsterdam fork, as with any hard fork.
For builders: builders become staked protocol entities with on-chain identity. You will need to deposit ETH (minimum 1 ETH) into the beacon chain using the new 0x03 withdrawal credential. The bid-reveal mechanism is enforced on-chain, and failure to reveal a payload results in forfeiture of the bid value. Builders will also need to run or access a consensus layer client to compute the state root for the ExecutionPayloadEnvelope.
For DeFi traders: MEV extraction — front-running, sandwich attacks — could be reduced by up to 70% according to some estimates, meaning fairer execution for swaps, liquidations, and arbitrage. The on-chain auction mechanism also increases transparency around block space pricing.
ePBS vs. MEV-Boost: A Comparison
To summarize the structural differences:
Under the current MEV-Boost system, the builder is off-chain and invisible to the protocol; the proposer-builder exchange is mediated by a trusted relay; the proposer signs a blinded block header without seeing contents; payment is enforced by the relay; censorship resistance depends on relay behavior; and execution validation happens in the 4-second attestation window.
Under ePBS (EIP-7732), the builder is an on-chain staked entity with a registry identity; the exchange is enforced by the beacon chain through cryptoeconomic guarantees; the proposer includes a signed bid commitment in the beacon block; payment is deducted from the builder’s beacon chain balance before payload reveal; censorship resistance is structurally supported by protocol design (with FOCIL coming in Hegotá); and execution validation is deferred to a 9-second window after attestation.
Looking Ahead: ePBS as Foundation
ePBS is not the end state. It is the foundation for a series of upgrades that collectively move Ethereum toward a more decentralized, efficient, and censorship-resistant architecture.
FOCIL (EIP-7805), the headline feature for the Hegotá upgrade later in 2026, adds fork-choice enforced inclusion lists. Combined with ePBS, this would create protocol-level guarantees that specific transactions cannot be excluded from blocks.
Encrypted mempools, still in research, would prevent builders and proposers from knowing which transactions they are including until after the block is broadcast, further reducing MEV extraction opportunities.
Slot auctions, a potential future modification to EIP-7732, would remove the block hash commitment from the builder’s bid, allowing the builder to commit any payload to the slot rather than a specific pre-built block. This would improve user experience and give builders more time to optimize blocks.
All of these become structurally possible only because ePBS gives the protocol visibility into the block production process for the first time.
Conclusion
For nine years, Ethereum validators have been responsible for both proposing and building blocks. In practice, the building part has been outsourced to off-chain infrastructure that the protocol cannot see, verify, or enforce. ePBS changes that. It makes the builder a first-class protocol participant, the proposer-builder exchange a cryptoeconomically enforced deal, and the payload reveal a publicly verifiable event.
This is not the kind of upgrade that produces a single dramatic moment. It is the kind that restructures the plumbing of the network in ways that make every subsequent improvement — inclusion lists, encrypted mempools, parallel execution, ZK-verified state — easier to build and harder to break.
If the Glamsterdam upgrade ships on schedule, Ethereum will be the first major blockchain to enshrine proposer-builder separation at the protocol level, replacing trust with code at the most fundamental layer of block production.