A sandwich attack is the most common way ordinary DEX users lose money to MEV. It does not require hacking anything. A bot simply places one trade right before yours and one right after, inside the same block, and keeps the price difference your swap creates. This guide explains exactly how sandwich attacks work on Polygon, why your slippage setting matters so much, and what you can do to reduce the risk.
In short: a sandwich attacker sees your pending swap in the public mempool, buys the same token just before you, lets your swap execute at the higher price, then sells right after. Your slippage tolerance caps how much you can lose. Private submission keeps the swap out of the public mempool, and tight slippage limits the damage if anything does go wrong.
How a sandwich attack works
Most Polygon DEXs use automated market makers (AMMs). The price in a pool depends on the ratio of the two tokens it holds, so every trade moves the price: buying a token makes it more expensive for the next buyer.
A sandwich exploits that in three steps:
- Front-run. The bot sees your pending swap, say USDC for POL, and buys POL first. The pool price of POL goes up.
- Your swap. Your transaction executes against the moved price, so you receive less POL than you would have.
- Back-run. The bot sells the POL it bought, now at the higher price your swap pushed up, and keeps the profit.
All three transactions land in the same block, in that order. To get in front of you, the bot typically offers a higher priority fee; its closing trade follows yours.
Why slippage tolerance is the attacker’s budget
When you swap, you set a slippage tolerance. The DEX router turns that into a minimum amount you are willing to receive. If the price moves so much that you would get less, the swap reverts instead.
That safety net is also a ceiling for the attacker. The bot can push the price only so far that your swap still clears your minimum. Any further and your transaction fails, which ruins the sandwich.
Here is a simplified example. The numbers are illustrative and ignore pool fees and gas.
| Item | Amount |
|---|---|
| Quote for your 10,000 USDC swap | 39,604 POL |
| Slippage tolerance | 1% |
| Minimum you accept | 39,208 POL |
| Most you can lose to price movement | about 396 POL |
With a 1% tolerance, a sandwich can cost you at most about 1% of the expected output. With 5%, it could cost up to five times as much. The tolerance you choose is the budget you hand to anyone who can see your transaction before it executes.
Why Polygon swaps get sandwiched
Two properties make sandwiching practical on any EVM chain with a public mempool, including Polygon PoS:
- Pending swaps are visible. Transactions sent through a public RPC are gossiped to the network before they are included, and bots decode them automatically.
- Attacks are cheap to attempt. Low transaction fees mean the cost of the two extra trades is small, so even modest swaps can be worth attacking.
Pools with thin liquidity are more exposed, because a given trade moves the price more.
How to tell if you were sandwiched
Open your swap on Polygonscan and look at the block it was included in:
- Find the transaction immediately before yours. Does it swap in the same pool, in the same direction as you?
- Find the transaction immediately after yours. Does it come from the same address and swap back in the opposite direction?
- Compare what you received with your quote. Did you get close to your minimum?
If the same address bought right before you and sold right after you in the same pool, you were very likely sandwiched.
How to reduce sandwich attack risk on Polygon
Submit swaps privately
A sandwich starts with seeing your pending swap. Sending the signed transaction through a private RPC endpoint, which routes it toward block production instead of the public mempool, takes away that view. This is the main purpose of Polygon sandwich attack protection services, including Hyperstrate. It reduces exposure to mempool-watching bots; it does not control what happens after inclusion. More in MEV protection on Polygon.
Set slippage deliberately
- Use the smallest tolerance that lets your trade go through in normal conditions. For liquid pairs this is often well under 1%.
- Avoid very high “auto” tolerances on volatile or illiquid tokens.
- Accept that a tight tolerance sometimes means a reverted transaction. A small gas cost is usually better than a large loss.
Use a deadline
A deadline makes the swap revert if it is not included in time, so it cannot execute much later at a worse price.
Reduce your price impact
- Split large trades into smaller ones.
- Prefer pools and routes with deeper liquidity; aggregators can help.
- Consider limit orders or request-for-quote venues for larger amounts.
For wallets, DEXs and bots
If you build products, you can protect your users by default:
- Offer a private sending mode, or submit user swaps through a private endpoint.
- Default to sensible slippage and deadlines, and warn when users choose high tolerances.
- Monitor executions for sandwich patterns and adjust routing.
Frequently asked questions
Can a sandwich attack take more than my slippage tolerance?
Not from price movement on that swap: if the price moves beyond your minimum, the swap reverts. You still pay gas for a reverted transaction, so very tight tolerances on volatile pairs can mean more failed swaps.
Does private submission stop sandwich attacks?
It removes the main ingredient, visibility in the public mempool. It cannot rule out every party that handles the transaction before inclusion, so keep slippage tight as well.
Are small swaps safe from sandwiching?
Not necessarily. On low-fee networks like Polygon, the cost of attacking is small, so modest swaps with loose slippage can still be profitable targets.
Conclusion
A sandwich attack needs two things: a view of your pending swap and room to move the price. Private submission takes away the view; tight slippage, deadlines and sensible trade sizes take away the room. Together they make sandwiching your swaps hard and unprofitable.
Hyperstrate keeps signed Polygon transactions out of the public mempool before inclusion. Read how to prevent frontrunning on Polygon, see how private transactions work, or talk to our team.
