Published on Sun Aug 23 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 decent chance you were sandwiched. Sandwich attacks are one of the most common forms of maximal extractable value (MEV) extraction, and they cost DEX traders millions of dollars every year. The attack is simple in concept: a bot sees your pending swap in the public mempool, buys the token before you, lets your transaction push the price up, and then sells immediately after.
The good news is that sandwich attacks are preventable. Not with a single silver bullet, but with a combination of techniques that reduce your exposure to the public mempool and make your transactions harder to exploit. This guide covers the practical defense strategies that actually work, from slippage settings to private mempools to intent-based execution. For a deeper understanding of how sandwich attacks work mechanically, see our article on MEV detection tools and methods.
What Is a Sandwich Attack (Brief Recap)
A sandwich attack is a three-transaction pattern. The victim submits a swap that will move the price of a token. An MEV bot monitoring the public mempool sees this pending transaction and executes two transactions around it.
First, the bot front-runs the victim by buying the same token. This pushes the price up. Second, the victim’s transaction executes at the inflated price, paying more than they should have. Third, the bot back-runs by selling the token it just bought, capturing the price difference as profit.
The victim loses money in two ways. They pay a higher price for the token they bought, and the price impact of their own trade is amplified by the bot’s front-run. The bot profits from the difference between its buy price and sell price, minus gas and transaction costs.
Sandwich attacks are profitable because AMM (Automated Market Maker) pools have predictable price curves. When a bot sees a large buy order in the mempool, it can calculate exactly how much the price will move and determine whether front-running is profitable. For a detailed breakdown of the mechanics, see our guide on real-time MEV monitoring.
Defense Strategy 1: Slippage Tolerance Settings
The simplest defense against sandwich attacks is setting an appropriate slippage tolerance. Slippage tolerance tells the DEX the maximum price change you are willing to accept. If the price moves beyond your tolerance, the transaction reverts.
How Slippage Tolerance Works
When you submit a swap on Uniswap, SushiSwap, or any other AMM, you specify a minimum amount of output tokens you are willing to receive. This is calculated from your slippage tolerance percentage. If you set 0.5% slippage on a swap that should output 1,000 USDC, the minimum you will accept is 995 USDC. If the actual output would be less than 995 USDC, the transaction reverts.
A sandwich attacker profits by moving the price against you. If your slippage tolerance is tight enough, the attacker’s front-run will push the price beyond your tolerance, causing your transaction to revert. The attacker’s front-run transaction still executes, but without your transaction in the middle, the attacker cannot back-run profitably and may actually lose money on gas.
The Trade-Off
Setting slippage too low causes transactions to revert when there is legitimate price movement from other trades, network congestion, or oracle updates. Setting it too high leaves you exposed to sandwich attacks. The right setting depends on the token’s liquidity and volatility.
For highly liquid pairs (like USDC/USDT or ETH/USDC on major pools), a slippage of 0.1-0.5% is usually sufficient. For less liquid or more volatile tokens, 1-3% may be necessary to avoid constant reverts. The key is to set the lowest slippage that still allows your transaction to execute under normal conditions.
Why Slippage Alone Is Not Enough
Slippage tolerance is a necessary but insufficient defense. Sophisticated attackers can still profit from sandwiches even with tight slippage settings, especially on large trades or in pools with deep liquidity. Additionally, setting slippage too low can make your transactions impossible to execute, which is its own form of cost. Slippage should be combined with other defenses for robust protection.
Defense Strategy 2: Private Mempools and Flashbots
The most effective defense against sandwich attacks is to prevent your transaction from ever appearing in the public mempool. If the attacker cannot see your transaction, they cannot front-run it.
What Is a Private Mempool
A private mempool is a transaction submission channel that bypasses the public mempool. Instead of broadcasting your transaction to the public network of nodes, you submit it directly to a block builder or validator through a private channel. The transaction is included in a block without ever being visible to mempool watchers.
Flashbots introduced the concept of private transaction submission to Ethereum with its MEV-Boost infrastructure. When you submit a transaction through a private relay, it goes directly to block builders who include it in their block proposals. MEV bots that monitor the public mempool never see the transaction, so they cannot sandwich it.
How to Use Private Mempools
Several wallets and DEX aggregators now offer private mempool submission as a built-in feature. When you swap through these platforms, your transaction is routed through a private relay automatically. Some popular options include:
- MEV-protecting RPCs: These are custom RPC endpoints that route your transactions through private relays. You can configure your wallet to use an MEV-protecting RPC instead of a standard public RPC.
- DEX aggregators with MEV protection: Many aggregators now submit transactions through private channels by default, protecting users from sandwich attacks without requiring any configuration.
- Flashbots Protect: A public service that allows anyone to submit transactions through a private relay. You can configure your wallet’s RPC to point to the Flashbots Protect endpoint.
Limitations of Private Mempools
Private mempools are not a perfect solution. First, they may increase transaction latency slightly, as the transaction must be routed through the relay and picked up by a block builder. Second, not all chains support private mempool infrastructure. Ethereum has the most mature ecosystem, but Layer 2s and other chains are still developing their private submission infrastructure. Third, the block builder ecosystem is somewhat centralized, which introduces its own trust assumptions.
Defense Strategy 3: MEV-Protecting RPCs
MEV-protecting RPCs combine the benefits of private mempools with additional MEV-aware routing. When you use an MEV-protecting RPC, your transactions are not only hidden from the public mempool but also routed in a way that minimizes MEV extraction.
How MEV-Protecting RPCs Work
An MEV-protecting RPC intercepts your transaction before it reaches the public network. It then submits the transaction through a private channel to block builders. Some MEV-protecting services also offer “back-running” protection, where they attempt to capture any MEV from your transaction and return it to you rather than letting it be captured by third-party bots.
The practical benefit is significant. Studies have shown that transactions submitted through MEV-protecting RPCs experience dramatically lower rates of sandwich attacks compared to transactions submitted through standard public RPCs. For regular DEX traders, switching to an MEV-protecting RPC is one of the highest-impact, lowest-effort defenses available.
Setting Up an MEV-Protecting RPC
Configuring an MEV-protecting RPC typically involves changing your wallet’s RPC endpoint. Most wallets allow you to add a custom RPC URL. Once configured, all transactions sent through that wallet are routed through the MEV protection service. Some wallets now offer MEV protection as a toggle in their settings, requiring no manual RPC configuration.
Defense Strategy 4: Order Splitting
Order splitting is a technique that breaks a large swap into multiple smaller swaps executed over time. The idea is that smaller individual swaps have less price impact, making them less attractive targets for sandwich attackers.
How Order Splitting Reduces Sandwich Risk
A sandwich attacker’s profit is proportional to the price impact of the victim’s trade. A large swap that moves the price by 5% is a much more attractive target than a small swap that moves the price by 0.1%. By splitting a large order into many small orders, you reduce the price impact of each individual transaction, which reduces the profit a sandwich attacker can extract from each one.
Additionally, if you spread your swaps across multiple blocks or time periods, it becomes harder for an attacker to predict and target your full order. The attacker would need to sandwich each individual small swap, and the gas costs of doing so may exceed the profit from each small sandwich.
Practical Implementation
Order splitting can be done manually by executing multiple smaller swaps over several blocks, or programmatically using tools like TWAP (Time-Weighted Average Price) bots. Some DEX aggregators offer built-in order splitting features that automatically break large swaps into smaller pieces.
The trade-off is that order splitting increases the total gas cost (you pay gas for each individual swap) and exposes you to price movement over the execution period. For very large trades, the reduction in sandwich risk typically outweighs the additional gas costs. For smaller trades, the gas overhead may not be worth it.
Defense Strategy 5: Time-Delayed Transactions
Time-delayed transactions involve submitting your swap with a delay, either by using a multi-step transaction flow or by submitting to a future block. The goal is to make it harder for bots to predict and target your transaction in real time.
How Time Delays Help
Most sandwich bots operate in real time, scanning the mempool and executing sandwiches within the same block or the next block. If your transaction is not immediately executable, or if its execution is conditional on some future event, real-time bots cannot easily target it.
Some protocols implement this through commit-reveal schemes, where you first commit an intent to swap and later reveal the details. Others use auction-based systems where your order is matched in a batch rather than executed immediately. These approaches introduce latency but significantly reduce sandwich risk.
Limitations
Time-delayed transactions are not suitable for all use cases. If you need immediate execution, the delay is unacceptable. Additionally, time delays expose you to price risk, as the market may move against you during the delay period. This technique is best suited for large institutional trades where execution quality matters more than speed.
Defense Strategy 6: Intent-Based Execution
Intent-based execution is the newest and potentially most powerful defense against sandwich attacks. Instead of submitting a specific transaction (swap X for Y at this exact pool with these exact parameters), you submit an intent: “I want to receive at least Z tokens for my X tokens, by any means.”
How Intent-Based Systems Prevent Sandwiches
In an intent-based system, your order is not submitted to the public mempool as a traditional transaction. Instead, it is submitted as a signed intent that is filled by competitive solvers. These solvers search for the best execution path across liquidity sources and submit the final transaction on your behalf.
Because the intent does not specify a particular execution path or pool, sandwich bots cannot predict how the order will be executed. The solver has flexibility to route the order through whichever path offers the best price, and the final transaction is submitted through private channels, not the public mempool.
Intent-based systems also often use batch auctions, where multiple orders are settled simultaneously at a uniform clearing price. In a batch auction, there is no sequential ordering of transactions that a sandwich attacker can exploit. All orders in the batch execute at the same price, eliminating the front-run/back-run pattern that sandwiches require.
Platforms Using Intent-Based Execution
Several platforms now use intent-based execution models, including UniswapX, CoW Swap, and 1inch Fusion. Each has its own auction mechanism and solver network, but the core principle is the same: the user signs an intent, and competitive solvers fill it. For a deeper understanding of how these systems work, see our guide on understanding DEX aggregator fees, which covers how surplus and execution quality work in these models.
Comparison of Defense Methods
| Defense Method | Effectiveness | Effort Required | Cost | Best For |
|---|---|---|---|---|
| Slippage tolerance | Low-Medium | Very low | Free (may cause reverts) | All trades (baseline) |
| Private mempools | High | Low | Free or low cost | All trades on supported chains |
| MEV-protecting RPCs | High | Low | Free or low cost | All trades on supported chains |
| Order splitting | Medium | Medium | Higher gas costs | Large trades |
| Time-delayed transactions | Medium | Medium-High | Latency cost | Institutional/large trades |
| Intent-based execution | Very High | Low-Medium | Varies by platform | All trades (where available) |
Practical Checklist for Avoiding Sandwich Attacks
Here is a practical checklist you can follow to minimize your exposure to sandwich attacks:
- Set appropriate slippage tolerance. Use the lowest setting that reliably executes for your token pair. For liquid pairs, 0.1-0.5%. For less liquid pairs, 1-3%.
- Use an MEV-protecting RPC. Configure your wallet to use a private relay or MEV-protecting RPC endpoint. This is the single highest-impact change you can make.
- Use a DEX aggregator with built-in MEV protection. Many aggregators now route through private mempools by default. Check whether your preferred platform does this.
- Consider intent-based platforms. If available on your chain, use platforms like UniswapX, CoW Swap, or 1inch Fusion, which use competitive solver auctions and batch settlement.
- Split large orders. For trades that represent a significant portion of a pool’s liquidity, break them into smaller pieces executed over multiple blocks.
- Avoid trading in low-liquidity pools. Sandwich attacks are most profitable in pools with shallow liquidity. Stick to well-established pools with deep liquidity.
- Monitor your execution. Use MEV detection tools to check whether your past transactions were sandwiched. This helps you identify which defenses are working.
Frequently Asked Questions
Can sandwich attacks happen on Layer 2 chains like Base?
Yes, sandwich attacks can happen on any chain with a public mempool and AMM-based DEXs. Layer 2 chains like Base, Arbitrum, and Optimism all have public mempools where MEV bots can monitor and front-run transactions. However, the private mempool infrastructure on Layer 2s is less mature than on Ethereum mainnet. Some Layer 2s have introduced their own MEV mitigation features, and intent-based platforms are increasingly available on these chains as well.
Is setting slippage to 0% enough to prevent sandwich attacks?
Setting slippage to 0% will cause most transactions to revert, including legitimate ones, because even normal market activity causes small price movements between quote and execution. A more practical approach is to set the lowest slippage that reliably executes, combined with private mempool submission. Slippage tolerance alone is a weak defense because sophisticated attackers can still profit within tight slippage bounds, especially on large trades.
Do MEV-protecting RPCs slow down my transactions?
MEV-protecting RPCs can add a small amount of latency, typically a few seconds, because your transaction must be routed through a private relay and picked up by a block builder. In practice, this delay is usually negligible and is far outweighed by the protection benefit. Some users report that MEV-protecting RPCs actually improve execution quality because the transaction is included in a well-constructed block rather than competing in the public mempool.
What is the difference between a private mempool and an intent-based system?
A private mempool hides your transaction from the public mempool but still executes it as a standard swap on a specific pool. An intent-based system goes further by not specifying the execution path at all. You sign an intent expressing what you want (e.g., at least X output tokens), and a solver determines the best way to fill it. Intent-based systems provide both mempool privacy and execution path flexibility, making them a stronger defense against sandwich attacks.
Are sandwich attacks illegal?
The legal status of sandwich attacks and other forms of MEV extraction is an active area of debate. Some legal scholars argue that front-running on public blockchains differs from traditional securities front-running because there is no fiduciary relationship and the mempool is public. Others argue that sandwich attacks constitute market manipulation. Regulatory bodies have not yet issued clear guidance specifically targeting MEV extraction. Regardless of the legal status, the practical reality is that sandwich attacks are common, and traders should take steps to protect themselves rather than relying on legal recourse.
Written by Jacob Cavazos
← Back to blog
