WWCWildWildCrypto
Menu

Market literacy / Updated 2026-08-27

The Invisible Cost of Every Swap: Slippage, Sandwich Bots, and the Setting That Decides How Much You Lose

A swap can fill worse than quoted for two very different reasons. Here is how slippage and sandwich attacks actually differ, why your slippage tolerance is a permission slip rather than a prediction, and what genuinely reduces the cost.

How this guide is checked

Official sources first, no wallet connection, no guaranteed returns.

Reviewed on 2026-08-27 by WildWildCrypto Safety Desk. Method: Human editorial review with official-source checks, affiliate-disclosure checks, and no-financial-advice checks.

Publisher: WildWildCrypto Editorial. Corrections go through the contact page. We do not ask for seed phrases or tell you what to buy.

sandwich attack slippage matters because A swap that quotes one number and delivers another feels like the interface lied to you, and the usual advice — raise your slippage tolerance until it goes through — makes the problem worse in a way nothing on screen explains.

This guide separates ordinary price impact from a deliberate sandwich attack, shows precisely what your slippage tolerance authorises, explains what a private transaction route does and does not protect, and sets out a routine that keeps ordinary swaps boring.

You will learn why an automated market maker moves the price against you by design, how a sandwich bot converts your own tolerance setting into its profit margin, what proportion of DeFi flow now bypasses the public mempool, and the five habits that reduce the cost more than any single tool.

Two different costs wearing the same name

When a swap fills worse than the screen quoted, people call it slippage regardless of what happened, and that conflation hides the only distinction that matters for defence. The first cost is structural and unavoidable. MetaMask's explainer defines slippage as the difference between expected execution price and actual execution price, and on a decentralised exchange the mechanism producing it is the pricing formula itself. An automated market maker prices trades against a shared pool using a constant-product relationship, so your own trade moves the price as it executes — the larger your order relative to the pool, the further it moves. The same explainer illustrates the curve: a small trade might cost around 0.1% in price impact while a trade ten times larger against the same pool costs around 1%. Nobody is doing that to you. It is arithmetic, and it is the price of trading against a pool rather than an order book.

The second cost is somebody deliberately taking money from you, and it only exists because your intention became visible before it executed. On a public blockchain, a pending transaction sits in a shared waiting area — the mempool — where anyone can read it. Ethereum.org defines the resulting practice: maximal extractable value is the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block. Independent participants called searchers run bots that watch for profitable opportunities and pay validators for the transaction ordering they need. The distinction to carry is simple. Price impact is what your own trade does to the pool. A sandwich attack is what someone else's trades do to you, using advance knowledge of yours.

Checklist

  • Slippage: the gap between the expected and actual execution price.
  • On an AMM, your own trade moves the price by design.
  • Price impact scales with trade size relative to pool depth.
  • MetaMask's illustration: roughly 0.1% on a small trade, roughly 1% at ten times the size.
  • MEV: value extracted by including, excluding and reordering transactions.
  • Pending transactions are publicly readable in the mempool before they execute.
  • Price impact is arithmetic; a sandwich is a deliberate act using your visible intent.

How a sandwich actually works

The mechanics are worth understanding once, because they explain why every proposed fix either hides your transaction or shrinks the prize. A bot watching the mempool sees your pending swap: which pool, which direction, how much, and — critically — the maximum adverse price you have already agreed to accept. It then places its own buy immediately before yours, which pushes the pool price up. Your swap executes next, at that worse price, still within the tolerance you authorised. The bot then sells immediately after, into the price your trade just pushed up further, and pockets the difference. Ethereum.org describes the pattern as searchers watching the mempool for large trades, then buying cheaply ahead and selling into the inflated price afterwards. Your loss is their revenue; the two are the same number.

Two consequences follow, and both are counter-intuitive on first encounter. The first is that the attack requires no privileged access, no exploit and no compromise of your wallet — it uses only information you broadcast and permission you granted. There is nothing to patch, which is why the entire defensive conversation is about visibility and settings rather than security software. The second is that the profitability of sandwiching you is set almost entirely by two things you control: how far the price can be pushed before your transaction reverts, which is your slippage tolerance, and how thin the pool is, which is your choice of what to trade. A large swap into a thin pool with a generous tolerance is the ideal target, and each of those three factors is a decision made in the seconds before you click confirm.

