To learn how to avoid sandwich attacks, you set slippage to the smallest number that still executes, send the swap through a private transaction endpoint, split or route large orders, stay away from the busiest minutes of the market and check what you actually received. A sandwich is the simplest extractive trade there is: someone sees your swap waiting to be included in a block, buys the same asset immediately before it and sells immediately after.
Your trade pushes the price up, their sale takes the difference, and you receive fewer tokens than the interface quoted. It is ordinary transaction ordering rather than a hack, so the defence is procedural, and most measures cost nothing.
What you need before you start
- A wallet that offers a protected or private transaction setting on the chain you trade on.
- A quote screen you can read: the minimum received and the price impact for your full size.
- A rough idea of the pool depth relative to your order, from the pool page.
- Enough of the native gas asset for failed attempts, not only for the trade itself.
- A block explorer open in another tab to check the result afterwards.
How to avoid sandwich attacks step by step
1. Judge whether your trade is worth sandwiching
The attack only pays when your trade moves the price enough to cover the attacker’s own gas and fees. That makes the target profile specific: large trades relative to pool depth, generous slippage settings, and thin pools where a modest order shifts the curve. If your order is a noticeable share of the liquidity, assume you are visible and worth taking.
Check: the price impact on the quote. Read a price impact warning as a statement about pool depth rather than a formality, because that number is what makes your trade worth taking.
2. Set slippage to the smallest number that still executes
Slippage tolerance is a permission. It states the worst price you will accept, and an attacker can extract exactly up to that limit and no further. A default of one or two percent on a volatile token is an invitation, and raising it to fifty percent to force a stuck trade through is the most expensive click in decentralised trading. Start low, let the transaction fail, and raise in small increments.
Cost: a failed transaction costs gas. A filled one at maximum tolerance costs the whole tolerance.
3. Read the minimum received and the deadline
Before signing, take the two numbers that matter out of the quote: the minimum received and the price impact. Minimum received is what the transaction will enforce, and it is the figure to compare against what actually arrives. Then look at the wallet’s review screen. A deadline set far ahead leaves the transaction sitting in the mempool where it can be executed later under conditions you never saw. Shorter deadlines fail more often and cost less when they do.
4. Split the order
Two or three smaller swaps in sequence usually beat one large one in a thin pool. Each individual trade moves the price less, so each is less profitable to surround, and the pool has time to be arbitraged back toward fair value between them.
Cost: extra gas. Compare that against the price impact your full size shows in the quote, because on a shallow pool the impact number is frequently several times the gas.
5. Route through an aggregator
An aggregator splits one order across several pools and venues. A sandwich then has to be constructed against multiple pools at once, which raises the attacker’s cost and lowers their edge, sometimes past the point of being worth it. This is a side benefit rather than a defence in itself, and it comes with its own routing considerations, covered in our guide to DEX aggregators.
6. Use a private transaction endpoint
This is the actual fix. Instead of broadcasting to the public mempool where anyone can read your pending trade, you submit it directly to block builders. The trade is not visible until it is already included, so there is nothing to front-run. Most major wallets offer it as a toggle described as protected or private transactions, and on chains where it is available it removes the attack rather than pricing it down.
Two limits are worth knowing. Private routing can mean slower inclusion during congestion, and it depends on the builders you are submitting to, which is a trust assumption of its own, just a much narrower one than broadcasting your intent to the entire network.
Time: turning it on takes under a minute and applies to every subsequent trade.
Check: after switching, send one small trade and confirm in the explorer that it was included the way you expect, because a misconfigured custom network can fall back to the public route without saying so. The setting is per network and per profile, so a second browser profile or a phone will broadcast publicly while the desktop stays protected. Recheck after every wallet update.
7. Avoid the moments when everyone is trading
Launches, token release dates, listing announcements and sharp market moves are when extraction is most concentrated, because pools are volatile and slippage settings across the market are loose. If the trade does not have to happen in the first minutes of an event, it will almost always execute better afterwards, on quieter blocks and a rebalanced pool.
8. Check what you actually received
After the swap, compare the tokens received against the quote you accepted. A gap close to your full slippage tolerance is the signature of a sandwich, and a small gap is ordinary price movement between quote and inclusion. Open the transaction in a block explorer and look at its position within the block. A buy of the same pair immediately before yours and a sell immediately after, from the same address, is the attack written out in full.
Protection measures compared
| Measure | What it changes | Cost | Effect on the attack |
|---|---|---|---|
| Tight slippage | Caps what can be extracted | Gas on failed attempts | Prices it down |
| Short deadline | Stops a stale transaction filling later | More failures | Prices it down |
| Split order | Each trade moves the price less | Extra gas per swap | Prices it down |
| Aggregator routing | Spreads the order across pools | Routing considerations of its own | Raises the attacker’s cost |
| Private endpoint | Hides the trade until included | Slower inclusion in congestion, builder trust | Removes it where available |
| Quiet timing | Avoids loose market-wide slippage | Waiting | Less concentrated extraction |
| Resting order | Fills at a stated price, off the public path | May not fill at all | Removes the ordering problem |
| Small test trade | Confirms endpoint and routing | Gas and a fee | Shows the route before size |
Special cases: teams, bots, bridges and large orders
How to avoid sandwich attacks as a team
A treasury or an operations desk makes exactly the trades worth surrounding: large, scheduled and frequently announced in advance. Write the procedure down rather than relying on whoever holds the keys to remember it. It needs the endpoint to use, the maximum slippage anyone may set without a second approval, the largest size permitted in a single transaction, and the name of the person who checks the result afterwards.
Keep the intention private until execution. A post saying the treasury will convert a sum this week tells everyone watching what to wait for, and a governance vote with a public execution date does the same thing more precisely. Where timing must be public, split and vary the execution.
Automated trades and repeated patterns
Scripts are the easiest targets because they are predictable: the same size, the same pair, the same interval. Randomise the size within a band and the timing within a window, and route through a protected endpoint by default rather than as an option the script can fall back from. A fallback that quietly uses the public mempool whenever the protected endpoint is slow removes the protection exactly when it is needed.
Log the quote and the result for every automated trade, and alert on the gap rather than reviewing it at the end of the month. The alert is the difference between one bad fill and a hundred of them.
Cross-chain and bridged swaps
A bridge transfer that ends in a swap on the destination chain has two execution points, and the second happens while you are not watching. Check whether the bridge swaps on arrival, what slippage it applies, and whether that setting is yours to choose. Where possible, bridge the asset and swap separately, at the cost of time and a second fee.
Orders too large to split
Some trades cannot be broken up: a liquidation deadline, a contract call that has to happen in one transaction, or a size that would take days to work through a thin pool. When the size is fixed, the defence moves to routing and venue. Check whether the asset has depth on a centralised venue or through a desk. If the trade has to happen on-chain in one piece, send it through a protected endpoint, accept slower inclusion, and set the minimum received at a level you would genuinely accept rather than one chosen to guarantee execution.
Orders that wait instead of executing
Where the interface offers an order that fills at a stated price rather than at the next block, use it for anything that is not urgent. An order held off the public path and filled by a counterparty at an agreed price removes the ordering problem, and the trade-off is that it may not fill at all. Urgent trades belong in a protected swap with a tight tolerance; the rest can wait in a resting order.
After the trade: working out what a fill cost
Compare the tokens received against the quote and separate the causes. Gas is visible on the transaction. Ordinary movement between quote and inclusion is small and goes in either direction. A shortfall landing close to the slippage limit, in the direction that favours whoever traded around you, is the pattern worth recording. Do the arithmetic in the asset you paid with, since a moving display price hides small losses. A desk that loses roughly the same fraction every time is being told that its slippage setting is the problem rather than the market.
After a bad fill there is no recourse and nobody to contact, so treat it as a configuration review: which endpoint the trade actually used, what the slippage was set to, whether the size suited the pool at that moment, and whether it went out during a burst of activity. Resist the instinct to trade back immediately. The price on screen is the one the attack left behind, and a reversal into that state is a second opportunity for the same actor. Wait for arbitrage to restore the curve, which in an active pool takes minutes, and requote.
Common mistakes
- Raising slippage very high to force a stuck trade through instead of letting it fail and requoting.
- Protecting the desktop wallet and trading from a phone or second browser profile that still broadcasts publicly.
- Granting an unlimited allowance instead of the exact amount, and combining approval and swap so a failure forces both to be redone.
- Sending a second transaction for a stuck swap instead of replacing it with a higher fee, so both can execute.
- Announcing a treasury conversion or running a bot with the same size, pair and interval every time.
How long it takes and what it costs
Turning on a protected endpoint takes under a minute, and the full routine of checking the quote, setting slippage and verifying the result fits inside about ten minutes per trade. The costs are gas on failed attempts, extra gas for split orders, gas and a fee for a small test trade, a second fee when you bridge and swap separately, and slower inclusion during congestion on private routing.
Budget for failures. Tight slippage means transactions that revert, and an address with no gas margin leaves a half-completed sequence: an approval granted and no swap. Fund the address with more than the trade needs. Keep any test trade small enough to be uninteresting, because on a thin pool a larger test is itself worth surrounding. A trade that fails and repeats is cheaper than a filled trade at a tolerance picked to avoid failing.
What none of this prevents
Sandwiching is distinct from a token whose contract blocks selling, from a pool whose liquidity is withdrawn after you buy, and from ordinary price impact in a shallow market. Those need different checks, covered in how to buy altcoins on a DEX. Private routing also does not exist on every chain, and on chains with a single sequencer the ordering risk moves to the sequencer rather than disappearing.
For teams launching a token, this is a first-impression problem: the earliest buyers get the worst execution, and they say so publicly. Pool depth at launch and the messaging around it are covered on our crypto traffic acquisition page.
Frequently Asked Questions
What is a sandwich attack in simple terms?
A sandwich attack is transaction ordering around your swap. Someone sees your pending swap in the public mempool, buys the same asset immediately before it and sells immediately after. Your trade pushes the price up and their sale captures the difference, so you receive fewer tokens than the interface quoted.
Does lowering slippage stop sandwich attacks?
Lowering slippage caps sandwich attacks but does not stop them. Slippage tolerance sets the maximum an attacker can extract, so a tight setting makes most sandwiches unprofitable. It does not make the trade invisible, which is what private routing through a protected endpoint does.
Are private transactions worth using for ordinary trades?
Yes, on chains where wallets offer them. Enabling protected or private transactions takes under a minute and applies to every trade afterwards. The trade-offs are slower inclusion during congestion and reliance on the builders you submit to, a narrower trust assumption than broadcasting to the whole network.
How do I know whether I was sandwiched?
Compare the tokens you received against the quote you accepted, then open the transaction in a block explorer. A gap close to your full slippage tolerance, plus a buy of the same pair immediately before yours and a sell immediately after from one address, is the attack.
Is a sandwich the same as a token that cannot be sold?
No. A sandwich is transaction ordering around a legitimate trade. A token that blocks selling is a contract restriction, and liquidity being pulled after you buy is a third, separate problem. Each one needs its own checks before you trade.