MEV (maximal extractable value) is the profit that can be taken by choosing which blockchain transactions are included in a block and in what order, and the most visible form, the sandwich attack, quietly gives users a worse price on their trades. Ethereum.org defines MEV as "the maximum value that can be extracted from block production in excess of the standard block reward and gas fees." Because pending transactions on public chains are visible before they are confirmed, automated bots can trade ahead of them (front-running), behind them (back-running) or both (sandwiching). This guide explains the types of MEV, how a sandwich attack works at a conceptual level, how private transaction routes, slippage limits and protocol designs such as batch auctions reduce the harm, and what wallet, protocol and security teams should check. It is written for DeFi users who want to understand their trade results, wallet and dApp product teams, and security teams reviewing protocols. It is defensive: it explains mechanics and controls, not how to run a bot. Projects named on this page are listed alphabetically where compared, and naming is not a recommendation. For the wider risk picture see the DeFi Risk Guide.
Key takeaways
- MEV comes from ordering power: whoever decides transaction order (validators, and in practice block builders) can capture value, and searchers compete to give them profitable bundles.
- Not all MEV harms users: ethereum.org notes that arbitrage keeps decentralised exchange prices accurate and fast liquidations keep lending protocols solvent; sandwiching, by contrast, worsens user trades.
- Slippage tolerance is the sandwich budget: the minimum output you sign (Uniswap's
amountOutMinimum) is the worst price you accept, and a sandwich can push your trade towards that limit, so loose tolerances invite extraction. - Private routing hides trades from the public mempool: services such as Flashbots Protect send transactions to a private mempool so they are not visible to front-running and sandwich bots, at the cost of trusting the relay and builders.
- Protocol design can remove the incentive: batch auctions with uniform clearing prices, as used by CoW Protocol, make order within a batch irrelevant, so there is nothing to gain by reordering.
What it is
MEV was first described as "miner extractable value" in the 2019 paper Flash Boys 2.0 by Daian and colleagues, which documented bots on decentralised exchanges paying higher fees and optimising latency to get ahead of ordinary users, and showed that these priority gas auctions could threaten consensus security. After Ethereum moved to proof of stake (The Merge), validators took over ordering and the term became "maximal extractable value".
The main actors, as ethereum.org describes them:
- Searchers: run algorithms over chain data to find profitable opportunities and submit transactions or bundles to capture them.
- Generalised front-runners: watch the mempool, copy profitable pending transactions with their own address substituted, and pay more gas to execute first.
- Builders: assemble blocks from public and private transactions and bid for the right to have them proposed.
- Validators (proposers): propose blocks and earn MEV indirectly through fees and builder bids.
| MEV type | What happens | Effect on users |
|---|---|---|
| DEX arbitrage | Buy a token where it is cheaper and sell where it is dearer in one atomic transaction | Generally neutral or positive: aligns prices across venues |
| Liquidations | Race to liquidate under-collateralised loans and collect the fee | Keeps lending protocols solvent; borrowers lose the liquidation penalty either way |
| Front-running | Copy or anticipate a pending transaction and execute first | The user's opportunity is taken or their price worsens |
| Back-running | Execute immediately after a transaction to capture the price move it creates | Usually no direct harm to the user; value can be shared back through order flow auctions |
| Sandwich attack | Trade before and after a large user swap | The user receives a worse price, up to their slippage limit |
| NFT MEV | Front-run mispriced listings or popular mints | Buyers miss listings; mint gas wars raise costs |
How it works
The public mempool
On public chains a signed transaction normally waits in a shared pool before a block includes it. Uniswap's documentation notes that transactions with lower fees can stay pending for an indeterminate time, and prices can move in that window. Anyone watching the pool sees what a user intends to trade, how much, and the worst price the user will accept.
A sandwich attack, conceptually
- A user submits a large swap on an automated market maker with a slippage tolerance, for example accepting up to 1 percent worse than the quoted price.
- A searcher sees the pending swap and places a buy of the same token just before it, which moves the pool price against the user.
- The user's swap executes at the worse price, still inside the user's tolerance, which pushes the price further.
- The searcher sells straight after, at the higher price, and keeps the difference minus fees.
The user's loss is bounded by the slippage tolerance and the pool's depth: on an automated market maker, price impact is larger in shallower pools. Ethereum.org notes sandwiching is riskier for searchers than arbitrage because it is not atomic, and that competitive gas wars can consume 90 percent or more of searchers' MEV in fees.
Block building today
On Ethereum, proposer-builder separation is used out of protocol through MEV-Boost: validators accept the highest bid from competing builders. Ethereum.org describes MEV-Boost as transitional, with higher trust assumptions than in-protocol separation would have, and raises concerns about centralisation among builders and large staking pools. For users this means a transaction sent "privately" still reaches builders; what changes is who can see it beforehand.
The defences
| Defence | How it helps | Trade-offs |
|---|---|---|
| Tight slippage tolerance and a deadline | Limits the worst price; Uniswap's amountOutMinimum or amountInMaximum makes the swap revert outside the range, and the deadline makes it revert if included too late | Too tight and swaps fail in volatile markets, costing gas on public routes |
| Private transaction routing (for example Flashbots Protect) | Transactions go to a private mempool, hidden from front-running and sandwich bots; per Flashbots, transactions are included only if they do not revert, so failed swaps do not cost fees | Trust in the relay and builders; inclusion may be slower; private pools can make the network more "pay-to-play", as ethereum.org warns |
| Order flow auctions (for example MEV-Share) | Users share selected hints; searchers bid to back-run, and Flashbots states users receive 90 percent of the MEV by default | Only back-runs accepted; hints reveal some information |
| Batch auctions and intents (for example CoW Protocol) | Orders settled in batches at uniform clearing prices by competing bonded solvers, who must meet the user's signed limit price; coincidences of wants are matched peer to peer | Depends on solver competition and honesty; settlement timing differs from instant swaps |
| Splitting large trades | Smaller trades cause less price impact, so less to extract | More fees and more transactions |
| Protocol-level design | Oracles resistant to manipulation, commit-reveal schemes and fair ordering reduce the value of reordering | Engineering cost; some approaches are still research |
Why it matters
- Hidden cost to users: a sandwiched trade looks like normal slippage in a wallet, so users rarely realise value was taken.
- Network cost: ethereum.org notes gas auctions congest the network and raise fees for everyone.
- Consensus risk: if MEV exceeds the block reward, validators may be tempted to reorganise the chain, a risk first raised in Flash Boys 2.0.
- Centralisation: exclusive order flow and large builders concentrate power, and private routes require trusting fewer parties.
- Automated agents trade too: trading bots and AI agents that hold wallet keys and submit swaps with loose slippage settings are as exposed as humans, and do it at machine speed. Their signing keys and RPC endpoints are non-human identities that need limits and monitoring. See the AI Agents with Crypto Wallets Security Guide.
What to monitor
- Realised versus quoted price: for wallets and trading desks, the gap between quote and execution per swap, flagged when it nears the slippage limit.
- Adjacent transactions: trades by the same address immediately before and after a user's swap in the same pool and block are the signature of a sandwich. See the Blockchain Analytics and On-Chain Monitoring Guide.
- Route mix: share of user swaps sent through private routes or batch settlement versus the public mempool.
- Failure rate: reverted swaps from tight tolerances, which signal settings that need tuning.
- Refunds received: MEV and gas refunds from order flow auctions, as a measure of value returned to users.
Common misconceptions
- "MEV is always theft." Arbitrage and liquidations are useful; the harm is concentrated in front-running and sandwiching.
- "Private RPC means private forever." Private routing hides a transaction until inclusion; once on chain everything is public, and the relay and builders see it first.
- "A high slippage setting makes swaps reliable at no cost." It makes them succeed by accepting a worse price, which is exactly the room a sandwich uses.
- "Only large trades get sandwiched." Size matters relative to pool depth and tolerance; a small trade in a thin pool with loose tolerance can be profitable to attack.
- "It is just like stock market front-running, so it is illegal." Legal treatment of on-chain MEV is unsettled and varies by jurisdiction; do not rely on law as a defence.
- "Wallet security covers this." MEV does not need your keys; it exploits a valid transaction you signed. Key security still matters for drainers, covered in the Crypto Scam and Drainer Guide.
Related concepts
| Concept | Relation to MEV |
|---|---|
| Price impact | The price move your own trade causes on an automated market maker; MEV exploits it |
| Slippage | Price change while a transaction is pending; tolerance caps it |
| Proposer-builder separation | Splits building from proposing to reduce reorg incentives; MEV-Boost implements it out of protocol |
| Intents and solvers | Users sign an outcome, not a transaction path; solvers compete to deliver it |
| Oracle manipulation and flash loans | Related DeFi attack classes that also exploit atomic ordering; covered in the DeFi Risk Guide |
| Smart contract and chain security | The wider control set; see the Blockchain and Distributed Ledger Security Guide |
Practitioner checklist
- Default wallet and dApp swap settings to a sensible slippage tolerance and a short deadline; warn users who loosen them.
- Offer a private transaction route or batch settlement option and explain its trust trade-offs.
- Show quoted price, price impact and minimum received before signing.
- For protocols, review whether any function's outcome depends on transaction order, and use commit-reveal, batching or manipulation-resistant oracles where it does.
- For trading bots and AI agents, cap trade size and slippage in policy, route privately, and protect their signing keys and RPC credentials like any other machine identity.
- Monitor realised versus quoted prices and adjacent-transaction patterns, and track the share of volume protected.
- Re-check MEV protection settings after wallet, router or RPC changes.
Standards and references
- Ethereum.org: Maximal extractable value (MEV)
- arXiv: Flash Boys 2.0, Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges
- CoW Protocol docs: MEV protection
- Flashbots docs: Flashbots Protect overview
- Flashbots docs: MEV-Share introduction
- Uniswap docs: Swaps, price impact and slippage
Related NHI Mgmt Group resources: DeFi Risk Guide · Crypto Wallet Security Guide · Blockchain Analytics and On-Chain Monitoring Guide · AI Agents with Crypto Wallets Security Guide