Of everything about slippage, this is the part that changes behaviour: on a public blockchain, your slippage tolerance is not just a personal risk preference. It is a number visible to anyone watching, and it defines precisely how much can be taken from your trade. Background on the setting itself is in the slippage tolerance setting.
What a sandwich attack actually is
Transactions submitted to a public blockchain wait in a visible queue before being confirmed. During that wait, anyone — including automated bots scanning continuously — can see what you are about to do.
A sandwich attack places one transaction immediately before yours and one immediately after. The bot buys first, which pushes the price up. Your buy then executes into that raised price, so you receive fewer tokens than you would have. The bot then sells into the price your own trade just supported, and keeps the difference. Your trade is the filling; the bot’s two transactions are the bread.
How your tolerance sets the attacker’s budget
The attack only works if your transaction still succeeds after the price has been pushed against you. If the bot moves the price too far, your trade reverts on slippage — and the bot has spent fees for nothing.
This makes your tolerance the binding constraint on the whole operation. It states publicly, in advance, exactly how far the price can be moved against you while your trade remains valid. A tight tolerance leaves a narrow margin that may not cover the bot’s own costs, making the attempt not worth making. A wide one leaves a generous margin. Setting 15% because a trade kept failing does not merely accept ordinary market noise up to 15% — it advertises that up to roughly 15% can be extracted with your transaction still going through.

Which trades are most exposed
Exposure rises with three things: a wide tolerance, a large trade size (a bigger prize justifies the bot’s costs), and thin liquidity (a shallow pool is cheaper to move). A small trade in a deep pool with a tight tolerance is an unattractive target on all three counts. A large trade in a shallow pool with a wide tolerance is attractive on all three — and that combination arises naturally when someone is trying to buy a newly launched, thinly traded token quickly, which is exactly the scenario where the “just raise the tolerance” instinct is strongest.
What reduces the exposure
- Keep tolerance as tight as will still execute. This directly shrinks the margin available, which is the most effective single change.
- Prefer deeper markets. Moving a deep pool costs the bot more, which narrows the set of trades worth attacking.
- Split large orders. Smaller pieces are individually less attractive targets than one large, visible order.
- Use private transaction routing where your interface supports it. A trade that never appears in the public queue cannot be seen and front-run in this way.
- Treat repeated failures as information. A trade that will not execute within a sane band is telling you about the market’s depth, not asking you to widen the band.
None of these makes a trade impossible to attack; together they make it a poor target. Concrete figures for how much different tolerance settings permit are on the worked examples page.
Frequently asked questions
Does a sandwich attack steal from my wallet?
No. Nothing is taken from your wallet directly u2014 your trade executes exactly as you authorised it, just at a worse price than it would have received without the surrounding transactions.
Are centralized exchanges vulnerable to sandwich attacks?
Not in this form. The attack depends on transactions being publicly visible before confirmation, which is a property of on-chain trading rather than a platform's internal order matching.
Would a very low tolerance stop sandwich attacks entirely?
It does not stop them outright, but it shrinks the margin available to the point where many attempts are not worth the attacker's own transaction costs, which removes most of the incentive.
