The MEV Stack Demystified: Mempool, Builders, Relays, and Why Flashbots Changed Everything

The first time I truly understood MEV was not while reading a research paper - it was while watching a transaction I submitted to Ethereum mainnet get sandwich-attacked in real time. I was testing a swap on Uniswap V2 from a hot wallet during the Upside deployment cycle. The transaction landed with a worse execution price than the simulation showed, and when I pulled the block on Etherscan, I saw it: a bot had inserted a buy right before mine and a sell right after. Classic sandwich. They extracted roughly $140 from a$12,000 swap. Not catastrophic, but instructive.

Understanding MEV changed how I think about exchange infrastructure in general. There is always someone faster, always a value extraction game running in parallel to the visible one. If you build exchange connectivity or settlement infrastructure without understanding MEV, you are building blind.

What MEV Actually Is

MEV stands for Maximal Extractable Value - previously called Miner Extractable Value before the Merge. It refers to the profit that can be extracted by whoever controls transaction ordering within a block. On Ethereum post-Merge, that is validators (formerly miners). On Solana, it is also validators. On any chain with a sequential execution model, it exists.

The key insight is that a blockchain block is not a first-come-first-served queue. The entity building the block decides which transactions go in, in what order, and which get excluded entirely. That ordering power has real dollar value.

The three primary MEV strategies:

Arbitrage - price discrepancy between two DEXs. If ETH/USDC trades at $3,400 on Uniswap and$3,405 on Curve, a bot can buy on Uniswap and sell on Curve in the same block, capturing the spread atomically.

Sandwich attacks - detect a large pending swap in the mempool, front-run it with a buy to move the price, let the victim’s transaction execute at the worse price, then back-run with a sell to capture the delta.

Liquidations - DeFi lending protocols (Aave, Compound) allow anyone to liquidate undercollateralized positions for a bonus. When the price of an asset drops and a position becomes eligible for liquidation, multiple bots race to claim the liquidation bonus.

In aggregate, MEV extraction on Ethereum has exceeded $1 billion annually for several years running. This is not a rounding error. It is a structural feature of any sequenced execution environment.

The Dark Forest: Pre-Flashbots

Before Flashbots, the MEV game was brutal and public. Every pending transaction was visible in the Ethereum mempool. MEV bots monitored this mempool continuously, simulating every pending transaction to identify profitable opportunities.

When a bot spotted a profitable pending transaction - say, a large DEX swap - it would broadcast a competing transaction with a higher gas price to ensure it landed first. This triggered gas price wars. Two bots competing for the same MEV would keep outbidding each other in real time, sometimes spending more on gas than the MEV was worth. The failed transactions still cost gas. Validators earned enormous fees from these wars regardless of which bot won.

This had several negative effects:

1. Network congestion - failed transactions consumed block space, raising gas prices for everyone.
2. Opaque value flows - MEV extraction happened invisibly; ordinary users had no idea why their transactions were failing or getting sandwiched.
3. Centralization pressure - large MEV operations had private channels with miners to get their bundles included, creating an informal two-tier system.

The public mempool was, to use the phrase that circulated at the time, a dark forest. Any large transaction you submitted could be seen and exploited before it landed.

How Flashbots Changed Everything

Flashbots launched MEV-Geth in early 2021, and it reframed the entire problem. The core insight was simple: instead of competing in the public mempool, let MEV searchers submit bundles directly to block builders through a private off-chain auction.

A bundle is a sequence of transactions that must be included atomically and in order within a single block. The searcher simulates their bundle locally, determines the profit, and attaches a bid (in ETH) payable to the block builder/validator. The bundle is submitted via a private API - it never touches the public mempool.

This changed the game in three important ways:

Private submission eliminated gas wars - failed bids cost nothing. Searchers could bid aggressively without paying gas on losing transactions.

Bundle atomicity removed partial execution risk - if the entire bundle cannot land as specified, none of it lands. This is critical for arbitrage: you do not want your buy leg to execute without your sell leg.

Transparent value distribution - validator revenue from MEV became auditable. Flashbots published dashboards. The industry started talking openly about MEV instead of treating it as a dirty secret.

Proposer-Builder Separation (PBS)

The Merge in September 2022 introduced a structural change that formalized what Flashbots had done informally. Ethereum’s consensus layer now separates the role of block proposer (the validator selected by the consensus mechanism to produce a block) from block builder (the entity that actually assembles the transaction set).

This is Proposer-Builder Separation (PBS), and it created the modern MEV supply chain.

Without PBS, validators had to run their own block-building software, which meant either doing MEV extraction themselves or leaving that value on the table. PBS lets validators outsource block construction entirely - they just pick the most profitable block offered to them by external builders and sign it.

MEV SUPPLY CHAIN (Post-Merge Ethereum)

Searchers
│
│  Submit signed bundles + tip bids
│  (via builder API or Flashbots RPC)
▼
Builders
│  (e.g., Flashbots builder, Titan, rsync-builder, beaverbuild)
│
│  Assemble blocks from bundles + mempool txs
│  Simulate, order, optimize for maximum value
│  Submit block headers + bid to relays
▼
Relays
│  (e.g., Flashbots relay, Bloxroute relay, Ultra Sound relay)
│
│  Verify block validity + highest bid
│  Serve block header to validators (signed blind)
│  Only reveal full block after validator commits
▼
Proposers (Validators)
│  Selected by consensus layer for this slot
│  MEV-Boost queries registered relays for best bid
│  Signs the block header, commits to relay
│  Relay releases full block → propagated to network
▼
Block finalized on Ethereum

