MEV (Maximal Extractable Value) & Its Mitigations: Flashbots, PBS, and MEV-Boost in Ethereum Post-Merge

Introduction: MEV Is an Incentive, Not a Bug

Maximal Extractable Value (MEV) formerly “miner extractable value” is the additional profit a block producer (or anyone who can influence the transaction ordering) can earn by reordering, inserting, or censoring transactions within a block. MEV isn’t new: on chain, arbitrage, liquidations, and back-running opportunities have existed since the earliest decentralized exchanges. What’s new is the industrialization of MEV post-Merge: instead of miners tightly coupling execution and block production, validators propose blocks, while specialized builders assemble them and bid for inclusion through relays. This supply chain of blockspace professionalizes MEV extraction while making it more transparent and in some cases more equitable.

But MEV has costs: toxic MEV like sandwich attacks hurts users; cross-domain MEV creates race conditions across rollups; centralization risk emerges if a few builders and relays dominate. This article maps the landscape, explains the mechanics of Flashbots and MEV-Boost, demystifies Proposer-Builder Separation (PBS) and its enshrined variant ePBS, and offers practical mitigation strategies for wallets, protocols, and L2s. We’ll also explore the road to SUAVE (a privacy-preserving, cross-chain orderflow network), OFAs (order-flow auctions), and how intents change who captures value.

MEV Basics: Where the Value Comes From

In AMMs and lending markets, prices and collateral ratios aren’t continuous, they update when transactions execute. If a DEX price diverges from an external market or another DEX, arbitrageurs can profit by trading against outdated quotes. If a borrower falls below a collateral threshold, liquidators can pay gas to close the position and take a fee. These profits are economic and would exist even in a perfectly fair system. MEV enters when ordering power determines who collects those profits.

• Back-running: A user submits a trade; arbitrageurs race to execute a follow-up trade in the same block to restore prices.
• Liquidation racing: Multiple liquidators compete to be first, driving gas wars.
• Sandwiching (toxic): An attacker places a buy before a user’s swap and a sell after, extracting value from induced slippage.
• Time-bandit attacks (L1 risk): Reorging past blocks to capture MEV (mitigated post-Merge but still a theoretical concern if incentives grow).
• Cross-domain MEV: Profits spanning L1/L2s or multiple rollups, requiring coordination and giving an advantage to entities with broader visibility and low latency.

The Post-Merge Block Supply Chain: Searchers → Builders → Relays → Proposers

The Merge replaced proof-of-work miners with proof-of-stake validators. It also enabled a clean separation of responsibilities. Today, the block pipeline often looks like this:

1. Searchers monitor the mempool and private orderflow, generating bundles of transactions that realize some MEV strategy (arbitrage, liquidation, back-run). They simulate and rank bundles by profit.
2. Builders aggregate transactions and searcher bundles into full candidate blocks, optimizing for maximal value (gas + MEV). Builders then bid to proposers with a bid value that promises the proposer (validator) a payment if they sign the block.
3. Relays act as trusted mail carriers between builders and proposers. They verify that a block is valid and that the bid is real, then deliver the sealed block header to the proposer. After the proposer signs, the relay reveals the block body.
4. Proposers (Validators) pick the best bid (usually highest) and sign the block. The protocol finalizes it in the normal way (Casper FFG/attestations).

This “market for blocks” reduces the need for every validator to be an expert MEV searcher, increasing total revenue while centralizing sophisticated logic in builders. The risk is relay trust (censorship, withholding, or failure), builder centralization, and opaque orderflow capture.

Flashbots & MEV-Boost: How the Current Stack Works

Flashbots began as a research/engineering initiative to make MEV transparent and reduce user harm. Pre-Merge, they offered a private relay for bundles to reach miners. Post-Merge, MEV-Boost is client-side middleware validators run to connect to a market of builders through relays. Validators choose the best bid per slot, increasing earnings compared to building blocks locally.

Key elements:

