Answers>Learn about MEV & transaction ordering>MEV mitigation strategies
MEV mitigation strategies
// Tags
MEV protectionFlashbots
TL;DR: MEV mitigation strategies are techniques and tools designed to protect blockchain users from value extraction by transaction ordering manipulation. The most practical approaches include private transaction submission (sending transactions directly to block builders instead of the public mempool), MEV redistribution (returning captured value to the users who generated it), batch auctions (executing all trades at a uniform clearing price), and protocol-level design choices that minimize ordering-based exploitation. No single strategy eliminates MEV entirely, but combining multiple approaches can dramatically reduce the amount of value extracted from ordinary users.
The Simple Explanation
MEV extraction works because pending transactions are visible in the public mempool, giving bots the information they need to front-run, back-run, and sandwich trades. The most direct way to protect against MEV is to prevent your transaction from being visible in the first place. The second best approach is to design systems where transaction ordering does not matter, or where extracted value gets returned to the people it was taken from.
Think of it like shipping a valuable package. Sending it through the regular mail (the public mempool) means anyone along the route can see what is inside and potentially tamper with it. Private transaction services are like an armored courier: the package goes directly from you to its destination without being exposed. Batch auctions are like a sealed-bid auction: everyone submits their bid in a sealed envelope, and all bids are opened simultaneously so no one can react to anyone else's bid.
What Are the Main Types of MEV?
Mitigation makes more sense once you know what you are defending against. Most extraction falls into a handful of patterns, summarized below alongside the strategy that counters each one. For background on why these opportunities exist, see our explainer on why MEV exists.
MEV type
How it works
Primary mitigation
Front-running
A bot copies your trade with higher gas to execute first
Private submission
Sandwich attack
A bot trades before and after you to move the price
Private submission, tight slippage
Back-running
A bot trades right after you to capture arbitrage
MEV redistribution
Liquidations
Bots race to liquidate undercollateralized positions
Fair ordering, oracle design
Arbitrage
Bots equalize prices across venues
Often benign, batch auctions
Most of these depend on the attacker seeing and reordering your transaction ordering, which is exactly what the strategies below disrupt.
Private Transaction Submission
The most accessible and widely adopted MEV protection strategy is private transaction submission. Instead of broadcasting your transaction to the public mempool where bots can see and react to it, you send it through a private channel directly to block builders. Since bots cannot see your transaction in the mempool, they cannot sandwich it.
Flashbots Protect is the most popular private transaction relay. When you route your wallet's RPC connection through Flashbots Protect, your transactions bypass the public mempool entirely. They go directly to block builders participating in the Flashbots ecosystem, who include them in blocks without exposing them to searcher bots. The service is free for users and can be activated by simply changing the RPC endpoint in your wallet from a standard provider to the Flashbots Protect URL.
MEV Blocker, developed by CoW Protocol, offers a similar service with an additional feature: it runs an auction among searchers for any back-running opportunities your transaction creates, and returns the majority of the proceeds to you. This means if your transaction creates an arbitrage opportunity (which is different from being sandwiched), you recapture most of that value instead of leaving it entirely to searchers.
The limitation of private transaction services is that they only protect the user who opts in. If you submit a swap through Flashbots Protect, your specific transaction is shielded, but the broader MEV dynamics on the network remain unchanged. Private transaction submission also introduces a trust assumption: you are trusting the relay and builders not to exploit your transaction themselves. Reputable services have strong reputational incentives to honor this trust, but it is a different security model than the public, trustless mempool.
MEV Redistribution
Rather than trying to prevent MEV extraction, redistribution strategies accept that MEV will be extracted and focus on returning the value to the users who generated it. The logic is straightforward: if a user's trade creates a $50 arbitrage opportunity, that $50 should go back to the user, not to a searcher.
MEV-Share, developed by Flashbots, implements this model. When a user submits a transaction through MEV-Share, searchers can bid for the right to back-run the transaction (capturing any arbitrage it creates). The auction proceeds go to the user, minus a small fee. The user's transaction still executes normally, but the economic surplus it generates flows back to the user rather than being captured entirely by bots.
Protocol-level fee switches and value redistribution mechanisms are another form of MEV redistribution. Some DeFi protocols have explored designs where a portion of MEV generated by protocol activity (liquidations, rebalancing, oracle updates) is captured by the protocol itself and distributed to token holders or used to improve user execution prices.
Batch Auctions and Uniform Pricing
Batch auctions take a fundamentally different approach to MEV mitigation by eliminating the relevance of transaction ordering entirely. Instead of processing trades sequentially (where order determines price), a batch auction collects all trades during a time window and executes them simultaneously at a single uniform clearing price.
CoW Protocol (Coincidence of Wants) is the leading implementation of this model. When you submit a swap through CoW Protocol, your order goes into a batch along with all other pending orders. Solvers compete to find the best execution for the entire batch, matching trades against each other where possible (if Alice wants to sell ETH for USDC and Bob wants to sell USDC for ETH, they can trade directly) and routing remaining volume through onchain liquidity. All trades in the batch execute at the same price, so ordering is irrelevant.
This design eliminates sandwich attacks because there is no concept of going "before" or "after" another trade within a batch. Every participant gets the same price. It also enables peer-to-peer matching (coincidence of wants), which avoids DEX fees and slippage entirely for matched portions.
The tradeoff is latency. Batch auctions require collecting orders over a time window before executing them, which means trades are not instant. For users who prioritize best execution over speed, this is often an acceptable tradeoff.
Protocol-Level Design Choices
Beyond user-facing tools, MEV can be mitigated through smart contract and protocol design decisions that reduce the surface area for ordering-based exploitation.
Time-weighted average prices (TWAPs) spread large trades across multiple blocks, reducing the per-block price impact and making sandwich attacks less profitable. Instead of swapping $1 million in a single transaction (which creates a massive, easily sandwiched price impact), a TWAP order splits it into $50,000 chunks executed over 20 blocks. Each individual chunk has minimal price impact and is less attractive to sandwich bots.
Commit-reveal schemes require users to first commit to a trade (submitting an encrypted hash of their intent) and then reveal the details in a later block. Since the transaction details are hidden during the commit phase, bots cannot see what the user is trading and therefore cannot front-run or sandwich. The reveal phase exposes the trade details, but by then it is too late for ordering-based exploitation.
Oracle design also has MEV implications. Protocols that use onchain oracles updated by transactions create MEV opportunities around each update. Chainlink and other oracle providers have explored designs that minimize the ordering advantage around oracle updates, including delayed updates, multi-block averaging, and encrypted oracle submissions.
How Do the MEV Mitigation Strategies Compare?
No single approach is right for every situation. The table below contrasts the main strategies by how much they protect, what they cost, and who they suit best.
Strategy
Protection
Tradeoff
Best for
Private submission
Strong against sandwiching
Trust in the relay
Most everyday users
MEV redistribution
Returns captured value
Does not stop all attacks
Arbitrage-creating trades
Batch auctions
Removes ordering advantage
Slower execution
Large or price-sensitive trades
TWAP execution
Lowers per-block impact
Exposure spread over blocks
Very large swaps
Encrypted mempool
Hides intent until ordered
Still maturing
Future protocol defaults
On rollups, the entity that orders transactions is the sequencer, so Layer 2 MEV mitigation increasingly focuses on how sequencers order and reveal transactions.
Encrypted Mempools and Future Approaches
Encrypted mempools represent the next frontier of MEV mitigation. In this model, transactions are encrypted before entering the mempool, making their contents invisible to everyone (including block builders) until after the block order has been committed. Threshold encryption schemes require a committee of participants to collaboratively decrypt transactions only after the block order is finalized, preventing any individual actor from gaining an information advantage.
Several research projects and testnet implementations are exploring encrypted mempools, including Shutter Network on Ethereum and various designs being prototyped for L2 sequencers. The technical challenges are significant: encryption adds computational overhead, the decryption committee introduces new trust assumptions, and the system must handle edge cases like transactions that become invalid after decryption. But if implemented successfully, encrypted mempools could eliminate the information asymmetry that enables most forms of MEV extraction.
Can MEV Be Eliminated Completely?
No, and not all MEV is harmful. Activities like arbitrage and timely liquidations keep prices accurate and protocols solvent, so the realistic goal is to minimize the predatory forms (front-running and sandwiching) while preserving the beneficial ones. The strongest results come from combining strategies: route trades privately, keep slippage tight, use batch auctions for size, and rely on protocol-level design where you control the contracts. As encrypted mempools mature, the information asymmetry that powers most extraction should shrink further, but MEV as an economic force will persist as long as transaction ordering carries value.
Practical Recommendations for Users and Developers
For users making DeFi trades, the most impactful actions are: route transactions through a private relay like Flashbots Protect or MEV Blocker, set slippage tolerances as tight as practically possible (lower slippage means less room for sandwich bots to extract value), use batch auction protocols like CoW Protocol for large trades, and consider TWAP execution for very large swaps.
For developers building DeFi protocols, design with MEV awareness from the start. Audit your smart contracts not just for security bugs but for MEV attack surfaces. Consider how oracle updates, liquidation mechanisms, and price-sensitive operations can be ordered exploitatively. Implement or integrate with private transaction relays for your users. Publish documentation that educates your users about MEV risks and the protection mechanisms available to them.
How Quicknode Supports MEV-Aware Development
Quicknode's infrastructure provides the foundation for both understanding and mitigating MEV in production applications. The Core API's low-latency RPC access enables developers to implement MEV protection features that depend on accurate, real-time chain state, including tight slippage estimation, optimal gas pricing, and precise transaction timing.
Quicknode Streams delivers the real-time blockchain data needed to monitor MEV activity, track sandwich attack patterns, and analyze block builder behavior. By streaming filtered transaction and event data to your analytics infrastructure, you can quantify how much MEV your users are exposed to, evaluate the effectiveness of mitigation strategies, and make data-driven decisions about which protection mechanisms to implement. The combination of fast RPC access for transaction submission and comprehensive streaming data for analysis gives developers a complete toolkit for navigating MEV in production.
Frequently Asked Questions
Is using Flashbots Protect free?
Yes. Flashbots Protect is free for users. You activate it by switching your wallet's RPC endpoint to the Flashbots Protect URL, after which your transactions skip the public mempool.
Does private submission stop every kind of MEV?
No. It is very effective against sandwich attacks because bots cannot see your transaction, but it does not change network-wide dynamics and relies on trusting the relay and builders not to misuse your transaction.
What is the difference between front-running and back-running?
Front-running places a bot's transaction before yours to act on your intent, often harming you. Back-running places a transaction immediately after yours to capture arbitrage your trade created, which redistribution services can return to you.
Are batch auctions slower than normal swaps?
Yes, slightly. Batch auctions collect orders over a short window before settling them at a uniform price, so execution is not instant. The tradeoff is better protection from ordering-based attacks.
How can developers measure MEV exposure?
By streaming and analyzing transaction and event data, developers can detect sandwich patterns and quantify value lost. Real-time pipelines like Streams make this analysis practical at scale.