Each layer has a clear function. Searchers find opportunities. Builders assemble profitable blocks. Relays provide a trust-minimized handoff layer. Proposers earn the highest possible reward for their slot.

The Builder API and MEV-Boost

MEV-Boost is the software validators run to participate in this system. It is a middleware that sits between the validator’s consensus client and the execution client. When a validator’s slot arrives, MEV-Boost queries all registered relays, receives block headers with attached bids, selects the highest bid, and commits to that block.

The builder API is the protocol that builders use to submit blocks to relays. It is standardized - all major relays support the same builder API specification. This means a searcher who submits bundles to the Flashbots builder can have their transactions included in blocks that end up on the Flashbots relay, the Bloxroute relay, or the Ultra Sound relay, depending on which validator wins the slot.

In 2025, MEV-Boost participation among Ethereum validators has exceeded 90%. A validator running without MEV-Boost is systematically leaving money on the table every slot.

The Relay Trust Problem

Relays are a point of trust in the current PBS system. The relay holds the full block temporarily - after the validator commits to the header but before the full block is revealed - to prevent the validator from stealing the builder’s transactions.

This creates several failure modes:

Relay downtime - if your only registered relay is offline when your slot arrives, MEV-Boost falls back to local block building. You miss the MEV premium for that slot.

Relay censorship - some relays enforce OFAC compliance, meaning they filter transactions touching sanctioned addresses. A validator using only OFAC-compliant relays will miss certain bundles. A validator using a non-censoring relay includes everything but may attract regulatory scrutiny in some jurisdictions.

Relay collusion - in theory, a relay could front-run builder transactions by inspecting the full block before forwarding it. This has not been demonstrated in practice, but the trust assumption is real.

The practical mitigation for production validators: register with 3-5 relays across the censoring/non-censoring spectrum. MEV-Boost takes the highest bid it receives, so redundancy improves both revenue and reliability.

MEV on Solana: The Jito Ecosystem

Solana’s architecture is different enough that “MEV” works differently, but the economic incentive is identical. Solana does not have a mempool in the Ethereum sense - transactions are forwarded directly to the current leader (validator) via a gossip network. Block time is 400ms. The throughput is orders of magnitude higher.

Jito Labs built the Solana equivalent of the MEV-Boost stack. The components:

Jito-Solana - a modified validator client (fork of the official Agave client) that adds MEV bundle processing. Validators running Jito-Solana can receive and process tip bundles.

Jito Block Engine - the off-chain service that receives bundles from searchers, simulates them, and forwards profitable bundles to Jito-Solana validators ordered by tip.

Bundle API - the interface searchers use to submit bundles. A bundle on Solana is 2-5 transactions that must land atomically in a single block slot, plus a tip transaction to the Jito tip account.

The economics: Jito validators earn tips from every bundle they include on top of their normal validator rewards. In practice, validators running Jito-Solana have earned significantly higher rewards per epoch than validators on the stock client, which has driven adoption to over 60% of Solana stake.

Why This Matters for CeFi Infrastructure Engineers

If you build CeFi exchange connectivity, you might think MEV is purely a DeFi concern. It is not, for three reasons.

Private order flow is now a product. Coinbase, Binance, and other major exchanges have explored or implemented order flow monetization. If you understand how Flashbots built a private order flow auction, you understand the mechanics of what Exchange X is selling when they offer preferential data access to market makers.

Block space arbitrage between CeFi and DeFi is a real trading strategy. When ETH price moves sharply on Coinbase, there is typically a profitable arbitrage available on Uniswap before on-chain prices fully adjust. The traders running this strategy need low-latency CeFi connectivity and MEV infrastructure simultaneously. Building exchange connectivity without awareness of the on-chain side means building half the picture.

Cross-domain MEV - the extraction of value across the CeFi/DeFi boundary - is where a significant amount of alpha lives in 2026. The infrastructure to participate requires understanding both sides.

How This Breaks in Production

The MEV stack has failure modes that only surface under load or adversarial conditions.

Builder simulation lag - builders simulate bundles locally before including them in a block. If the chain state changes between simulation and block production (due to another transaction landing first), a bundle’s profit calculations may be wrong. Well-built searchers simulate against the latest state aggressively and discard stale bundles rather than submitting ones that will revert.

Relay latency cliffs - validators have a hard deadline for each slot. If MEV-Boost does not receive a valid block header from any relay within the deadline, it falls back to local building. I have seen relay outages during high-congestion periods where 15-20% of slots fell back to local builds for a 20-minute window. Any validator that had not tested this fallback path found out the hard way.

Jito tip account exhaustion - on Solana, the tip account is a known address. During periods of very high MEV competition, the tip transaction queue can back up. Searchers who submit tip transactions without checking recent tip rates end up under-bidding and getting excluded.

Sandwich detection countermeasures - sophisticated protocols now implement slippage protection and private mempool submission (via services like MEV Blocker on Ethereum). As the share of transactions using private submission grows, the set of sandwichable transactions shrinks, compressing that MEV vector. The searchers who survive are the ones focused on pure arbitrage rather than user-harming extraction.

The MEV stack is not a static system. It has evolved faster in the last four years than most exchange infrastructure I have worked on. Understanding its current architecture is table stakes for anyone building serious on-chain infrastructure - and staying current with its evolution is the actual competitive edge.