ePBS stands for enshrined proposer-builder separation. It is the change, specified in EIP-7732, that moves Ethereum’s block-building marketplace out of trusted off-chain middleware and into the protocol itself. Today, a validator who wants a professionally built block hands the deal to a relay, an unpaid third party that both sides simply have to trust. Under ePBS the builder’s signed bid goes into the beacon block directly, payment is enforced by consensus, and the relay’s trust role disappears. It ships as the headline consensus change of Glamsterdam, the hard fork after Fusaka, currently targeted at mainnet in the second half of 2026.
This post answers the question from the ground up: why proposer-builder separation exists at all, what problem relays created, how EIP-7732 restructures the pipeline, and what a slot looks like afterwards. The second half turns to the audience that feels this fork most directly, MEV searchers and block builders, and to why the new timing makes node latency matter even more. For everything else shipping in the fork, see our Glamsterdam upgrade guide.
Why ePBS exists: the problem relays created
Proposer-builder separation is older than EIP-7732. The idea is that the validator randomly chosen to propose a block, the proposer, should not need to be good at constructing one. Building a maximally profitable block is a specialist’s job: it means merging thousands of pending transactions, private order flow, and searcher bundles into the most valuable arrangement, and doing it fresh every twelve seconds. So the roles split. Builders construct blocks and bid for the right to have them proposed; proposers pick the highest bid and collect it. That separation keeps sophisticated MEV extraction from becoming a requirement for running a validator.
The catch is that Ethereum never had a protocol for this market. It emerged after the Merge as out-of-protocol infrastructure: MEV-Boost, a sidecar that roughly nine out of ten validators run today. The proposer asks relays for the best header, signs it blind, and trusts the relay to reveal the payload and to have verified that the builder’s payment is real. The relay is unpaid, trusted middleware holding the whole market together. If a relay is buggy, slow, or dishonest, proposers miss blocks or lose payment; builders leak their blocks; and the chain’s most important auction depends on a handful of altruistically operated servers that the protocol cannot see.
Enshrining PBS means writing that market into consensus so the trust job disappears. That is what EIP-7732 does, and it is why the “e” matters: ePBS is not a new market structure, it is the existing one with the middleman replaced by protocol rules.
How ePBS works under EIP-7732
ePBS moves the auction into the protocol. Builders register as staked entities on the beacon chain, in their own registry next to the validator set, and every bid they sign is backed by their on-chain balance. The beacon block stops carrying the execution payload entirely; instead it carries the winning builder’s signed bid, which commits to the exact block hash of a payload along with the bid value, gas limit, fee recipient, and blob commitments. The moment a proposer includes that bid, the value is deducted from the builder’s balance. Payment is unconditional, meaning the proposer gets paid even if the builder never reveals the payload, and that is precisely why nobody needs a relay to escrow trust anymore.
The payload itself arrives later in the slot. After the beacon block has been attested, the builder publishes the full payload, and a Payload Timeliness Committee (PTC) of 512 validators attests to whether it showed up on time. Full execution validation moves off the attestation critical path entirely. Proposers who want nothing to do with the market can still build their own payload; self-building stays a first-class option in the protocol.
Glamsterdam pairs this consensus-side change with EIP-7928 Block-Level Access Lists on the execution side, which is what unlocks the fork’s push toward much higher gas limits; we cover that half in the Block-Level Access Lists explainer. But for the block production pipeline, ePBS is the change that rearranges the furniture.
The new slot anatomy
The point of splitting consensus from execution is time. Today a block has roughly two seconds to propagate and be validated before attestations are due. Under ePBS that critical window stretches to roughly nine seconds, because attesters vote on the consensus block without executing the payload at all.
The slot opens with the proposer publishing the beacon block, which locks the payload contents to a specific block hash. Attesters vote on that consensus block early in the slot without touching the payload. Somewhere around the middle of the slot the builder reveals the full payload (blobs get their own, later deadline), and the PTC attests that the payload matching the committed hash arrived in time. The rest of the slot belongs to execution: nodes apply the payload and update state, and execution validity is checked against the next block instead of blocking this slot’s attestations.
The exact second marks are still being tuned on devnets, but the shape is settled, and two properties of it matter enormously for anyone who trades on chain state: the payload is committed at the slot boundary, and it becomes public only mid-slot.
What ePBS means for searchers and builders
Everything above is the protocol view. This section is for the people inside the pipeline: the builders who bid for slots and the searchers who feed them bundles. The short version is that the strategy layer of MEV mostly survives ePBS intact, while the timing layer does not. The auction moves on-chain, the payload lands mid-slot instead of at the slot boundary, and the window in which a bundle can reach a builder and make it into a committed payload gets meaningfully tighter. Everything that was already a latency game becomes more of one.
Builders: a capital business with a new auction
Building becomes a capital business. Unconditional payment means your beacon chain balance has to cover your bids, and while the registry minimum is small, bidding competitively on a high-value block means parking serious collateral on-chain and eating its opportunity cost. Expect consolidation pressure, and expect new financial plumbing around it; some relays are already positioning themselves as capital providers that re-sign bids for a fee rather than as auctioneers.
The auction changes shape as well. Bids travel over two channels: a rate-limited p2p gossip topic that is public but not cancellable, and direct connections to proposers that are cancellable and faster. The transparent second-price dynamics of today’s relay auctions do not carry over cleanly, because builders with direct proposer connectivity can shade their public bids, which pushes the market toward first-price, sealed-bid behavior. Bid strategy becomes a genuinely new problem to solve.
A builder that wins the header can also simply decide not to reveal the payload. The bid is paid regardless, so the downside is capped, and in volatile moments the option to abandon a committed payload has real value. Slots will occasionally go empty in ways today’s pipeline does not produce.
Relays, meanwhile, stop being load-bearing. Nothing in ePBS needs a trusted third party to exchange a blind header for a payload or to vouch for payment, so whatever survives of the relay ecosystem survives as optional infrastructure for bid distribution, analytics, and capital services.
Searchers: same counterparties, less time
Your relationships do not change: you still send bundles and private flow to builders, and builders still compete to include them. What changes is when everything has to happen.
Start with the window. Today the parent payload is public at the slot boundary, so a builder has essentially a full slot, ten seconds and more, to build on known state before the next proposal locks. Under ePBS the parent payload only becomes public mid-slot, while the next header still locks at the next slot boundary. That leaves roughly four to six seconds of building on fresh state, depending on where the reveal deadline finally lands. Your bundle has to reach a builder, simulate against the new parent state, and get merged into the payload whose hash the builder commits to, all inside that window.
The head of the chain also starts arriving in two steps. The consensus block tells you which payload hash won; the state behind it only exists for you once the payload is revealed and your node has executed it. If your view of the chain comes from a public RPC provider, you are waiting on their fan-out, their nodes’ execution, and the public internet, stacked on top of a reveal that already happens mid-slot. The searchers who see post-state first are the ones whose code sits where the payload lands.
Withholding adds a kind of variance searchers have not had to price before. When a builder abandons a committed payload, every bundle inside it dies too, and the state you predicted never materializes. Detecting an empty slot fast, from the PTC signal and your own node’s view rather than a delayed provider feed, decides whether you re-target the next block in time. And none of this makes timing games disappear: proposers can still propose late, builders will reveal as close to the deadline as tolerated, and cancellable direct-connection bids keep last-look dynamics alive. The games move earlier in the pipeline and run on smaller margins.
Why latency to the node matters more under ePBS
Every one of these changes shrinks a time budget that was already tight, and that raises the price of every network round-trip in your loop. We covered the general argument in why MEV is a latency game; ePBS sharpens it. A multi-pool simulation that does its state reads over public RPC spends a real fraction of a four-to-six-second window on round-trips alone, while the same loop running on the node does those reads as local socket calls. The per-call gap between those transports is measured in IPC vs HTTP vs WebSocket.
The payload reveal becomes the new critical moment. The instant it hits the wire, your node executes it and the post-state exists on that machine, so co-located code reads it immediately while remote code waits on a provider pipeline it can neither see nor control. The mempool stays decisive too, because ePBS does not touch it: pending transactions remain the raw material, and watching them from your own node’s connection beats a downstream relay. The mechanics are in how to access the Ethereum mempool, and you can watch the pool live on the BLAZED.sh mempool visualizer.
This is exactly the model BLAZED.sh is built around: your container or script deploys onto the same host as a fully synced Ethereum mainnet node and talks to it over a local socket at sub-10ms round-trips instead of racing across the public internet. When the game restructures around a mid-slot reveal and a compressed build window, being on the node is not an optimization, it is the starting line.
How to prepare before Glamsterdam ships
There is a concrete checklist hiding in all of this. Rehearse against the public testnets; Sepolia and Hoodi fork before mainnet, and the exact slot timings and PTC parameters will settle there, so you can learn the new rhythm somewhere other than mainnet. You can track the fork milestones on the Glamsterdam countdown. Measure your full trigger-to-submission path today, because anything that spends a second on remote round-trips will not fit comfortably in a post-ePBS build window. And move the evaluation loop onto the node, so the mempool subscription, the state reads, and the view of the payload reveal are all local. The deployment docs cover containers and scripts, supported networks lists what is live, and RPC pricing explains the per-request credit model.
FAQ
Is ePBS live?
Not yet. As of July 2026, EIP-7732 is locked into the Glamsterdam fork and multi-client devnets have been running the full slate since June; Glamsterdam entered its final devnet stage in mid-June 2026. The Sepolia and Hoodi public testnet forks come next, and mainnet is targeted for the second half of 2026, realistically toward the end of the year given how much testnet seasoning recent forks have needed. Client teams have been explicit that getting ePBS right outranks hitting a date, so treat any specific month as provisional.
What is the difference between PBS and ePBS?
PBS, proposer-builder separation, is the market structure in which specialized builders construct blocks and validators merely propose the best bid; Ethereum already has it today via MEV-Boost, entirely outside the protocol. ePBS is the same structure enshrined in consensus by EIP-7732: builders stake on the beacon chain, bids ride inside the beacon block, and payment is enforced by protocol rules instead of relay trust.
ePBS vs MEV-Boost: does ePBS kill relays?
It removes their trust role. The header-for-payload exchange and the payment guarantee move into the protocol, so proposers no longer need MEV-Boost or a trusted relay to outsource building safely. Relay-like services may persist for bid distribution, analytics, and builder capital, but they stop being load-bearing.
Do searchers need to stake under ePBS?
No. Only builders register and stake on the beacon chain. Searchers keep sending bundles to builders exactly as today; what changes for searchers is timing, not access.
Does ePBS change the mempool?
No. Public and private transaction flow work as before. The mempool remains the primary signal source for searchers, and low-latency access to it remains an edge.
Conclusion
ePBS is Ethereum absorbing the block-building market it already has: EIP-7732 replaces the trusted relay with staked builders, in-protocol bids, and unconditional payment, and it re-times the entire pipeline while doing so. The auction commits at the slot boundary, the payload lands mid-slot, and the window between fresh state and the next committed block shrinks to a few seconds. Strategy still decides which plays are worth making; under ePBS, latency decides even more of who makes them. If your searcher currently races over public RPC, the time to fix that is before Glamsterdam reaches mainnet, not after. Start with the co-location argument, then the deployment docs.