Checklist

  • The bot reads your pending swap, including your maximum acceptable price.
  • It buys ahead of you, pushing the pool price up.
  • Your swap fills at the worse price, inside the tolerance you authorised.
  • It sells immediately after, capturing the difference.
  • No exploit or wallet compromise is involved — only public information and your permission.
  • Profitability depends on your tolerance, your size, and the pool's depth.
  • Large swap plus thin pool plus generous tolerance is the ideal target.

Slippage tolerance is a permission slip, not a prediction

This is the single most useful correction in the whole subject. Interfaces present slippage tolerance as a protective setting, and people reason about it as an estimate of how much the price might move. It is neither. It is a ceiling on how much worse than quoted a fill you have pre-agreed to accept, enforced by the transaction reverting if the ceiling is breached. Set it to 5% and you have not predicted 5% of movement; you have signed a statement that you will accept anything down to 5% worse — and a sandwich bot's maximum profit is bounded by precisely that figure.

Which makes the standard troubleshooting advice actively dangerous. A swap fails, the interface suggests raising the tolerance, the user raises it, and the swap goes through. What actually happened is that the user removed the guard that had just protected them. MetaMask's guidance on swaps warns that if slippage tolerance was set high enough that the trade executed at a bad price, the blockchain transaction is final and irreversible, and its explainer recommends a moderate band — noting that an extremely tight setting such as 0.1% causes many swaps to fail in volatile conditions while roughly 0.5% to 1% is usually a reasonable balance, with 1% to 2% typical defaults. The right reading of a failing swap is diagnostic rather than obstructive: the transaction is telling you the market is moving faster than your tolerance, or the pool is too thin for your size. The correct responses are to wait, to reduce the trade size, or to split it — not to widen the band. And the failure mode is asymmetric in a way that deserves emphasis: a swap that fails costs you a little gas and nothing else, while a swap that fills at a terrible price is irreversible.

Checklist

  • Tolerance is a ceiling on acceptable loss, not a forecast of movement.
  • A sandwich bot's profit is bounded by your tolerance setting.
  • Raising tolerance to force a swap through removes the guard that just worked.
  • MetaMask: a bad fill within your tolerance is final and irreversible.
  • Roughly 0.5% to 1% is described as a reasonable balance; 1% to 2% are typical defaults.
  • Very tight settings such as 0.1% cause frequent failures in volatile conditions.
  • A failed swap is a diagnosis: too fast, too large, or too thin.
  • Respond by waiting, shrinking, or splitting — not by widening.

Private order flow: what a protected route does, and what it does not

If the attack depends on seeing your transaction before it executes, the structural fix is to stop broadcasting it. That is what a private transaction route does. Flashbots Protect describes itself as a cheaper and safer way to transact on Ethereum, routing transactions to a private Flashbots mempool where they will be hidden from frontrunning and sandwich bots rather than into the public one. Its documentation lists further consequences that matter to ordinary users: transactions are only included in the block if they do not revert, so users do not pay fees for failed transactions, and a transaction that generates MEV can earn an MEV refund. It also states that the RPC does not track user information such as IP or location, and that no user information is stored or logged.

This is no longer a niche practice, which is the part most guides miss. Research from CoW DAO — a benchmark study of private MEV protection RPCs by Paul Janicot and Alex Vinyas, published in May 2025 — reports roughly 80% usage of private RPCs across DeFi interactions, with these systems running order flow auctions that return part of the extracted value to users. The transaction supply chain has already shifted underneath the average user, and many people are protected by defaults they never chose. Two honest caveats. First, private routing addresses visibility, not price impact: it can stop a bot from front-running you, but nothing prevents your own large trade from moving a thin pool, because that is the pricing formula doing its job. Second, the study's own framing is that not all such systems produce the same outcomes — design choices differ, and the protection is a property of the specific route rather than of the category. Practically: check which RPC your wallet uses, prefer one that offers protection, and understand that it changes who can see your transaction rather than what your trade does to the market.

