MEV, maximal extractable value, is one of those terms that gets used to mean three different things in the same conversation. Some of it is structural and necessary; some of it is a quiet, regressive tax on retail users; some of it is a security problem that affects whether your protocol can be safely used.
This piece is the explainer we give to founders building a DEX, to traders trying to understand why their executions look bad, and to protocol teams whose price-sensitive operations need a credible answer to "is my protocol exposed to MEV?"
What MEV is
The mechanic is simple. Someone, historically a miner, now a block builder under proposer-builder separation, has the right to choose the order, inclusion, and exclusion of transactions in the next block. That right has economic value because transaction order matters: putting a buy before someone else's buy executes at a different price than after.
MEV is the value that can be extracted by exercising that right. It is not necessarily extractive of users; some MEV is essential infrastructure. But the MEV that affects users falls into three categories worth distinguishing.
Category 1: Necessary MEV
Arbitrage between DEXes. When ETH/USDC trades at $3,000 on Uniswap and $3,001 on SushiSwap, an arbitrageur converges the price by buying low and selling high. This MEV is what keeps decentralised markets in line with each other and with centralised price discovery. Without it, DEXes would drift wildly.
Liquidations of unhealthy positions in lending markets. When a borrower's collateral falls below the maintenance ratio, someone has to liquidate. The MEV from liquidations rewards the liquidator and protects the lending protocol from bad debt.
These activities are competitive but not extractive. Users benefit indirectly through tighter spreads and protocol solvency.
Category 2: Extractive MEV
Sandwich attacks are the canonical extractive pattern.
The mechanic:
- Attacker sees a pending swap that will move the price (e.g., a buyer wants to buy ETH).
- Attacker submits their own buy first, with a higher priority fee, executing before the victim. This raises the price.
- The victim's transaction executes, paying the new (higher) price.
- Attacker submits a sell immediately after, executing against the price impact the victim's transaction created.
The victim gets worse execution than they would have without the attack. The difference goes to the attacker. The protocol gets nothing. The pool sees no improvement in price discovery.
Front-running of oracle updates and large swaps is similar in pattern: someone exploits the visibility of pending transactions to trade ahead of them.
These patterns are not necessary infrastructure. They are a regressive tax on users who are visible enough in the mempool to be picked off.
Category 3: Toxic MEV
Oracle manipulation combined with flash loans is the most dangerous category. An attacker uses MEV machinery, atomic transactions, mempool visibility, to drain a protocol entirely. This is not extraction at the margin; it is exploitation.
The defense is not at the MEV layer; it is at the protocol design layer, as we covered in our post on oracle manipulation.
What users lose
The numbers vary by ecosystem and tooling, but the order of magnitude is meaningful.
A retail user swapping a few thousand dollars on a public Uniswap pool through a default DEX UI, with default slippage settings, is regularly paying 10-50 basis points to MEV. On a $10,000 swap, that's $10-50. Compounded over many trades, it adds up to a meaningful chunk of trading volume captured by sandwich bots.
Larger users (institutional desks, treasury operations) often lose more in absolute terms. A $5M swap with default slippage on a public mempool can lose tens of thousands of dollars to MEV in a single transaction.
This is not catastrophic, but it is a continuous tax. And, importantly, it is largely avoidable.
What users can do
The mitigations exist and are not technically difficult.
Use a private mempool
Flashbots Protect, MEV Blocker, and similar services route your transaction directly to block builders without broadcasting it publicly. Sandwich bots cannot sandwich what they cannot see.
In MetaMask, this is a one-time RPC change. Other wallets have similar settings. Most of the cost is the awareness that this option exists.
Set realistic slippage
A common UI pattern is "slippage tolerance: 50%" because the default failed for the user once and they raised it without thinking. 50% slippage is an explicit invitation: take up to half the value of this trade as MEV.
Realistic slippage for most pools is 0.1-1%. Raising it should be a deliberate choice based on actual pool depth, not a UI default that was clicked away.
Trade on protocols with batched auctions
CoW Swap, Balancer's CowSwap-style integration, 1inch Fusion, protocols that batch trades and match them at a uniform price within each batch eliminate sandwich attacks structurally. They also tend to give better execution on average.
Avoid trading from an obviously rich wallet
If the same wallet that holds eight figures of ETH does a $10M swap on a public DEX, sandwich bots will optimise their attacks on it specifically. Operational separation between treasury and trading helps; we cover the architecture in Wallet Setup.
What protocols can do
If you operate a DEX or any protocol that does price-sensitive operations, MEV is part of your threat model.
Default users into protected execution. A DEX UI that defaults to private-mempool routing is a DEX that captures less of its volume for MEV bots. The friction is small; the user benefit is large.
Use slippage limits, not user-set tolerance, for protocol-internal operations. Liquidations, automated rebalances, oracle-fed operations should have hard slippage caps in the contract, not user-set parameters.
Watch your own execution quality. A protocol whose own treasury operations regularly get sandwiched is a protocol whose treasury is bleeding to MEV, and which therefore should be doing those operations through a private mempool or a batched auction.
Treat MEV in your audit. A serious Smart Contract Audit considers MEV as a threat. Specifically: which protocol operations are price-sensitive, can they be sandwiched, what is the worst-case loss?
Where this is going
The MEV landscape changes faster than most security topics. Proposer-builder separation, encrypted mempools, threshold encryption schemes, application-level batching, the cryptographic and protocol-level mitigations are maturing.
For protocol teams, the practical posture is:
- Assume your users are exposed by default.
- Make protected execution the path of least resistance.
- Treat MEV as a security topic, not a "trader concern."
For users, the practical posture is:
- Use a private mempool.
- Set realistic slippage.
- Use protocols built for protected execution when the trade size is meaningful.
The cost of awareness is low. The cost of unawareness compounds on every trade.