Proposer–Builder Separation and MEV

The previous two frontiers turned dials on the participant: account abstraction changed what a user’s account can do, and verkle trees and statelessness changed what it costs to run a verifying node. This page turns a different dial — the one the overview labelled “who gets to build the next block, and who profits.” It is the first frontier that is fundamentally about economics and power, not capability.

The problem it attacks is one the security Part already named: whoever assembles a block chooses which transactions go in and in what order, and that ordering power is worth money. Here we don’t re-derive front-running or sandwiching — that page did. We take the fact as given and ask the structural question the frontier cares about: if ordering is worth money and requires specialist skill, what stops block-building from collapsing into the hands of a few professionals — and taking Ethereum’s decentralization down with it? Proposer–builder separation is the answer being built, and this page traces it from the version running today to the version proposed for the protocol itself.

Why ordering power centralizes block production

Start from first principles. A block is an ordered sequence of transactions applied one after another to the world state. Because a market’s price is a function of the order trades hit it, the party who fixes that order can extract value — MEV.

MEV stands for Maximal Extractable Value (originally Miner Extractable Value, pre-Merge). It is the profit a block producer, or anyone who can influence ordering, can capture purely by choosing which transactions to include and in what order, over and above the ordinary block reward and priority fees. It comes from arbitrage between exchanges, liquidations, back-running, and sandwiching — all of which are ordering games. The key fact for this page is not how each game works but a property of the whole activity: extracting MEV well is hard, specialized labour.

To squeeze the maximum out of a slot you must:

• ingest every pending transaction and every private bundle in real time,
• simulate thousands of candidate orderings against live state,
• solve, in effect, an optimization problem over which bundles to include,
• and do all of it in the few hundred milliseconds before the slot is gone.

That is a latency-sensitive, capital-intensive, expertise-heavy craft. Now recall who proposes blocks under Proof-of-Stake. Since the Merge, the right to propose a slot’s block falls to a pseudo-randomly chosen validator — very often a hobbyist running a node at home. Bolt those two facts together and you get the centralizing pressure:

   IF every validator must build its own block to earn MEV...

   home validator (Raspberry Pi)        professional operator (datacenter)
   ────────────────────────────────     ──────────────────────────────────
   sees the public mempool only         sees private orderflow + all bundles
   no simulation infrastructure         simulates thousands of orderings/slot
   earns: base fees + a little MEV       earns: base fees + NEAR-MAXIMAL MEV

        → the professional out-earns the hobbyist every slot
        → higher yield attracts more stake to professionals
        → staking concentrates around the few who can also build well

This is the trap. MEV cannot be deleted — it is intrinsic to any orderable, publicly-visible sequence of transactions. So if you require every proposer to also be an elite builder to earn the going rate, you have quietly made “be a large, sophisticated operator” the price of competitive staking. The chain’s proposer set — the thing whose decentralization secures it — drifts toward a professional oligarchy. That is the exact opposite of why Ethereum lowered the staking bar to 32 ETH and told people they could run a validator at home.

The PBS idea: split the two jobs

Proposer–builder separation (PBS) breaks the trap by observing that proposing and building are different jobs that do not need the same operator.

   ONE ROLE (centralizing)              TWO ROLES (PBS)
   ─────────────────────────            ─────────────────────────────────────
   validator must ALSO build            BUILDER: assembles the most valuable
   the most profitable block            block body — the specialist ordering job

                                        PROPOSER: the randomly-chosen validator
                                        that just PICKS the best-paying block
                                        and signs it — stays simple, stays home

• Builders are specialist firms that compete to assemble the most valuable block body from searchers’ bundles and public transactions. This is the MEV-extraction craft, done by professionals.
• Proposers (validators) do not build. They receive complete, pre-built blocks from builders, pick the one that pays them the most, and simply sign and propose it. A proposer needs no simulation cluster and no private orderflow — just the ability to run an auction and choose the top bid.

The economic effect is the point. A home validator now captures MEV at nearly the same rate as a datacenter, because both are buying finished blocks from the same competitive builder market. Building can be as centralized as the market makes it, but proposing stays cheap, simple, and decentralized — and proposing is the role that actually matters for consensus safety, because it is the proposers who are the randomly-selected, slashable validator set.

The clean sentence: PBS separates who orders transactions (the builder) from who proposes the block (the validator), so that specialization in the first job doesn’t force centralization of the second.

MEV-Boost: PBS today, out of protocol

