Crypto Gloss

MEV Advanced

Basic MEV — frontrunning, sandwiching, and arbitrage — is well documented (see the introductory mev entry). What’s less understood is the sophisticated infrastructure layer that emerged to systematize MEV extraction: Proposer-Builder Separation (PBS), the MEV-Boost relay network, the SUAVE oracle/auction architecture, and ongoing protocol-level debates about whether MEV should be captured by validators, redistributed to users, or eliminated. As of 2025, MEV is no longer a dark forest phenomenon — it’s a structured multi-billion dollar market with professional participants, formal auction mechanisms, and significant implications for Ethereum’s censorship resistance and decentralization. Understanding advanced MEV requires understanding this infrastructure layer.

From Chaos to Cartel: The History of MEV Systematization

Here is how it developed over time.

Pre-Flashbots Era (2019–2020): The Dark Forest

Before any coordination infrastructure, MEV was purely adversarial:

  • Competing bots submitted the same arbitrage transactions with higher gas prices
  • “Priority gas auctions” — bots in a race to outbid each other — created extreme gas spikes
  • Failed MEV transactions wasted ~$500M+ in gas (bots losing races paid for failed txns)
  • Vulnerable users suffered sandwich attacks with no warning

The Dark Forest paper (2020, Samczsun and colleagues) documented this chaotic state: Ethereum’s mempool was a competitive jungle where the only winning strategy was predatory extraction.

Flashbots Era (2021–present): Coordination and Privatization

Flashbots dramatically changed this by creating structured MEV markets:

Flashbots Auction (pre-Merge): A private mempool where searchers submitted MEV bundles directly to miners off-chain, avoiding failed transaction gas waste. Miners received direct payment (ETH bribe) rather than gas price.

MEV-Boost (post-Merge): After Ethereum moved to Proof of Stake, Flashbots created MEV-Boost — middleware that separates the role of block building from block proposing, creating the PBS infrastructure.

Proposer-Builder Separation (PBS)

The following sections cover this in detail.

The Core Concept

PBS splits the validator’s role into two distinct actors:

Block Proposer: The randomly selected validator for a given slot. Proposes one block. In PBS, the proposer does NOT build the block — they simply select from bids made by builders.

Block Builder: Specialized entities (Titan Builder, Beaver Build, rsync-builder, etc.) that:

  1. Collect transactions from the public mempool
  2. Collect private order flow from wallets (Metamask, Banana Gun, etc.)
  3. Search for MEV opportunities within the available transaction set
  4. Arrange transactions to maximize block value
  5. Bid for the right to have their block included by the proposer

Relay: The trust intermediary between builders and proposers. The relay:

  1. Receives blocks from builders (with sealed content)
  2. Verifies blocks are valid and bids are real
  3. Reveals block contents to proposer only after commitment to include it

The proposer sees only the bid amount and block header — not the transactions. They commit to the highest bid, then the relay reveals the full block. This prevents the proposer from stealing the MEV after seeing it.

MEV-Boost: The Market Implementation

MEV-Boost is the middleware (running as sidecar to the consensus client) that connects proposers to builders via relays. As of 2024–2025:

  • ~90%+ of Ethereum blocks are built via MEV-Boost
  • Validators using MEV-Boost earn 20–200%+ more than those not using it
  • Major relays: Flashbots, Ultra Sound, Agnostic Gnosis, Manifold
  • Major builders: Titan Builder, Beaver Build, rsync-builder, I Can Has Block

Builder Market Concentration

Block building has become highly concentrated:

  • Top 3 builders produce ~70–80% of blocks
  • These builders have special “exclusive order flow” relationships with major wallets
  • Coinbase Wallet, MetaMask Swaps, Banana Gun → send transactions directly to specific builders rather than public mempool
  • Why? Builders promise better execution (less sandwich exposure) in exchange for priority view of order flow

This concentration creates censorship concerns: if the top builders decide not to include certain transactions (e.g., Tornado Cash interactions following OFAC sanctions), those transactions face significant delays.

SUAVE: The Next Generation

SUAVE (Single Unifying Auction for Value Expression) — Flashbots’ proposed long-term replacement for MEV-Boost.

Problem With PBS/MEV-Boost

  1. Centralization: Builder concentration is worse than pre-PBS searcher concentration
  2. Opaque order flow: Private mempool deals between wallets and builders disadvantage users who don’t route through preferred wallets
  3. Cross-chain MEV ignored: Same MEV opportunity exists across Ethereum, L2s, and other chains but current PBS only captures Ethereum-level MEV
  4. No user MEV protection: Users pay sandwich attacks through execution quality loss even with MEV-Boost protecting proposers

SUAVE’s Approach

