Lecture 13: Maximal Extractable Value (MEV)
Instructor: Yu Feng, UCSB
CS190: Blockchain Programming and Applications
Lecture 13 — This lecture explores Maximal Extractable Value (MEV), a fundamental economic phenomenon in blockchain systems. We examine how block producers and specialized actors extract value by strategically ordering transactions, analyze common MEV strategies including front-running and sandwich attacks, and discuss both harmful and beneficial impacts on the ecosystem
The Blockchain Mempool: A Public Waiting Room
When a user sends a transaction—whether a token transfer, DEX swap, or loan repayment—it enters the mempool (memory pool), a public waiting area for unconfirmed transactions. Every node maintains its own mempool version, converging on similar pending transaction sets.
The mempool's defining characteristic is transparency: all transactions, their contents, and associated gas fees are publicly visible. This transparency enables decentralized operation but creates a unique economic environment that makes MEV possible.
Block producers observe the public mempool and can reorder transactions to maximize their own profit when creating new blocks.
What is MEV? Defining a New Financial Primitive
01
Historical Origin
Originally "Miner Extractable Value" in Proof-of-Work systems, the term evolved to "Maximal Extractable Value" after Ethereum's transition to Proof-of-Stake and the emergence of other privileged block producers like rollup sequencers.
02
Core Definition
MEV is the maximum value extractable by block producers through strategic inclusion, exclusion, or reordering of transactions within blocks they create—beyond standard block rewards and transaction fees.
03
Information Asymmetry
MEV exists due to information asymmetry: transactions are public and can be front-run, back-run, or reordered before confirmation. Block producers and specialized "searchers" exploit this by monitoring the mempool for profitable opportunities.
Core MEV Strategies
The Good, The Bad, and The Ugly
MEV strategies range from simple to sophisticated, often involving multiple transactions bundled for atomic execution. Understanding these mechanisms reveals both the predatory and beneficial aspects of MEV in decentralized finance.
Front-running
Executing transactions before victims by paying higher gas fees
Back-running
Capitalizing on price movements immediately after target transactions
Sandwich Attacks
Combining front-running and back-running to trap victim transactions
Front-running and Back-running: The Basic Tools
Front-running Mechanics
A front-runner spots a profitable pending transaction in the mempool—such as a large DEX swap that will significantly move an asset's price. The attacker submits their own transaction with a higher gas fee, ensuring priority execution.
By executing first, the front-runner causes the price to move up, forcing the original transaction to execute at a worse, less favorable price. This directly harms the victim while benefiting the attacker.
Back-running Mechanics
Back-running involves executing a transaction immediately after a target transaction to profit from its price impact. For example, if a large trade creates a price imbalance between two DEXs, a back-runner can arbitrage by buying on the cheaper DEX and selling on the pricier one.
Back-running is often considered less harmful than front-running because it doesn't directly worsen the victim's execution—it simply captures a profit opportunity the victim's trade created.
The Sandwich Attack: A Profitable Combination
The sandwich attack combines front-running and back-running to profit directly at a user's expense, "sandwiching" the victim's transaction between two attacker transactions. This is one of the most common and harmful MEV strategies.
1
Step 1: Front-run
Bob's bot spots Alice's 100,000 USDC swap for M-Token in the mempool and submits a buy order with higher gas, executing first and raising the price.
2
Step 2: Victim Trade
Alice's transaction executes at the inflated price caused by Bob's front-run, receiving fewer M-Tokens than expected—suffering slippage.
3
Step 3: Back-run
Bob immediately sells all acquired M-Tokens at the even higher price created by Alice's large trade, profiting from the price movement he orchestrated.
Liquidation MEV: A Necessary Evil
In decentralized lending protocols like Aave, liquidation represents a critical form of MEV. When a borrower's Health Factor drops below the critical threshold, their position becomes eligible for liquidation. Liquidators repay debt in exchange for collateral at a discount (the liquidation bonus).
This process is highly competitive: when multiple liquidator bots detect the same opportunity, they engage in intense gas wars, bidding against each other to ensure their transaction is included first. The winner claims the liquidation bonus; losers' transactions fail.
Despite appearing extractive, liquidation MEV is essential for protocol health—it ensures under-collateralized loans close quickly, protecting protocols from accumulating bad debt.
Multiple bots detect the same liquidation opportunity and submit transactions simultaneously. They engage in a gas war—the highest-paying transaction (Tx A) succeeds while others (Tx B) fail.
Oracle Latency MEV
Blockchain oracles bring off-chain data (like real-world asset prices) to smart contracts—a vital but inherently slow process. Oracles typically update on time-based schedules (e.g., every 30 minutes) or after significant price deviations (e.g., >1% change).
The Latency Problem
The delay between real-world price changes and on-chain oracle updates creates oracle latency—a window where smart contracts operate on stale, outdated information.
Exploitation Opportunity
Attackers monitor both real-world prices (on centralized exchanges) and on-chain oracle prices, exploiting discrepancies to extract massive value—sometimes with catastrophic consequences for protocols.
The 2022 LUNA/UST collapse provides a devastating real-world example of oracle latency MEV at scale.
Case Study: The LUNA De-peg
During the LUNA price crash, real-world prices on centralized exchanges like Binance fell dramatically faster than on-chain oracles updated. This created a massive, exploitable gap between market reality and on-chain perception.
1. Price Discrepancy
  • Real-world: LUNA $0.10 (Binance)
  • On-chain (stale): LUNA $1.00
  • 90% gap between market and oracle.
