Proposer-builder separation (PBS) splits one job into two. On Ethereum today, the validator chosen to propose a block usually doesn't decide what goes in it. A specialist called a builder assembles the block, bids for the right to have it published, and the validator signs the winning bid — often without ever seeing what's inside.
If that sounds like a strange arrangement for a network built on trust minimization, that's the right instinct. PBS exists because of an uncomfortable discovery: building the most profitable block is a specialist's game, and pretending otherwise doesn't make the specialists go away — it just decides whether they operate inside the validator set or alongside it. The previous post covered the Scourge, the roadmap track that owns this problem. This one explains the mechanism itself: how the split works today, why it's held together by trusted intermediaries, and what enshrining it into the protocol would change.
Why the Split Exists
Start with the problem. Every block has an ordering, and ordering is worth money — this is MEV, the value extractable by whoever sequences transactions. Capturing it well requires sophisticated algorithms, low-latency infrastructure, and constant iteration. A home validator running on a mini PC cannot compete with a firm running optimization software against the mempool in real time. Not "will struggle to compete." Cannot.
Left alone, that asymmetry pushes proof of stake toward a bad equilibrium: sophisticated operators earn meaningfully more per block, stake compounds toward them, and the validator set centralizes around MEV skill rather than honest participation. PBS is the response. If block construction is going to professionalize no matter what, separate it from block proposal — let builders specialize and compete, and let validators stay simple, collecting the auction proceeds without needing any of the infrastructure.
The design goal, compressed: keep the proposing role decentralized by conceding that the building role won't be.
How the Auction Actually Works
What runs in production today is mev-boost — an out-of-protocol implementation built by Flashbots, adopted around the Merge in 2022. Ethereum's consensus rules know nothing about it. The flow for a single 12-second slot looks like this:
- Builders assemble candidate blocks. They pull from the public mempool and from private order flow (transactions sent directly to builders to avoid front-running), then sequence everything to maximize total value.
- Builders bid. Each submits its block to a relay along with a bid — the amount the proposer gets paid if this block wins.
- The relay verifies and escrows. The relay checks that the block is valid and the bid is real, then shows the proposer only the block header and the bid amount.
- The proposer signs blind. The validator picks the highest bid and signs the header without seeing the block's contents.
- The relay releases the body. Only after the signature exists does the full block get published to the network.
The blind signing in step four is the load-bearing piece, and it's worth pausing on. If proposers could see block contents before committing, they could steal the builder's work — copy the profitable ordering, publish it as their own, keep the MEV and skip the payment. The commitment has to come before the reveal, or the market collapses. Roughly nine in ten Ethereum blocks flow through this pipeline. Validators who opt out just build blocks locally the old way, and generally earn less for it.
Where the Trust Sits
Notice what step three did. The builder can't trust the proposer not to steal, and the proposer can't trust the builder's bid without verification — so both trust the relay instead. The relay sees the full block, holds it in escrow, vouches for its validity, and releases it at the right moment. It performs this coordination for free, as neutral infrastructure, with no protocol-level accountability.
That's the soft spot, and it isn't hypothetical. Relays can censor — after the 2022 Tornado Cash sanctions, several major relays filtered sanctioned transactions, and for a stretch a majority of blocks ran through filtering relays. Relays can fail — in 2023 a proposer exploited a relay's release logic to grab block contents early and take roughly $20 million from sandwich bots. And relays can simply shut down, since nothing pays them.
The builder market has its own concentration problem: a small number of firms assemble the large majority of blocks, competing on private order flow as much as on algorithms. The hard constraint underneath everything is time — twelve seconds per slot, within which building, bidding, verification, and propagation must all finish. That latency pressure is itself a centralizing force. It rewards colocation and punishes distance, which is part of why the builder set stays small.
So the honest summary of PBS today: it succeeded at keeping validators simple, and it did so by relocating the trust into unpaid intermediaries the protocol can't see.
What's Changing
The roadmap response is to enshrine the separation — move the commit-reveal guarantee from relays into consensus rules. The proposal carrying this is EIP-7732, usually just called ePBS. Under it, the beacon chain itself splits a block into a consensus portion and an execution payload: the proposer commits to a builder's payload in-protocol, a committee of validators attests that the payload arrived on time, and builder payment is enforced by consensus rather than by a relay's word. The relay's escrow job stops existing.
Alongside it sits a complementary proposal, EIP-7805 — fork-choice enforced inclusion lists (FOCIL) — which attacks the censorship half of the problem: a set of validators names transactions the builder must include, so a dominant builder can delay a transaction but can't durably exclude it. Both are in the specification stage as of mid-2026, further than protocol-level MEV work has ever progressed, with no confirmed fork date. Given the EIP process and fork cadence, treat scheduling claims skeptically until an item appears on an actual fork agenda.
What Would Confirm This Direction
ePBS or FOCIL scheduled into a named hard fork — that's the strongest signal, because the Scourge track has never shipped consensus code. Short of that: relay count and relay dependence declining, censorship metrics improving (fewer filtered blocks, shorter inclusion delays for sanctioned-adjacent transactions), and the builder market gaining entrants rather than losing them.
What Would Break It
The builder market collapsing to an effective monopoly would undermine the premise — an auction with one bidder isn't an auction, and inclusion lists only mitigate the censorship symptom, not the pricing power. A serious relay failure before enshrinement ships would be a different kind of break: damage arriving faster than the fix. And ePBS proving incompatible with other consensus-layer changes — shorter slots, single-slot finality — would send the design back to research. A quieter failure mode: order flow going private faster than the public auction can price it, hollowing out the mechanism while leaving its shell intact.
Timing
Now: mev-boost is the de facto standard — out-of-protocol, relay-dependent, handling the large majority of blocks. Next: watch fork agendas for EIP-7732 and EIP-7805; specification progress is real but unscheduled. Later: fully enshrined PBS interacting with slot-time changes and finality redesigns — direction agreed, multi-year horizon.
Boundary
This covers the mechanism: what PBS is, how the current implementation works, and what enshrinement would change. It is not a guide to running mev-boost, an assessment of any relay or builder as a business, or a claim about validator profitability. Which relays and builders matter, and the concentration thresholds worth acting on, are tracking questions — this is the static explanation; the tracked version lives elsewhere.
