How to Avoid Sandwich Attacks: 7 Practical Defences

To avoid sandwich attacks, tighten your slippage tolerance, keep trades small relative to pool depth, send transactions through a private or MEV-protected route, and avoid illiquid tokens where possible. No single step is a guarantee, but combined they remove most of what a sandwich bot needs: visibility and headroom.

1. Set slippage deliberately

Slippage tolerance is the maximum price movement you will accept. A bot can only extract up to that limit before your trade reverts. Many interfaces default to a generous value for volatile tokens. Reduce it for liquid pairs; for example, a stablecoin swap rarely needs more than a small fraction of a percent. If a trade fails at a tight setting, raise it a little rather than jumping to a large number. Details are in slippage tolerance explained.

Key takeaway: every extra percent of tolerance is room a bot can use. Match the setting to the pair, not to habit.

2. Trade at the right size

Price impact grows with the share of a pool your trade takes. A large order in a shallow pool moves the price a lot, creating an obvious target. Options:

• Split a large trade into several smaller ones over time, accepting some timing risk.
• Use an aggregator that routes across multiple pools to reduce impact.
• Prefer deep pools for the pair you want.

3. Use private routing

If your transaction never appears in the public mempool, a bot cannot see it there. Services such as Flashbots Protect and MEV Blocker offer RPC endpoints that send transactions privately to builders. Flashbots’ documentation describes protection against frontrunning and sandwich attacks as a main purpose. Adding such an RPC to your wallet is usually a configuration change. Check the service’s current documentation for what it covers, what chains it supports and whether it may refund or share any MEV.

4. Choose venues and order types carefully

Some trading venues use batch auctions or intent-based designs where orders settle together at a uniform price, which limits the ordering advantage a sandwich needs. Limit orders handled off-chain until execution also avoid public exposure. These designs have their own trade-offs, such as slower fills or reliance on solvers, so read how a venue works before assuming protection.

5. Check the pool and token

Thin pools and new tokens attract sandwiching and carry other risks. Look at liquidity depth, the pool’s age, and whether the token has unusual transfer rules. If a pool is tiny, even a small trade can have large impact.

6. Read the quote and the warnings

Reputable interfaces show price impact and estimated minimum received. If the minimum looks far worse than the quote, pause. Some wallets warn about high slippage or risky tokens; take those warnings seriously, and verify current features in the wallet’s own documentation because they change.

7. Verify afterwards

Learn to inspect your transactions on a block explorer, as in how to check if you were sandwiched. Over time you will see which routes and settings cost you least.

Quick comparison of defences

Defence	Effort	Main benefit	Main drawback
Tight slippage	Low	Caps extractable amount	More reverts in volatile markets
Smaller trade size	Medium	Lower price impact	More transactions and fees
Private RPC	Low	Hides trade from public mempool	Depends on service coverage
Batch or intent venues	Medium	Uniform pricing	Slower or different fill model
Deep pools only	Low	Less impact	Fewer token choices

What this means for bot operators

The more users adopt these habits, the fewer exposed trades exist. That is one reason the economics in are sandwich bots profitable keep shifting. If you operate a bot, expect the supply of easy targets to decline. Vendors such as CryptoMEV Bot say their software looks for large swaps with high slippage tolerance, per their sandwich bot page, which tells you exactly which trades are most exposed.

A routine you can reuse

Before each swap: check pool depth, set slippage to the lowest value that works, use a protected RPC if available, review the minimum received, and confirm the token contract. It takes under a minute once habitual.

Habits for specific situations

Swapping a new token. Newly launched tokens are the classic hunting ground. Pools are shallow, tolerance often has to be wide, and bots watch for launches. If you trade them at all, use small amounts, protected routing and expect worse fills than quotes suggest.

Moving a large position. Do not use a single swap. Consider splitting over time, using an aggregator and, where available, a venue with batch settlement. Accept that you may trade off a little timing risk for lower extraction.

Using a mobile wallet. Many mobile wallets let you set the RPC or enable built-in protection. Look in the settings for a network or transaction-protection option. If none exists, the other defences matter more.

Bridging or swapping across chains. Each hop is another swap exposed to ordering games. Prefer routes with fewer hops and deeper pools.

How to read a protection claim

Not every wallet feature labelled “protection” works the same way. Ask: does it keep the transaction out of the public mempool, does it limit price impact, or does it only warn you? A warning does not stop a bot. Private routing can; so can a venue that settles orders in batches. Read the provider’s documentation, since coverage varies by chain, and recheck from time to time because features change.

Why defending matters beyond your own wallet

Each protected swap removes a target. Over time, that reduces the incentive to run sandwich strategies, which is why the economics for operators are becoming harder. It also changes the legal and ethical conversation, covered in is sandwich trading legal. If you are on the operator side and want to see how the vendor frames what it targets, the CryptoMEV Bot sandwich page is explicit about the kind of swap it looks for, and its broader MEV explainer describes sandwich attacks as raising the victim’s slippage.

This article is educational and not financial advice. Verify current features of any service before relying on it.