Checklist

  • Private routes hide the transaction from the public mempool.
  • Flashbots Protect: hidden from frontrunning and sandwich bots.
  • Only non-reverting transactions are included; no fee for failed transactions.
  • MEV generated by your transaction can be partly refunded.
  • CoW DAO research: roughly 80% of DeFi interactions now use private RPCs.
  • Private routing does not reduce your own trade's price impact.
  • Outcomes vary by provider — protection is route-specific, not automatic.
  • Check which RPC endpoint your wallet is actually using.

The routine that keeps ordinary swaps boring

None of this requires expertise to act on, and the habits compound. Before a swap, check the pool's depth relative to your size — the price impact figure the interface shows you before confirmation is the honest preview, and a number that surprises you is telling you the pool is too thin for this trade rather than that the quote is wrong. Split large trades into smaller pieces rather than moving everything at once, which reduces both your own price impact and the prize any bot is competing for. Keep tolerance in the modest band and treat every upward adjustment as a decision requiring a reason, not a reflex when something fails.

Two further habits do more work than they appear to. Route through a protected RPC where your wallet supports it, so that the ordinary case never enters the public mempool at all. And weight the choice of what you trade as heavily as the mechanics of how: the extreme losses in this category do not happen on deep, liquid pairs, they happen on newly launched tokens with almost no liquidity, where a modest order moves the price enormously and a generous tolerance is often required just to execute. That combination — thin pool, urgent trade, wide tolerance — is where an ordinary swap becomes a large, irreversible loss, and recognising it is worth more than any setting. Finally, keep the two costs mentally separate when you review a fill. If the loss tracks the price impact the interface predicted, you paid the pool. If it is much larger, and the pool traded oddly either side of you, you were sandwiched. The first is a reason to trade smaller; the second is a reason to change your route.

Checklist

  • Read the predicted price impact before confirming; treat a surprise as a warning.
  • Split large trades rather than moving everything in one transaction.
  • Keep slippage tolerance modest and justify every increase.
  • Never raise tolerance simply because a swap failed.
  • Use a protected RPC route where your wallet supports one.
  • Thin, newly launched pools are where the extreme losses happen.
  • Thin pool plus urgency plus wide tolerance is the dangerous combination.
  • Review fills: predicted impact means you paid the pool, far worse means you were sandwiched.

Authority sources used

Outbound links are included for verification and entity authority, not decoration.

FAQ

What is the difference between slippage and a sandwich attack?

Slippage is the gap between the price you expected and the price you got, and on a decentralised exchange most of it is structural. An automated market maker prices your trade against a shared pool, so the trade itself moves the price as it executes — the bigger your order relative to the pool, the more it moves. MetaMask's explainer illustrates the curve with a small trade costing around 0.1% and a trade ten times larger against the same pool costing around 1%. Nobody is doing that to you; it is the pricing formula. A sandwich attack is a deliberate act by a third party that exploits the fact that your pending transaction is publicly visible before it executes. A bot reads your swap in the mempool, buys ahead of you to push the price up, lets your trade fill at the worse price, then sells into the move. Ethereum.org describes this as searchers watching the mempool for large trades and buying cheaply ahead before selling at the inflated price. The practical difference: price impact is reduced by trading smaller or in deeper pools, while sandwiching is prevented by not broadcasting your intention in the first place.

My swap keeps failing. Should I raise the slippage tolerance?

Usually not, and this is the most common way people turn a minor inconvenience into a real loss. Slippage tolerance is not an estimate of how much the price might move — it is the maximum worse-than-quoted fill you have already agreed to accept, and the transaction reverts rather than filling beyond it. When a swap fails, that guard did its job: it is telling you the market is moving faster than your tolerance, or the pool is too thin for the size you are trying to move. Raising the number does not make the fill better; it authorises a worse one, and it simultaneously raises the ceiling on what a sandwich bot can extract, since its profit is bounded by exactly that figure. The asymmetry is what settles it. MetaMask warns that if tolerance was set high enough for the trade to execute at a bad price, the blockchain transaction is final and irreversible — whereas a failed swap costs you some gas and nothing more. Better responses are to wait for calmer conditions, reduce the size, split the trade, or reconsider whether a pool this thin should be traded at this size at all.