Here is the crucial nuance for a frontier page: the Ethereum protocol does not know about PBS. As of 2024 the consensus layer still expects each validator to produce its own block. PBS exists anyway — bolted on beside the protocol by a piece of optional middleware called MEV-Boost, released by Flashbots.

A validator runs MEV-Boost as an extra process next to its consensus client. When the validator is chosen to propose, MEV-Boost turns it into an auctioneer:

   searchers ──bundles──►  BUILDERS  ──full blocks──►  RELAY  ──header+bid──►  MEV-Boost
   (find MEV)              (assemble          (holds the block,        (proposer's
                           & bid)              runs the auction)        middleware)
                                                                            │
                                          proposer signs the winning        │
                                          HEADER (commits) ◄────────────────┘
                                                    │
                                          relay releases the FULL BODY ──► block published

Walk the seam carefully, because it is where the trust lives. There is a chicken-and-egg standoff:

• The proposer wants to see the full block before signing, to be sure it is valid and pays what was promised.
• The builder refuses to reveal the full block first — if it did, the proposer could copy the profitable ordering and propose it themselves, stealing the builder’s MEV.

The relay resolves this as a trusted intermediary. The builder sends the complete block to the relay. The relay shows the proposer only a block header plus a promised payment. The proposer signs that header — irrevocably committing to propose it — and only then does the relay release the full body. Because the proposer commits blind, it cannot steal the MEV; because the relay has already validated the block, the proposer is protected from signing something invalid. Neither party can cheat the other. But both must trust the relay — and that trust is exactly the thing enshrined PBS wants to delete.

By the numbers — why a home validator opts in

Why does a solo staker bother running extra middleware? Pure economics. Take one slot with round, illustrative figures:

   validator builds its own block:     0.04 ETH  (ordinary priority fees only)
   validator auctions the slot:        0.11 ETH  (a builder's winning bid, which
                                                   already bakes in the MEV it captured)

   difference per profitable slot ≈ 0.07 ETH — for running one extra process.

A staker who runs MEV-Boost captures a share of MEV they could never extract themselves; one who refuses leaves it on the table. Across a year of slots the gap is large enough that opting out is a real sacrifice — which is why a large majority of Ethereum validators run MEV-Boost, and precisely why builder and relay concentration became a systemic worry. (Figures vary enormously slot to slot; the durable point is the direction — outsourcing beats self-building.)

Under the hood — the relay is the trust seam

It is worth stating plainly what the relay can and cannot do, because “you must trust the relay” is the whole reason ePBS exists.

A relay can:

• Censor. Refuse to relay any block that contains a given address — for example, to comply with a sanctions list. Because a handful of relays carry most blocks, a censoring relay’s reach is large.
• Withhold or equivocate in principle, though relays stake their reputation on not doing so, and misbehaviour is publicly observable after the fact.

A relay cannot (in the honest model) steal the payment or forge a block — the cryptographic commitments and the proposer’s signature bound that. But “can’t steal your money” is a much weaker guarantee than “can’t censor your transaction,” and censorship is exactly the harm that matters for a chain whose entire value proposition is that it will process your transaction whether or not the powerful want it processed.

   what the relay holds:
     ┌───────────────────────────────────────────────────────────┐
     │  sees full block  ✓   →  can DECIDE to drop it (censor)    │
     │  holds it until commit ✓ → is a required chokepoint         │
     │  a few relays carry most blocks → concentrated power        │
     └───────────────────────────────────────────────────────────┘

The concern is not that a relay will rob you — the incentives and reputation guard against that. It is that a small number of trusted, off-protocol intermediaries now sit on the critical path of block production, and that is a censorship chokepoint the base protocol never signed up for.

Enshrined PBS (ePBS): baking the split into the protocol

If the relay is the problem, the obvious fix is to make the protocol itself do the relay’s job — so no trusted third party is needed. That is enshrined PBS (ePBS): teach the consensus layer, natively, how to let a builder commit to a block and a proposer commit to a builder, with the honest exchange enforced by the fork-choice rules and slashing instead of by a reputable middleman.

The goal, stated as a design target:

   MEV-Boost (out of protocol)          ePBS (in protocol)
   ─────────────────────────────        ─────────────────────────────────────
   relay guarantees fair exchange       PROTOCOL guarantees fair exchange
   trust a few off-chain relays         trust only the consensus rules
   censorship rides on the relay        censorship-resistance is a design goal
                                        (e.g. inclusion lists — see below)