• Private Orderflow (Protect RPC / “no-mempool” endpoints): Wallets or apps can send transactions privately to builders/relays to avoid mempool exposure and some forms of MEV (e.g., sandwiches), though this shifts trust to the privacy provider and may affect liveness.
• Bundles: Searchers submit transaction bundles with simulation-based guarantees (e.g., “must include my liquidation if these conditions hold”). Builders integrate bundles into blocks if profitable.
• Relay Protections: Relays prevent builders from learning the proposer’s identity before signing, and prevent proposers from seeing the full block before commit (to avoid theft). Still, relays remain trusted middleware and potential choke points.

MEV-Boost professionalized MEV and increased validator income. But it also created a relay oligopoly risk and raised censorship concerns when some relays filtered transactions. These are core motivations for the protocol-level upgrade to enshrined PBS (ePBS).

From PBS to ePBS: Enshrining the Market for Blocks

Proposer-Builder Separation (PBS) is the idea that the role of building blocks and the role of proposing them should be cleanly separated, with strict rules preventing either side from stealing value or censoring unfairly. Today’s MEV-Boost is an out-of-protocol implementation. ePBS would move parts of this logic into the Ethereum protocol itself, reducing reliance on trusted relays and giving validators credibly neutral access to builder bids.

Features and goals commonly discussed for ePBS:

• In-protocol commitments: Builders commit to block headers and payments in a way that doesn’t require trusted relays to enforce.
• CrLists (censorship-resistance lists): Mechanisms for proposers to ensure certain transactions cannot be indefinitely censored by builders.
• Inclusion lists: Proposers can attach a small list of transactions that must be included, ensuring base censorship resistance even with external builders.
• Payment enforcement: Economic guarantees (escrows, proofs) so proposers are paid the bid amount without trusting relays.

ePBS won’t eliminate MEV, no system can, as long as ordering creates economic opportunities. But it can push the market toward openness, reduce censorship vectors, and make value flows more accountable.

Privacy, Order-Flow Auctions (OFAs), and Intents: Who Captures the Spread?

Most user harm arises when public mempool visibility lets attackers frontrun or sandwich trades. Mitigations fall into three overlapping categories:

1. Privacy/Sealed Orderflow: Send transactions directly to a trusted endpoint (e.g., RPCs that route to builders) or use cryptographic sealing so contents aren’t visible until after inclusion. This addresses sandwiching but raises trust and liveness concerns.
2. Order-Flow Auctions (OFAs): Rather than giving orderflow away for free, wallets or dApps can auction the right to execute it among builders/searchers, rebating some MEV back to users or protocols. OFAs transform opaque capture into a transparent marketplace.
3. Intents: Users express what they want (e.g., “swap up to X slippage for best net price,” “bridge + swap by deadline”) without specifying how. Solvers compete to satisfy the intent, shifting value capture from opportunistic ordering to competitive execution.

Ecosystems like Flashbots propose SUAVE, an off-chain, privacy-preserving mempool/auction layer aiming for credible neutrality across chains and rollups. The goal: keep orderflow private until after an auction decides the best execution, then release the winning bundle to the appropriate chain with cryptographic attestations.

MEV on L2s: Sequencers, Shared Sequencers, and Cross-Rollup Arbitrage

Rollups inherit Ethereum security for data availability but currently centralize sequencing (ordering) to the team or a small validator set. That means L2 MEV often accrues to the sequencer. Some projects share a portion of this revenue with the protocol or users; others use private mempools to reduce sandwiching. As ecosystems mature, several trends appear:

• Shared Sequencers: Neutral networks that order transactions for many rollups, enabling cross-rollup atomicity and fair ordering rules. They can implement MEV smoothing and distribute value across participating chains.
• Proof-based Bridges: As ZK bridges improve, cross-rollup MEV will be settled by cryptographic proofs instead of trusted committees, reducing attack surfaces but changing latency and opportunity windows.
• Dual Posting of Data: Some rollups may post to both Ethereum blobs and a specialized DA layer, impacting how quickly MEV opportunities can be observed and arbitraged.