SUAVE is a separate network specifically for expressing transaction preferences and building blocks:

  1. Confidential Computing: SUAVE uses trusted execution environments (Intel SGX) — searchers can verify MEV computation happens correctly without revealing strategies
  2. Unified Preference Layer: Users specify how their transactions should be filled (e.g., “best execution price” not “fastest inclusion”)
  3. Cross-Chain Block Building: SUAVE can coordinate MEV across Ethereum + L2s simultaneously — capturing arbitrage that exists between chains
  4. Programmable Block Building: Any entity can write “SUAPP” programs that define custom block building logic

Timeline: SUAVE remains in development/testnet as of 2025. Full mainnet deployment is a multi-year effort. Meanwhile, MEV-Boost continues as the status quo.

Inclusion Lists: Censorship Resistance

The following sections cover this in detail.

The Censorship Problem

After OFAC sanctioned Tornado Cash (August 2022), multiple MEV-Boost relays refused to include Tornado Cash transactions:

  • Flashbots relay: 100% compliant with OFAC → blocked Tornado Cash txns
  • Other relays: Partial compliance

At peak, ~70% of Ethereum blocks were being built by OFAC-compliant builders, meaning Tornado Cash transactions faced delays of many slots.

EIP-7547: Inclusion Lists

The proposed Ethereum protocol solution: Inclusion Lists

  • Proposer (validator) creates a list of transactions that MUST be included in any block they propose
  • Builder cannot exclude these transactions without the proposer refusing their block
  • The proposer has no idea of MEV value — they simply enforce inclusion of mempool transactions
  • This restores base-level censorship resistance: validators can force inclusion of any transaction, regardless of builder preference

Status: EIP-7547 inclusion lists are planned for a future Ethereum upgrade. Not yet deployed.

MEV Smoothing

The following sections cover this in detail.

The Problem

MEV is lumpy — some blocks have $100K+ in extractable MEV (NFT mint, major DeFi liquidation), others have near-zero. This creates a “lottery” component for validators: your expected MEV earnings depend heavily on which blocks you’re randomly assigned.

MEV Smoothing proposals aim to redistribute MEV evenly across all validators:

  1. All MEV from all blocks goes into a shared pool
  2. Each validator receives their proportional share of the total MEV across the epoch
  3. No individual validator wins a single large MEV block — all share proportionally

Arguments for: Reduces centralization pressure (small validators no longer disadvantaged by block assignment randomness); reduces incentive for block withholding attacks (holding a high-MEV block to replace it).

Arguments against: Reduces validator competition; harder to implement correctly; may distort priority fee markets.

MEV Tax

MEV Tax (proposed by Paradigm research) is an alternative to blocking MEV:

Rather than fighting MEV extraction, formalize it as a “transaction priority tax” paid to the protocol:

  • Applications embed a “priority fee” directly in transaction logic: “pay X to validator who includes this transaction next”
  • This fee goes INTO the protocol (burned or redistributed) rather than to specialized searchers
  • Applications that need fastest execution pay explicitly; normal users pay less

Paradigm’s argument: MEV cannot be fully eliminated; the question is whether it flows to searchers+builders+validators or back to the protocol/users. MEV Tax routes value to where it arguably belongs.

Live implementations: Uniswap V4 hooks can implement MEV tax logic; some Solana programs experiment with explicit priority fee integration.

MEV on L2s and Solana

The following sections cover this in detail.

L2 MEV: Sequencer Centralization

Rollup sequencers are the primary MEV agents on L2s:

  • Optimism/Base (Coinbase-run sequencer): MEV via transaction ordering within the sequencer
  • Arbitrum: Fair Ordering — transactions ordered by arrival time; reduces some MEV
  • Flashbots is working on L2 block building standards (MEV-Boost for L2)

Solana MEV

Solana’s architecture creates different MEV:

  • No global mempool: Transactions go directly to the current leader (validator)
  • Jito-Solana: Jito Labs built a fork of the Solana validator client that adds a private mempool layer similar to MEV-Boost
  • JitoTips: Searchers pay “tips” on top of priority fees for their bundles to be executed atomically
  • Jito earns ~$30–100M+ annually in MEV-related tip revenue
  • JTO token captures Jito’s economics

Related Terms

Sources

Daian, P., Goldfeder, S., Kell, T., Li, Y., Zhao, X., Bentov, I., Breidenbach, L., & Juels, A. (2020). Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. IEEE Symposium on Security and Privacy 2020.

Wahrstätter, A., Ernstberger, J., Reid, A., Zhou, L., Canidio, A., Malik, D., & Gatteschi, V. (2023). Blockchain Censorship. arXiv:2305.18545.

Flashbots Research. (2022). MEV-Boost: Merge Ready Flashbots Architecture. Flashbots Blog/GitHub.

Buterin, V. (2021). State of research: increasing censorship resistance of transactions under proposer/builder separation. Ethereum Research Forum.

Heimbach, L., Kiffer, L., Ferreira Torres, C., & Wattenhofer, R. (2023). Ethereum’s Proposer-Builder Separation: Promises and Realities. arXiv:2305.19037.