By now you’ve seen MEV from the predator’s side: the mempool is a glass house, ordering is worth money, and a searcher with the right bundle can sandwich your swap before you blink. The natural question is the one this whole topic has been building toward — can we stop it? The honest answer is no, not entirely — ordering value is baked into the very idea of a shared, sequential ledger. So the real game isn’t elimination. It’s three quieter verbs: minimise the toxic, victimising part; democratise who gets to extract the rest; and redistribute the proceeds back toward the users who generated them. This lesson is the toolbox for all three.
Before you read — take a guess
Before we dig in — what's the single most realistic goal of Ethereum's MEV countermeasures?
The problem PBS solves: don’t make every validator a quant
Analogy. Imagine a restaurant where the owner — whose only real job is to unlock the doors and keep the lights on — is also forced to be a world-class chef, or the restaurant fails. Most owners can’t cook at that level, so either the food is terrible or only a handful of chef-owners survive and everyone else is squeezed out. The fix is obvious: separate the chef from the owner. Let specialist chefs (who live and breathe technique) compete to cook, and let owners simply pick the best dish on offer and serve it.
Definition. On Ethereum, validators are chosen to propose the next block — but extracting MEV well requires sophisticated, latency-sensitive software: scanning the mempool, simulating thousands of orderings, integrating searcher bundles, and computing the single most valuable block. If every validator had to do that to stay competitive, block production would centralise around the few firms that could afford the engineering — exactly the outcome a decentralised chain wants to avoid. Proposer-Builder Separation (PBS) splits the job in two: builders specialise in ordering (assembling the most valuable block), and proposers (validators) keep the right to propose but do almost no work — they just pick the highest-paying block offered to them.
So the validator running a humble home node and a billion-dollar trading desk end up earning the same MEV-inflated reward for the slot, because both simply accept the best bid. The skill gap moves to the builders, where competition is fine; the proposer role stays cheap, so it stays decentralised.
PBS isn't 'no MEV' — it's MEV with the centralising pressure removed
A common misread: “PBS solves MEV.” It does not reduce how much MEV exists, and it doesn’t stop sandwiching by itself. What it solves is a narrower, sneakier problem — that competing for MEV would otherwise centralise validation. PBS keeps the proposer’s job trivial so anyone can validate, while letting builders fight over ordering. Extraction continues; it just no longer threatens to collapse the validator set into an oligopoly.
When it matters
PBS matters most for credible decentralisation under proof-of-stake. The whole pitch of staking is that many independent validators secure the chain. If MEV made solo staking uneconomical versus industrial builders, that pitch dies. PBS is the structural patch that lets a hobbyist validator earn competitive rewards without ever writing a block-building algorithm.
The MEV supply chain, end to end
Analogy. Think of a sealed-bid art auction run through a trusted auction house. Artists (searchers) submit framed pieces; a curator (builder) assembles the best gallery wall; the auction house (relay) holds every gallery in a vault and shows the buyer only a photo of the wall plus its price tag — never the actual paintings — so no one can copy the arrangement. The buyer (proposer) points at the highest price tag, pays, and only then receives the real paintings to hang.
Definition. The modern Ethereum MEV pipeline has five roles, and value flows forward as data and backward as payment:
| Role | What it does | What it sees |
|---|---|---|
| User / Wallet | Signs a transaction (a swap, a transfer) and broadcasts it, wanting inclusion but with no say over its position | Only its own transaction |
| Searcher | Scans pending transactions for MEV (arbitrage, liquidations), then packages a profitable, precisely-ordered bundle | The public mempool + its own strategy |
| Builder | Assembles many bundles and transactions into a full, ordered block and computes the max it can pay to have it proposed | Everything it received; the full block contents |
| Relay | Runs a sealed-bid auction: escrows builders’ blocks and exposes only the header + bid so no one can steal the ordering | Full blocks (in escrow); reveals only headers |
| Proposer / Validator | Picks the highest-paying header, signs it, and pockets the bid — committing to a block it never saw inside | Only headers + bids, until after it signs |
The clever bit is how the proposer earns MEV without seeing the block contents. It signs a header — a cryptographic commitment to “whatever block hashes to this” — and the bid amount. The relay only releases the full block body once the signed header is in hand. So the proposer can’t peek at the juicy transactions, copy the builder’s ordering, and steal the profit; and the builder can’t get its block proposed without paying the promised bid. The relay sits in the middle holding both halves hostage until the trade is fair.
Step through the pipeline below. Watch the forward flow — transaction → bundle → block → signed header — and the value arrow running backward from builder to proposer: that’s the whole economic point made visible.
1. User / Wallet
Signs a transaction and broadcasts it — wanting it included, but with no say over where it lands in the block.
2. Searcher
Scans pending transactions for MEV (arbitrage, liquidations), then packages a profitable, precisely ordered bundle.
3. Builder
Assembles many bundles and transactions into a full, ordered block and computes how much it can pay to have it proposed.
4. Relay
Runs a sealed-bid auction: it holds builders’ blocks, escrows them, and exposes only the header + bid so no one can steal the order.
5. Proposer / Validator
Picks the highest-paying header and signs it — committing to a block it never saw the contents of, and pocketing the bid.
Step 1 of 5: User / Wallet. Signs a transaction and broadcasts it — wanting it included, but with no say over where it lands in the block.
Value flows forward as data (transaction → bundle → block → signed header) while the payment flows backward (builder's winning bid → the proposer's MEV reward). The relay's sealed-bid escrow is what lets the proposer collect the MEV without ever seeing — or being able to steal — the ordering inside the block.
In the MEV-Boost pipeline, how does a proposer earn the MEV reward without being able to steal the builder's ordering?
MEV-Boost: PBS as bolt-on software (and the relay trust problem)
Analogy. Ethereum’s base protocol doesn’t natively run the sealed-bid auction described above — at least not yet. MEV-Boost is like a popular third-party plugin that nearly every validator installs to get the feature the core software hasn’t shipped. It works beautifully, almost everyone uses it, and that ubiquity is precisely what makes its weak points scary.
Definition. MEV-Boost is out-of-protocol middleware (originally built by Flashbots) that implements PBS on Ethereum today. A validator runs it alongside its consensus client; MEV-Boost connects to one or more relays, collects builder bids, and hands the validator the highest-paying header to sign. The large majority of Ethereum blocks are now built this way — PBS in practice, even though it isn’t yet in the protocol itself.
The catch is the relay, which is a trusted party doing two delicate jobs: it must (1) faithfully escrow the block and reveal it only after the header is signed, and (2) not censor, steal, or leak the contents. That trust is a real bottleneck:
- A malicious or buggy relay could fail to release a block after the proposer signs, costing the proposer its slot reward.
- Relays can censor transactions (e.g. excluding sanctioned addresses), and because so few relays carry most blocks, a handful of operators can shape what gets included chain-wide — a centralisation and neutrality risk.
Relays are the soft underbelly — a small, trusted set carrying most blocks
Don’t picture MEV-Boost as trustless just because the rest of Ethereum is. The relay is an off-chain, trusted intermediary, and there are only a few major ones. If most blocks flow through two or three relays, those operators become a quiet choke point for censorship and a single point of failure. The fix isn’t a better relay — it’s removing the need to trust one at all, which is the whole motivation for enshrined PBS (ePBS): baking the proposer-builder auction directly into the Ethereum protocol so the escrow is enforced by consensus, not by a company’s good behaviour. ePBS is an active research and roadmap item, not yet shipped.
Which statement about relays in MEV-Boost is TRUE?
User-side mitigations: get out of the glass house
Analogy. The public mempool is a glass house — broadcast your move and every searcher watches you telegraph it. The simplest defence is to stop announcing your trade to the whole world before it’s mined. Instead of shouting your order across a crowded floor, you whisper it to a trusted broker who places it without tipping off the front-runners.
Definition. Private orderflow (via a private RPC or protection RPC, e.g. an MEV-protect endpoint) sends your transaction directly to builders over a private channel instead of the public mempool. If a sandwich attacker can’t see your pending swap, they can’t wrap it. Complementary user-side tools:
- MEV-aware routers split a large swap across pools and paths to flatten the price impact a sandwicher would feed on, and may route through protected channels by default.
- Tighter slippage tolerance caps how far your fill price can move — a sandwich that would push you past the cap simply reverts, so the attack can’t profit from you (at the cost of more failed transactions in volatile markets).
- Splitting orders into smaller clips reduces the per-trade MEV worth attacking.
- RFQ / just-in-time (JIT) liquidity: instead of hitting a public pool, you request quotes from market makers who fill you off the curve at a firm price, sidestepping on-chain sandwiching entirely.
Concrete example. You want to swap a large amount of ETH for USDC. Sent to the public mempool with loose slippage, a searcher front-runs to push the price up, lets you buy high, then back-runs to sell — the classic sandwich, and you eat the spread. Send the same swap through a private RPC with tight slippage, and the attacker never sees it in time to wrap it; worst case your tight slippage bound makes any attempted manipulation revert. Same trade, no sandwich.
Privacy has a price: orderflow concentration is its own centralisation risk
Private orderflow protects you, but if everyone’s transactions flow through a few private channels, those channels gain enormous power: they choose which builders see your trade, can extract value themselves, and starve the public mempool that keeps building permissionless and competitive. Exclusive orderflow can let dominant builders entrench (only they get the good flow), recreating centralisation through the back door. The user-level win (no sandwich) can trade off against a system-level loss (a less neutral, more captured market). Privacy vs. censorship/centralisation is the core tension here — neither side is free.
Fill in the logic of user-side protection and its tradeoff.
Pick the right option for each blank, then check.
Sending a swap through a RPC keeps it out of the public mempool, so a sandwich attacker can't it in time to wrap it. A slippage tolerance makes any manipulated fill . But if most flow concentrates in a few private channels, those channels gain power that can block building.
Protocol- and ordering-level mitigations: change the rules of the auction
User tools help individuals; the deeper fixes change how ordering itself works so the toxic MEV has nowhere to live. Four families, each with real tradeoffs.
Fair ordering / first-come-first-served (FCFS). Instead of letting whoever pays the most jump the queue, sequence transactions by arrival time as agreed by a committee of nodes. Front-running becomes harder because you can’t simply outbid your way ahead of a victim. Tradeoff: “arrival time” is fuzzy and gameable across a global network (latency races, spamming), and it doesn’t kill arbitrage MEV.
Batch auctions with uniform clearing price. Collect all trades over a short window into one batch, then settle them at a single clearing price that everyone in the batch receives (the CoW Swap–style design). If everyone trading the same pair in the same batch gets the identical price, there’s no “in-front” and “behind” to exploit — sandwiching dies, because the attacker can’t get a better price than its victim. Coincidences of wants can even match traders directly, skipping the AMM. Tradeoff: you wait for the batch, and you rely on solvers competing honestly to find the best settlement.
Threshold-encrypted mempools. Transactions enter the mempool encrypted; their contents are revealed only after the ordering for the block is fixed (decryption needs a threshold of validators to cooperate). You can’t front-run what you can’t read, and you can’t reorder based on contents you commit to before seeing. Tradeoff: added latency and complexity, liveness risk if the decryption committee misbehaves, and it doesn’t stop MEV that’s visible from on-chain state alone (e.g. a liquidation anyone can compute).
MEV redistribution. Accept that MEV will be extracted, but route the proceeds back to the users who created it. MEV-Share (an order-flow auction, OFA) lets a user expose just enough of their transaction for searchers to bid on the MEV it enables, then refunds the user a share of the winning bid — you get paid for the value your trade generates instead of being silently sandwiched. SUAVE (Single Unifying Auction for Value Expression) is a more ambitious vision: a dedicated, decentralised platform for orderflow, building, and bidding that aims to make this competition open and credibly neutral rather than captured by a few firms.
None of these fully solves MEV — they move it and trade it off
There is no silver bullet, and any source that says “this ends MEV” is overselling. Batch auctions kill sandwiching but not arbitrage; encrypted mempools hide intent but add latency and can’t stop state-visible MEV like liquidations; FCFS fights priority front-running but invents latency games; redistribution doesn’t reduce extraction at all — it just shares the spoils. Every mitigation buys a property (no sandwich / hidden intent / shared proceeds) by paying with another (latency / complexity / new trust assumptions). Expertise here is knowing which MEV each tool addresses and what it costs.
Sort each mitigation by where it lives: something a user/wallet chooses, or something baked into the protocol/ordering mechanism.
Place each item in the right group.
- Batch auction with a uniform clearing price
- MEV-Share order-flow auction with user refunds
- Tighter slippage tolerance on a swap
- Private / protection RPC (skip the public mempool)
- RFQ / just-in-time liquidity quote from a market maker
- MEV-aware router that splits the order across paths
- Threshold-encrypted mempool
- First-come-first-served fair ordering
A protocol moves to batch auctions with a single uniform clearing price for everyone trading the same pair in a window. What's the most direct effect on MEV?
The big picture: minimise, democratise, redistribute
Analogy. MEV is like friction in a machine: you can lubricate it, route it through bearings, and capture the heat to do useful work — but you can’t make it zero, because it’s a property of moving parts touching each other. Ordering value is the friction of a shared sequential ledger.
So the expert mental model isn’t “kill MEV.” It’s a layered defence matched to the three verbs:
- Minimise the toxic part. Sandwiching and front-running victimise users for no productive reason — squeeze these with private orderflow, tight slippage, batch auctions, and encryption.
- Democratise access. Don’t let a cartel of pros monopolise extraction or validation — PBS keeps proposing cheap, SUAVE-style open auctions keep the searcher/builder game competitive, and ePBS aims to remove the trusted relay entirely.
- Redistribute the proceeds. The MEV that will be extracted (arbitrage, liquidations — the load-bearing kind that keeps prices aligned and lending solvent) should pay the users who generated it, via order-flow auctions like MEV-Share.
Every tool in this lesson slots into one of those three. Hold them together and “I made a swap” stops being a quiet mugging and becomes a transparent, contested, increasingly fair pipeline — one you can now reason about, price, and defend.
Big picture
Taming MEV — the whole mitigation toolbox
- Taming MEV
- PBS (why)
- Splits ORDER (builder) from PROPOSE (validator)
- Keeps proposing cheap → validation stays decentralised
- Chef vs restaurant owner, sealed-bid
- Supply chain
- User → Searcher → Builder → Relay → Proposer
- Forward: tx → bundle → block → header
- Backward: bid → MEV payment
- Proposer signs the header, never sees contents
- MEV-Boost & relays
- Out-of-protocol PBS (Flashbots)
- Relay = trusted escrow → censorship / centralisation risk
- ePBS: enshrine the auction, drop the trusted relay
- User-side
- Private / protection RPC (skip public mempool)
- MEV-aware routers, tight slippage, split orders
- RFQ / JIT quotes off the curve
- Tradeoff: orderflow concentration centralises
- Ordering-side
- FCFS / fair ordering
- Batch auction + uniform price → no sandwich
- Threshold-encrypted mempool → hide intent
- MEV-Share / SUAVE → redistribute proceeds
- Big picture
- MEV can’t be eliminated
- Minimise toxic · Democratise access · Redistribute
- PBS (why)
Recap: PBS, MEV-Boost & mitigations
What centralising problem does Proposer-Builder Separation specifically prevent?
Check your answer to continue.
That’s the full machine — from the glass-house mempool all the way to the auction that prices its own friction. You can now name every role in the MEV supply chain, explain why PBS keeps validation decentralised, spot the relay as the trust bottleneck, choose the right user-side defence, and reason honestly about what each ordering-level fix buys and costs. One thing remains: prove it. The final exam is a single graded run across the whole topic — one question at a time, each answer locked the moment you submit, score revealed only at the end. No notes, no second chances. Go earn it.