2. Exploit Discrepancy
  • Attacker buys 1M LUNA for $100,000 (real price).
  • Deposits 1M LUNA into protocol, valued at $1,000,000 (stale oracle price).
3. Borrow & Profit
  • Protocol allows borrowing $500,000 in USDC against inflated collateral.
  • Attacker gains $500K.
4. Devastating Result
  • Oracle updates, protocol faces $400,000 in bad debt.
  • Value extracted via oracle latency exploitation.
The Broader Impact of MEV: Pros and Cons
Benefits: The Positive Side
Price Efficiency
Arbitrage MEV helps maintain consistent pricing across different DEXs, automatically rebalancing markets and improving overall price discovery.
Protocol Solvency
Liquidation MEV provides powerful incentives ensuring lending protocols remain solvent by quickly closing under-collateralized positions.
Network Incentives
MEV revenue can constitute a significant portion of block producer income, incentivizing robust network security and participation.
Drawbacks: The Dark Side
Direct User Harm
Front-running and sandwich attacks directly harm users through increased slippage, worse execution prices, and financial losses.
Network Congestion
Fierce competition among MEV bots creates "gas wars" that artificially inflate transaction fees and clog the network for all users.
Centralization Risk
High-value MEV opportunities favor sophisticated, well-resourced entities with technical expertise and capital, creating outsized influence and centralization pressure.
MEV Mitigation Strategies
Given the significant drawbacks of malicious MEV—particularly user harm and network congestion—substantial research and engineering efforts focus on mitigation. Strategies fall into two broad categories:
Chain-Level and Protocol Solutions
These solutions modify fundamental blockchain rules or the transaction supply chain to reduce harmful MEV at the protocol level.
Application-Level Solutions
Strategies that decentralized applications (dApps), especially DEXs, implement to protect their own users from malicious MEV attacks.
Private Transaction Relays
Chain/Protocol-Level Solution: Flashbots Protect RPC
The most widely adopted MEV mitigation today uses private transaction relays, pioneered by organizations like Flashbots. This fundamentally changes how transactions reach block producers.
How It Works
Instead of broadcasting to the public mempool, users (or their wallets) send transactions directly to a private relay (e.g., Flashbots Protect RPC). The relay forwards transactions to specialized block builders with agreements to include them.
Key Benefit
Transactions remain hidden from public MEV bots until inclusion in a block, providing strong protection against front-running and sandwich attacks since attackers never see the transaction in the public mempool.
Limitation
Users must trust the relay and builder not to exploit the transaction themselves. However, reputation and economic incentives of major builders align to prevent such behavior.
Proposer-Builder Separation (PBS)
PBS represents a fundamental, long-term protocol change—Ethereum's vision for democratizing the MEV market by restructuring the block production supply chain. This addresses a critical centralization pressure in blockchain networks.
1
The Centralization Problem
Before PBS, validators who propose blocks also build them. To maximize profit, proposers must run sophisticated, resource-intensive MEV extraction software. This creates massive economies of scale favoring large staking pools.
Small solo-stakers cannot compete—their blocks are less profitable because they miss MEV revenue. This economic pressure forces users to stake with large pools, driving validator centralization.
2
The PBS Solution: Role Separation
PBS breaks this centralizing link by separating roles into two specialized actors:
  • Builders (Specialists): Highly specialized entities that build maximally profitable blocks packed with MEV, then submit bids to proposers.
  • Proposers (Validators): Simply select the most profitable block from competing builders based on bid amount, without needing MEV expertise.