What slippage tolerance should I actually use?

There is no universal number because the right setting depends on how volatile the pair is and how deep the pool is, but the sensible band is narrower than most people assume. MetaMask's guidance describes roughly 0.5% to 1% as usually a reasonable balance, notes that typical interface defaults sit around 1% to 2%, and warns that an extremely tight setting such as 0.1% will cause many swaps to fail during volatile conditions. The useful mental model is that you are choosing between two failure modes: too tight and your transactions revert repeatedly, costing gas and time; too loose and you have pre-authorised a bad fill that cannot be undone. For deep, liquid pairs, a tight setting is appropriate and will rarely cause problems. For thin or newly launched pools, the tolerance required to execute at all is often a signal that the trade is unwise at that size rather than a setting to be dialled up. Treat any increase above your normal band as a decision that needs a reason — and note that if you are raising it repeatedly for the same trade, the trade is the problem, not the setting.

Does a private RPC or MEV protection actually work?

For the specific problem it addresses, yes — and it is now the majority behaviour rather than a niche technique. A sandwich attack depends entirely on a bot seeing your transaction before it executes, so routing it away from the public mempool removes the precondition. Flashbots Protect describes sending transactions to a private Flashbots mempool where they will be hidden from frontrunning and sandwich bots, and adds two useful properties: transactions are only included if they do not revert, so users do not pay fees for failed transactions, and a transaction that generates MEV can earn a refund. Its documentation also states that the RPC does not track user information such as IP or location and stores no user information. On scale, a CoW DAO benchmark study of private MEV protection RPCs by Janicot and Vinyas reports roughly 80% of DeFi interactions now flowing through private RPCs. Two caveats keep this honest. Private routing does nothing about the price impact your own trade has on a thin pool, because that is the pricing formula rather than an attack. And the same study observes that different systems produce different outcomes, so the protection belongs to the specific route you use rather than to the idea in general.

Does this affect me if I only buy on a centralised exchange?

Sandwich attacks as described here are specific to public blockchain transactions, so a trade executed inside a centralised exchange's own order book is not exposed to mempool-watching bots — there is no public pending transaction for them to read. Ordinary slippage still applies, but through a different mechanism: on an order book, a large order fills across successive price levels, so the average price worsens as it consumes depth, and MetaMask's explainer gives the example of a large order averaging a fraction of a percent worse than the top-of-book price. Two things do carry over. First, the moment you move funds on-chain — withdrawing to a wallet, bridging, or swapping in a decentralised venue — you re-enter the environment where transactions are publicly visible before execution. Second, the underlying discipline is identical in both venues: size relative to available liquidity determines your cost, and trading in thin conditions is expensive regardless of the venue's architecture. If you only ever buy and hold on a custodial exchange, this specific attack is not your risk — but the custodial risks covered elsewhere on this site are, and they are larger.

How do I tell whether I was sandwiched or just paid normal price impact?

Compare the outcome against the prediction the interface gave you before you confirmed. Every reputable swap interface shows an expected price impact figure derived from the pool's depth and your trade size, and that number is an honest forecast of the structural cost. If your fill lands close to it, you paid the pool, and the remedy is to trade smaller, trade in a deeper pool, or split the order. If your fill is dramatically worse than predicted while sitting just inside your slippage tolerance, that pattern is characteristic of a sandwich, because a bot's optimal strategy is to move you as close to your authorised ceiling as it can without triggering a revert. You can corroborate it by looking at the pool's activity immediately before and after your transaction in the same block: a buy in the same direction right before yours and a sell right after is the signature. Either way the transaction is final, so the value of the diagnosis is forward-looking. Paying the pool tells you to change your sizing; being sandwiched tells you to change your route, and to check whether your tolerance was wider than it needed to be.