Published on Sat Aug 22 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos
If you have ever swapped tokens on a decentralized exchange and received a worse price than the quote showed, there is a good chance you were extracted. Not by the exchange. Not by a fee. By a class of automated bots that monitor the public mempool, identify profitable trading opportunities, and manipulate transaction ordering to capture value at your expense.
This is MEV. It stands for Maximal Extractable Value, originally Miner Extractable Value before Ethereum’s transition to proof-of-stake. It is one of the most studied and least understood phenomena in decentralized finance. This article explains what MEV is, how the most harmful form (sandwich attacks) works, and the four general approaches to protecting users against it.
What Is MEV
MEV is the value that can be extracted from a block by strategically ordering, including, or excluding transactions. On Ethereum and EVM-compatible chains, transactions sit in a public mempool before they are included in a block. Anyone can see them. Anyone can react to them.
Block producers (miners under proof-of-work, validators under proof-of-stake) have the power to choose which transactions to include and in what order. This ordering power has economic value. If a large swap is sitting in the mempool, a bot can front-run it by submitting a buy transaction first, let the large swap push the price up, and then sell immediately after. The bot captures the price difference. The original trader gets a worse price.
MEV is not inherently malicious. Arbitrage, for example, is a form of MEV that keeps token prices consistent across different pools and exchanges. When a token trades at $1.00 on Uniswap and $1.02 on SushiSwap, an arbitrageur buys on Uniswap and sells on SushiSwap, capturing the $0.02 difference. This benefits the ecosystem by keeping prices aligned.
But other forms of MEV are purely extractive. Sandwich attacks and front-running transfer value from ordinary users to sophisticated bots. These are the forms that MEV protection aims to eliminate.
How Sandwich Attacks Work
A sandwich attack is the most common and most harmful form of MEV extraction on DEXs. Here is how it works:
-
The victim submits a swap. A user submits a transaction to swap, say, 10 ETH for USDC on Uniswap. This transaction enters the public mempool.
-
The attacker sees the transaction. An MEV bot monitors the mempool and identifies the pending swap. The bot calculates that this large buy will move the price of ETH significantly upward.
-
The attacker front-runs. The bot submits its own buy transaction with a higher gas price, ensuring it is included in the block before the victim’s transaction. The bot buys ETH at the current price.
-
The victim’s transaction executes. The victim’s swap goes through, but because the bot’s buy already moved the price up, the victim gets fewer USDC than they expected. The slippage tolerance on the victim’s transaction prevents it from reverting, so the trade completes at a worse price.
-
The attacker back-runs. The bot immediately sells the ETH it bought, now at the higher price created by the victim’s swap. The bot pockets the difference.
The victim is “sandwiched” between the attacker’s buy and sell. The attacker profits. The victim loses. The loss is often invisible to the victim, who sees a swap that completed successfully but at a worse price than quoted.
The Scale of the Problem
The numbers are significant. Research from EigenPhi documented 182,246 sandwich attacks in the first six months of 2022 alone, causing traders to lose $87.7 million. A UCL study estimated that over 32 months, blockchain extractable value yielded $540.54 million in profit across sandwich attacks, liquidations, and DEX arbitrage.
More recent data shows the problem persisting. Between November 2024 and October 2025, EigenPhi tracked over 95,000 sandwich attacks. Monthly extraction from sandwich attacks peaked at nearly $10 million in late 2024 before declining to about $2.5 million by October 2025. The decline is partly attributed to wider adoption of MEV protection tools, but the annual loss to traders was still approximately $60 million.
Nearly 40% of sandwich attacks hit low-volatility pools, meaning even swaps typically considered safe can be targeted. The average profit margin for attackers was only about 5%, with block builders capturing most of the extracted value through gas fees.
Four Approaches to MEV Protection
The DeFi ecosystem has developed four general approaches to protecting users from MEV extraction. Each works differently and has different tradeoffs.
Approach 1: Private Mempools
The simplest approach to MEV protection is to prevent transactions from entering the public mempool in the first place. If MEV bots cannot see your transaction, they cannot front-run it.
How It Works
Private mempools (also called private order flow or private relays) route transactions directly to block builders without broadcasting them to the public mempool. The transaction is invisible to MEV bots until it is already included in a block.
Flashbots pioneered this approach with its MEV-Boost relay for Ethereum proof-of-stake. Users submit transactions to a private relay, which forwards them to block builders who include them directly in blocks. The transactions never appear in the public mempool.
What It Does and Does Not Solve
Private mempools prevent front-running and sandwich attacks by hiding transactions from bots. But they have limitations:
- Trust requirement. The user trusts the private relay not to exploit or censor their transaction.
- Not cryptographic. Protection depends on the relay’s reputation and operational integrity, not on mathematical guarantees.
- Private sandwich attacks exist. Research from late 2024 found that private routing does not guarantee protection. A study identified 2,932 private sandwich attacks affecting 3,126 private victim transactions between November and December 2024, producing $409,236 in losses. A single bot accounted for nearly two-thirds of private front-runs.
- Centralization risk. Private order flow concentrates block production power in a small number of relays and builders, which can degrade decentralization.
Approximately 40% of sandwich victims migrate to private routing within 60 days of their first attack, according to the same study. But private routing alone is not sufficient protection.
Approach 2: Batch Auctions
Batch auctions eliminate MEV by making transaction ordering irrelevant. If all trades in a batch execute at the same clearing price, there is no advantage to being first or last.
How It Works
Instead of executing trades one by one as they arrive, the protocol collects orders over a fixed time window (a batch). At the end of the window, all orders in the batch are settled simultaneously at a uniform clearing price.
The key property is uniform directed clearing prices. If multiple orders trade the same token pair in the same direction within a batch, they all clear at the same price. This makes transaction ordering within the batch irrelevant. A MEV bot cannot profit by inserting a transaction before or after another, because both would execute at the same price.
Who Uses This Approach
CoW Protocol is the primary example of batch auction MEV protection. CoW Protocol collects user-signed intents off-chain, auctions them to competing solvers, and settles them in batches with uniform clearing prices. The protocol has surpassed $20 billion in trading volume. Its MEV protection works through three mechanisms:
- Uniform clearing prices. All trades in the same direction within a batch settle at the same price, making order irrelevant.
- Delegated execution. Users do not submit transactions to the public mempool. Solvers submit settlements on their behalf.
- Coincidence of Wants. When two users have opposite trading intentions, their orders can be matched peer-to-peer without touching on-chain liquidity, bypassing AMM mechanics entirely.
1inch also uses batch auction mechanics in its Fusion mode. Users sign intents that are filled by resolvers through a Dutch auction, with built-in MEV protection.
Tradeoffs
Batch auctions introduce a waiting period. Orders are not executed immediately. They wait for the next batch settlement, which can take seconds to minutes depending on the protocol’s cadence. For users who need immediate execution, this delay may be unacceptable.
Batch auctions also require solver infrastructure. If no solver can find a profitable settlement for a batch, orders may go unfilled.
Approach 3: Intent-Based Execution
Intent-based execution protects against MEV by removing the user’s transaction from the public mempool entirely. Instead of submitting a transaction, the user signs an intent. A solver executes the trade on-chain.
How It Works
An intent is a signed off-chain message specifying what the user wants (e.g., “receive at least 1,000 USDC for 1 ETH”). The intent is not a transaction. It cannot be seen by MEV bots in the public mempool. Solvers compete to fill the intent by finding the best execution path and submitting the settlement transaction themselves.
Because the solver submits the transaction, the solver bears the MEV risk. The solver’s settlement is typically submitted through private relays or optimized to minimize exposure. The user’s price is guaranteed by the signed intent: the solver must deliver at least the minimum specified.
Who Uses This Approach
UniswapX is Uniswap’s intent-based swap protocol. Users sign orders specifying their swap parameters. Fillers compete to satisfy these orders using arbitrary fill strategies. The protocol provides gasless experience, MEV protection, and access to arbitrary liquidity sources.
1inch Fusion uses intent-based execution with a Dutch auction mechanism. Users sign intents that resolvers fill through progressively improving prices until a resolver is willing to execute.
CoW Protocol combines intent-based execution with batch auctions, as described above. Users sign intents, solvers compete, and settlements use uniform clearing prices.
Tradeoffs
Intent-based execution shifts MEV risk from the user to the solver. This is generally beneficial for users, but it means the solver’s costs (including MEV exposure) are factored into the price the user receives. If solvers face high MEV costs, the user’s price may be worse than a direct execution would have been (assuming no MEV extraction).
There is also a fill risk. If no solver is willing to fill the intent at the user’s specified price, the order goes unfilled. In Dutch auction models, the price degrades over time until a solver is willing to fill, which can result in worse execution for impatient users.
Approach 4: Threshold Encryption
Threshold encryption is the most technically ambitious approach to MEV protection. It aims to make transaction content invisible until ordering is final, using cryptography rather than trust or off-chain infrastructure.
How It Works
In a threshold-encrypted mempool, users encrypt their transactions before submitting them. The encrypted transactions are included in blocks and ordered by the block builder. But the builder cannot read the transaction content, so they cannot identify MEV opportunities.
After the block’s transaction ordering is committed, a distributed committee of key holders (called a “keeper” or “keyper” committee) collaborates to decrypt the transactions. Only then can the transactions be executed. Because the ordering was already fixed before anyone could see the content, front-running and sandwich attacks are impossible.
The committee uses a k-of-n threshold scheme. No single party holds the full decryption key. At least k of n committee members must cooperate to decrypt. This prevents any single party from decrypting transactions early.
Research and Deployment Status
Threshold encryption is an active research area. Key developments include:
- Shutter Network implemented threshold encryption for Gnosis Chain, using a committee of keypers to encrypt and decrypt transactions.
- Ferveo developed threshold encryption for the Penumbra blockchain with a focus on private DeFi.
- EIP-8184 (LUCID) proposes a public encrypted mempool for Ethereum, using commit-before-reveal inclusion of MEV-sensitive transactions without enshrining a specific encryption scheme.
- EIP-8105 addresses the Ethereum deployment debate for encrypted mempools.
- A 2025 USENIX Security paper constructed the first practical mempool privacy scheme using one-time distributed key generation, achieving transaction encryption in approximately 8.5 milliseconds.
A 2026 systematization of knowledge (eprint 2026/1643) surveyed the evolution of threshold-encrypted mempools and identified a convergence along four design axes: batched decryption to mitigate latency, silent setup to eliminate distributed key generation complexity, epochless encryption to remove position dependency, and collision-free encoding to prevent slot-collision censorship.
Tradeoffs
Threshold encryption is the most complex approach. It requires a committee of key holders, distributed key generation, and integration with block builders. The committee must be sufficiently decentralized to prevent collusion.
There is also a latency cost. Decryption cannot happen until after ordering is committed, which adds a delay to transaction execution. This delay is typically in the range of tens to low hundreds of milliseconds, which is acceptable for most applications but may matter for time-sensitive operations.
A critical limitation identified in recent research is that blind ordering and binary decryption suppress not only toxic MEV but also beneficial same-block auction mechanisms that return value to users. Threshold encryption is a blunt instrument: it eliminates all MEV, including the forms that benefit users.
How the Approaches Compare
| Approach | MEV Type Addressed | Trust Model | Latency Cost | Deployment Status |
|---|---|---|---|---|
| Private mempools | Front-running, sandwich | Trust in relay | Low | Widely deployed |
| Batch auctions | Sandwich, front-running | Trust in solver | Medium (batch wait) | Deployed (CoW, 1inch) |
| Intent-based | Sandwich, front-running | Trust in solver | Low to medium | Deployed (UniswapX, 1inch Fusion) |
| Threshold encryption | All MEV types | Trust in committee | Medium (decryption delay) | Early deployment, active research |
No single approach is universally best. Private mempools are simple but not cryptographically guaranteed. Batch auctions eliminate ordering MEV but add latency. Intent-based execution shifts risk to solvers but introduces fill risk. Threshold encryption is the most comprehensive but the most complex to deploy.
Which Platforms Use Which Approach
The mapping is not always one-to-one. Many platforms combine approaches:
- UniswapX uses intent-based execution. Users sign orders, fillers compete, MEV protection is inherent.
- CoW Protocol uses batch auctions with uniform clearing prices and intent-based settlement. Solvers compete to settle batches.
- 1inch Fusion uses intent-based execution with a Dutch auction. Resolvers fill intents with built-in MEV protection.
- Flashbots Protect uses private mempool routing. Transactions are sent to a private relay instead of the public mempool.
- Shutter Network uses threshold encryption on Gnosis Chain.
Why MEV Protection Matters
MEV extraction is a tax on DEX users, and it is one of the hidden costs explained in our guide to understanding DEX aggregator fees. It is often invisible. Users do not see a line item for “MEV extraction” in their transaction receipt. They see a swap that completed at a slightly worse price than expected. They may attribute this to slippage, to pool fees, or to market movement. In reality, a bot inserted transactions around theirs and captured value that should have stayed with the user.
The annual cost to traders from sandwich attacks alone is approximately $60 million, based on data from November 2024 to October 2025. For methods to detect whether your own swaps were sandwiched, see our guide on MEV detection tools and methods. This does not include other forms of MEV extraction like just-in-time liquidity, back-running, and arbitrage that may also extract value from user trades.
MEV protection is not a luxury feature. It is a baseline requirement for any DEX or aggregator that claims to offer best execution — and real-time MEV monitoring is how you verify it is working. Without it, the price you see is not the price you get.
Conclusion
MEV is the value extracted from block transaction ordering. Sandwich attacks are the most harmful form, costing traders tens of millions of dollars annually — for a technical breakdown of how sandwich bots exploit the mempool, see Sandwich Attack Anatomy. Four approaches exist to protect users: private mempools hide transactions from bots, batch auctions make ordering irrelevant, intent-based execution delegates risk to solvers, and threshold encryption uses cryptography to prevent pre-execution visibility.
Each approach has tradeoffs. Private mempools rely on trust. Batch auctions add latency. Intent-based execution introduces fill risk. Threshold encryption is complex to deploy. In practice, production systems combine multiple approaches to maximize protection while minimizing tradeoffs.
If you want to see MEV protection in practice on Base, including gasless swaps on Base, Orkid is a product built on Base. The specifics of its MEV protection approach are beyond the scope of this article, which covers only the general concepts and publicly documented protection strategies.
Frequently Asked Questions
What is MEV?
MEV (Maximal Extractable Value) is the profit that block producers or searchers can extract by reordering, including, or excluding transactions within a block. It is value that would not exist if transactions were processed in the order they were received. MEV takes many forms including sandwich attacks, arbitrage, and liquidations.
How do sandwich attacks work?
A sandwich attack occurs when a bot sees a pending swap in the mempool and places two transactions around it. The bot buys the token first (front-run), pushing the price up, then sells immediately after the victim’s swap executes (back-run). The victim gets a worse price, and the bot pockets the difference.
Can MEV be prevented?
MEV cannot be fully eliminated, but it can be significantly reduced. Protection methods include private mempools that hide transactions from bots, batch auctions that make transaction ordering irrelevant, and intent-based execution where a solver handles the trade privately. Each method has tradeoffs in latency, trust, and cost.
What is front-running in crypto?
Front-running is when a trader or bot exploits knowledge of a pending transaction to place their own transaction first for profit. In crypto, this happens because the mempool is public, allowing anyone to see unconfirmed transactions. It is a form of MEV and is one of the most common ways traders lose value on DEX swaps.
Written by Jacob Cavazos
← Back to blog