3
Democratization Benefits
Solo stakers become as profitable as large pools—neither builds blocks; both accept winning bids from the open market. This removes economic pressure for validator centralization and creates a hyper-competitive building market that maximizes value returned to all stakers.
Understanding PBS: Redistributing Value, Not Eliminating MEV
Critical Insight
PBS does not stop MEV. Instead, it acknowledges a fundamental truth: extracting MEV is very difficult.
1
The Problem Without PBS
Only a few highly-skilled actors can successfully find and capture MEV profits. This makes them rich and powerful, forcing others to join them—leading to centralization.
2
PBS's Clever Solution
Create an open auction where all "smart" actors (Builders) compete against each other. To win the right to build a block, they must bid their entire potential profit to the Proposer.
3
The Result: Value Redistribution
Money is moved from the few specialists who find MEV to all validators who secure the network. This preserves decentralization while ensuring MEV value benefits the entire ecosystem rather than concentrating among elites.
Application-Level: Slippage Tolerance
Slippage tolerance is the most common user-facing MEV protection, acting as a defensive tripwire. When users make swaps, DEX interfaces require setting a slippage tolerance (e.g., 0.5%)—a strict instruction to the smart contract.
How It Works
The setting creates a strict condition: "I only agree to this trade if the final price is no worse than 0.5% from my quoted price. If price moves against me more than that, fail my transaction."
Defense Against Sandwich Attacks
This directly attacks sandwich profitability. If the attacker's front-run pushes the price beyond the tolerance limit, the victim's trade fails and reverts.
This breaks the sandwich: the attacker is stuck with tokens from the front-run with no victim to sell to at a high price. The attack fails, and the attacker loses money on gas.
Limitation
Not a perfect fix—it sets an upper bound on extractable value. Attackers design bots to extract the maximum without triggering limits. If your tolerance is 0.5%, bots will try to extract 0.49%.
Application-Level: Batch Auctions
Example: CoW Swap
Some DEXs use a batch auction model instead of instant sequential execution. This fundamental mechanism change provides powerful protection against front-running and sandwich attacks.
Collection Phase
Protocol collects all user trades from a short time window (e.g., 30 seconds) into a single "batch"
Solving Phase
A third-party "solver" examines all trades in the batch simultaneously and calculates a single, uniform clearing price
Execution Phase
Everyone in the batch receives the same price regardless of submission order
Key Benefit: Order Irrelevance
Transaction ordering within the batch becomes irrelevant. Attackers cannot front-run by placing trades "first" because "first" doesn't matter—everyone gets the same price. This design makes traditional front-running and sandwich attacks ineffective.
Execution Models: AMM vs. Batch Auction
The fundamental difference between traditional AMM and batch auction models determines vulnerability to MEV attacks. Sequential execution enables manipulation; uniform pricing prevents it.
A. Standard AMM (Sequential)
Ordering matters. Transactions execute one-by-one. If your trade is second, you get the price after the first trade impacts the pool. This sequential execution enables front-running.
The attacker gets a better price by going first, and the victim suffers worse execution due to order dependency.
B. Batch Auction
Ordering is irrelevant. All transactions are collected into a batch and given to a Solver who finds the best execution price (e.g., from an AMM or multiple sources).
The system settles all trades at one uniform price, completely neutralizing front-running attacks since transaction order provides no advantage.
References
  1. Hayden Adams, Noah Zinsmeister, and Dan Robinson. 2020. Uniswap v2 Core. https://uniswap.org/whitepaper.pdf Accessed: 2025-10-01.
  1. Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and Ari Juels. 2020. Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. In 2020 IEEE Symposium on Security and Privacy (SP). 910–927. doi:10.1109/SP40000.2020.00040
  1. Flashbots. 2025. Flashbots: Research and Tools for MEV. https://docs.flashbots.net/ Accessed: 2025-10-01.
  1. Kaihua Qin, Liyi Zhou, Benjamin Livshits, and Arthur Gervais. 2022. Quantifying Blockchain Extractable Value: How dark is the forest? Financial Cryptography and Data Security (2022). https://arxiv.org/abs/2101.05511 Accessed: 2025-10-01.
This lecture draws on foundational research in MEV, decentralized exchange security, and blockchain protocol design. These works continue to shape our understanding of value extraction and protection mechanisms in decentralized systems.