For developers, L2 MEV feels like L1 circa 2020: rapid iteration, diverse policies, and a race to credible neutrality. Expect design space around inclusion lists on L2, private orderflow defaults, and solver-based intents integrated into rollup SDKs.

Mitigation Designs: Reducing Harm, Sharing Value

A robust MEV policy balances user protection, decentralization, and efficiency. Concrete designs include:

1. Inclusion Lists / CRLists: Give proposers the power to require inclusion of certain transactions (e.g., older txs approaching a deadline), improving base censorship resistance even with external builders. CRLists let proposers signal policies that discourage e.g., OFAC-style filtering.
2. MEV Smoothing / Revenue Sharing: Protocols can route OFA proceeds to users (gas rebates, better prices), to public goods, or to stakers to keep incentives aligned. Transparent accounting matters.
3. Quoting & RFQ Systems: DEXs integrate off-chain quoting (RFQ) with on-chain settlement, producing fixed-price fills that are harder to sandwich. Quotes can be signed and shielded until execution.
4. Batch Auctions: Periodically clear trades at a single price to remove ordering advantage within the batch. This sacrifices some UX latency for fairness.
5. Encrypted Mempools / Delayed Reveal: Encrypt tx contents on submission, reveal after ordering. Requires robust crypto and DoS protections.
6. Intents & Solver Competitions: Formalize user goals; let solvers compete and pay for orderflow, returning a portion of value to the originator.
7. Protocol-Level Guardrails: AMMs can use dynamic fees and anti-sandwich mechanisms (e.g., checking pre/post states, limiting slippage, or blocking toxic patterns).

Builder/Relay Strategies: Performance, Neutrality, and Resilience

For builders and relays, the mandate is reliability and credible neutrality:

• Latency Optimization: Co-locate with major nodes, maintain fast mempool connectivity, and prefetch private orderflow.
• Simulation Accuracy: Deterministic simulations reduce revert risk and improve bid quality; mispriced bids get out-competed.
• Neutrality & Policy: Resist arbitrary censorship; publish transparent policies; support inclusion lists.
• Diversity: Encourage a competitive builder set; avoid vertical integration that captures all orderflow end-to-end.
• Resilience: Fallback paths for relay outages; honest-but-curious mitigation; signed receipts for auditability.

The health of the ecosystem depends on multiple performant builders and relays. Concentration invites regulatory and technical risk.

Wallet & DApp Playbook: Practical Steps to Reduce User Harm

1. Default to Private Routing: Offer “protected” routes that avoid public mempools for swaps and high-value actions, with clear disclosure of trade-offs (possible failures, slightly higher latency).
2. Integrate OFAs: Let users opt into auctions for their orderflow with visible rebates. Align incentives by sharing execution value.
3. Intent-Based UX: Replace “send tx with fixed path” with “achieve best execution under constraints,” letting solvers compete.
4. Slippage & Deadline Hygiene: Suggest conservative defaults; detect outlier parameters and warn users; auto-adjust based on gas conditions.
5. Anti-Sandwich Guards: Use on-chain checks (e.g., price bounds) and off-chain monitoring (mempool watchers) to block harmful patterns.
6. Post-Trade Analytics: Show users how much value was protected or rebated, improving trust and product differentiation.
7. Diversify Routes: Support multiple relays/builders/providers to avoid single points of failure and policy capture.

Policy & Compliance: Censorship, Sanctions, and Neutral Infrastructure

MEV infrastructure intermediates economic activity. As relay operators took policy positions in the past (e.g., filtering based on sanctions lists), the community confronted a core question: should critical infrastructure be policy-neutral by design? ePBS, inclusion lists, and protocol-level guardrails push toward neutrality by making censorship harder and more costly. At the same time, teams must comply with applicable laws in their jurisdictions.

Practical guidance:

• Publish clear policies on inclusion and ranking; minimize subjective filtering.
• Support user choice: allow validators/wallets to select providers with matching risk preferences.
• Prefer proof-based mechanisms over policy-enforced outcomes; keep infrastructure verifiable rather than discretionary.

The Road Ahead: ePBS, SUAVE, Cross-Domain MEV, and Modular Orderflow

The next few years will see three overlapping transformations:

1. Enshrined PBS (ePBS): Bring the builder market into the protocol to remove trusted relays, add inclusion lists, and harden payment guarantees. Expect iterations: the first ePBS may be minimal, with future upgrades adding privacy and better censorship resistance.
2. SUAVE-like Networks: Off-chain, privacy-preserving coordination layers that auction orderflow across chains and rollups, releasing winning bundles with attestations. SUAVE can reduce toxic MEV and help move value back to users via OFA rebates.
3. Cross-Domain MEV Tooling: As rollups proliferate, MEV becomes multi-chain by default. Shared sequencers, intent routers, and proof-based bridges will let users express goals while solvers coordinate execution atomically across domains.

The endgame is credible neutrality + user-aligned value capture: a world where users don’t fear mempools, protocols share neutral infrastructure, and MEV revenues fund both public goods and system security, without predation.

FAQ

Does MEV-Boost centralize Ethereum?

It centralizes some logic (block building) among specialized entities, but increases validator revenue and transparency compared to ad-hoc private deals. The long-term antidote is ePBS with open markets and strong censorship resistance, plus a healthy diversity of builders and relays in the interim.

Can we eliminate MEV entirely?

No. As long as state updates are discrete and ordering changes payoffs, opportunities exist. The goal is to minimize toxic MEV, internalize neutral MEV efficiently, and share value with users and network participants fairly.

Is private orderflow always better for users?

It prevents some attacks, but introduces trust and availability trade-offs. If the private endpoint censors or fails, users may experience delays or worse prices. OFAs and intents aim to combine privacy with competition so users capture more of the value safely.

How do L2s share MEV fairly?

Options include MEV smoothing (distribute sequencer profits), shared sequencing with neutral policies, and intent routers that steer orderflow through auctions. Protocols should publish transparent policies and avoid irreversible vendor lock-in for sequencing and DA.

What’s the difference between PBS and ePBS?

PBS is the conceptual separation of proposer and builder roles. Today’s MEV-Boost is an out-of-protocol PBS. ePBS puts essential parts in protocol, removing trusted relays and improving censorship resistance and payment guarantees.

Glossary

• MEV: Extra value from transaction ordering within a block.
• Proposer: The validator selected to sign the block for a slot.
• Builder: An entity that assembles transactions/bundles into candidate blocks and bids to proposers.
• Relay: Middleware that mediates between builders and proposers, preventing theft and validating bids (pre-ePBS).
• PBS / ePBS: Proposer-Builder Separation; enshrined PBS moves key logic into protocol.
• OFA: Order-Flow Auction; a mechanism to sell orderflow rights and rebate value to originators.
• Intent: A user’s goal specification (“what”), leaving “how” to competing solvers.
• Shared Sequencer: Neutral ordering service for many rollups, enabling cross-rollup atomicity and fairness policies.
• Inclusion List / CRList: Proposer-supplied lists that must be included to prevent censorship.
• SUAVE: A proposed privacy-preserving, credibly neutral, cross-chain orderflow and auction network.

Key Takeaways

• MEV is structural: You can’t delete it, but you can redistribute it and reduce harm.
• MEV-Boost works now: It boosts validator revenue and professionalizes block building while motivating protocol-level fixes.
• ePBS is crucial: Enshrined PBS reduces reliance on trusted relays and strengthens censorship resistance and payment guarantees.
• Privacy + Auctions + Intents: Combine to block toxic MEV and give users a cut of the execution value.
• L2s must decide a MEV policy: Shared sequencers, MEV smoothing, and proof-based bridging shape where value accrues.
• Future is cross-domain: SUAVE-like networks, intent routers, and standardized proofs will coordinate value across chains.