The mechanism sketches roughly like this: the proposer signs a commitment to a particular builder’s bid without seeing the body; the builder is then obligated, by protocol rules, to reveal a valid block matching its bid, or be slashed. The trust that MEV-Boost placed in a relay’s honesty is replaced by a credibly-neutral rule enforced by the same staking and slashing machinery that already secures consensus.

A common companion proposal is the inclusion list: a mechanism letting the proposer force certain pending transactions to be included in whatever block the builder produces, so a builder cannot silently censor a user. Inclusion lists attack the censorship problem directly, whether or not the full ePBS design lands.

Now the honest hedge, which this Part insists on. ePBS is a proposal, and its design is unsettled as of 2024. There are multiple competing constructions (variants often discussed under names like PTC-style designs and slot-auction versus block-auction ePBS), open questions about timing games, builder collateral, and how inclusion lists interact with the auction, and no committed hard-fork date at the time of writing. Treat everything in this section as the shape of the goal, not a shipped feature. What is durable is the why: remove the trusted relay by moving its function into rules the whole network enforces. The how is live research.

It actually happened — the low-carb-crusader sandwich, April 2023

In early April 2023, an entity operating as an MEV-Boost validator (nicknamed “low-carb-crusader”) exploited a subtlety in the relay handshake to pull off a counter-attack against a set of sandwich bots, reported at the time as on the order of $20–25 million. The bots submitted their usual bundles through a relay; the malicious validator, having committed to a block, managed to reveal a different block that reordered the bots’ transactions against them — draining them instead of letting them sandwich their victims. The exploit turned on a flaw in how one relay released block contents relative to the proposer’s commitment. The lesson for this page is exact: the relay’s handshake is load-bearing, and it is out-of-protocol code. A bug there is not caught by consensus — it is a trusted intermediary whose correctness the base chain cannot vouch for. That is precisely the class of risk ePBS aims to remove by putting the commitment logic under the protocol’s own rules, where a violation is slashable rather than merely embarrassing. (Figures reported at the time; the mechanism — a relay handshake exploited — is the durable point.)

The trade-offs, held in view

PBS is a genuine improvement and a genuine bargain — not a free lunch. Line the whole arc up against the overview’s three-question test:

   WHAT IT BUYS                         WHAT IT COSTS
   ────────────────────────────────     ────────────────────────────────────
   proposers stay simple & cheap        block-BUILDING concentrates in a few
   (home validators earn near-max MEV)  professional builders

   staking stays decentralized          relays (today) are trusted chokepoints
   (the role that secures consensus)    that CAN censor transactions

   MEV auctioned in a clean market       user-level harm (sandwiching) is NOT
   instead of on-chain gas wars          solved — it is only made tidier

The bargain is subtle and worth stating precisely. PBS moves centralization rather than removing it: it protects the decentralization of the proposer set — the validators who are randomly selected and slashable — by accepting centralization in the builder set. That trade is deliberate, and it is defensible, because a concentrated builder market is far less dangerous than a concentrated validator set: builders don’t hold consensus power, and a proposer can always fall back to building its own (less profitable) block if the builder market misbehaves.

But two harms survive every version and must be named:

• Censorship resistance. Concentrating block-building in a few builders and (today) routing it through a few relays creates chokepoints. If most blocks flow through operators that exclude certain transactions, the chain’s credible neutrality — the property that makes it useful to untrusting strangers at all — is bargained away one slot at a time. Inclusion lists and ePBS are the countermeasures, and both are unfinished.
• User sandwiching. PBS reorganizes who builds; it does nothing to stop a builder from sandwiching a user’s public swap. The user’s defenses remain their own: tight slippage limits and private transaction submission (sending the swap straight to a builder so it never hits the public mempool).

That is the third overview question answered for this frontier: PBS keeps a normal user able to run a validator and still check the chain, which is a real win — but it does so by concentrating a different role, and whether that concentration stays benign depends on work that is still in progress.

The architect’s lens

MEV-Boost and proposer–builder separation are the major technology this page introduces, so we run the lens on them.

• Why does it exist? Because extracting MEV well is a specialist, latency-and-capital-intensive craft, but proposing a block under Proof-of-Stake falls to a randomly chosen, often-amateur validator. Without separation, only operators who could also build elite blocks would earn the going rate, pulling staking toward a professional oligarchy.
• What problem does it solve? It lets a home validator earn near-maximal MEV by auctioning its slot to professional builders instead of building by hand — decoupling the specialist ordering job from the proposing job, so building can centralize without dragging the consensus-critical proposer set down with it.
• What are the trade-offs? It moves centralization rather than deleting it: proposers stay decentralized, but block-building concentrates among a few builders, and today the exchange runs through a few trusted relays that can censor. It makes MEV extraction tidy but does nothing to stop users being sandwiched.
• When should I avoid it? As a solo staker, you might run without MEV-Boost — accepting lower rewards — if you value maximal decentralization, want to build censorship-resistant blocks yourself, or refuse to trust any relay. As a user, avoid the public mempool for sensitive swaps and submit privately.
• What breaks if I remove it? Take away PBS and every validator must build its own block to stay competitive — which centralizes staking around the few who can also be elite builders. You’d trade a concentrated builder market (relatively safe) for a concentrated validator set (dangerous to consensus itself). The chain would be less decentralized where it matters most.

Check your understanding

1. Define MEV precisely, and explain the specific property of extracting it — not just its existence — that creates centralizing pressure on block production under Proof-of-Stake.
2. State exactly what proposer–builder separation separates, and explain why splitting these two jobs lets building centralize without centralizing the part of the system that secures consensus.
3. MEV-Boost is described as delivering PBS “out of protocol.” Walk through the relay handshake and explain why the relay must be trusted — what could a proposer do without it, and what can a relay do that makes it a censorship chokepoint?
4. Contrast MEV-Boost with enshrined PBS (ePBS). What exactly does ePBS try to remove, what replaces the relay’s guarantee, and why must any claim about ePBS be hedged as of 2024?
5. The page says PBS “moves centralization rather than removing it.” Explain the trade being made, why it is defensible, and name the two harms that survive every version of PBS.

Show answers

1. MEV (Maximal Extractable Value) is the profit a block producer — or anyone who can influence ordering — can capture purely by choosing which transactions to include and in what order, beyond the ordinary block reward and priority fees. The centralizing pressure comes not from MEV’s existence but from the fact that extracting it well is specialist labour: you must ingest all orderflow, simulate thousands of orderings, and win in milliseconds. If every validator must do this to earn the going rate, then only large, sophisticated operators can compete, and staking drifts toward them — while proposing itself is assigned to randomly chosen, often-amateur validators.
2. PBS separates who orders transactions (the builder) from who proposes the block (the validator/proposer). Because the proposer now just buys a finished block from a competitive builder market and signs it, a home validator earns nearly the same MEV as a datacenter. Building can be as centralized as the market makes it, but proposing stays cheap and decentralized — and it is the proposer set (randomly selected, slashable) that secures consensus, so protecting its decentralization is what matters. Builders hold no consensus power.
3. In MEV-Boost the builder sends the full block to a relay; the relay shows the proposer only a header plus a promised payment; the proposer signs (commits to) that header, and only then does the relay release the full body. The relay must be trusted because of a standoff: if the builder revealed the block first, the proposer could copy the profitable ordering and propose it themselves, stealing the builder’s MEV — so the builder won’t reveal until the proposer commits, and the relay is what makes that safe for both. A relay is a chokepoint because it sees full blocks and can refuse to relay any block containing a given address (censor), and a few relays carry most blocks.
4. Enshrined PBS (ePBS) tries to remove the trusted relay by moving its function into the protocol itself. The relay’s honest-exchange guarantee is replaced by consensus/fork-choice rules plus slashing: a builder that fails to reveal a valid block matching its committed bid is slashed, and companion mechanisms like inclusion lists let proposers force certain transactions in to resist censorship. It must be hedged because ePBS is a proposal with an unsettled design as of 2024 — multiple competing constructions, open questions (timing games, collateral, inclusion-list interaction), and no committed hard-fork date. The goal is durable; the how is live research.
5. PBS moves centralization: it accepts a concentrated builder set in exchange for keeping the proposer/validator set decentralized. This is defensible because a concentrated builder market is far less dangerous than a concentrated validator set — builders hold no consensus power, and a proposer can always fall back to building its own (less profitable) block. The two surviving harms are censorship resistance (a few builders/relays as chokepoints that can exclude transactions, threatening credible neutrality) and user sandwiching (PBS reorganizes who builds but doesn’t protect a user’s public swap; defenses remain tight slippage and private submission).