How sandwich-attack protection actually works
A sandwich attack wraps your swap between two of the attacker's. Real protection is a cost-optimization problem, not a slippage slider. Here is how it works.
What a sandwich attack is
When you submit a swap to a public mempool, you broadcast your intent before it executes. A searcher watching the mempool can place a buy just before your trade and a sell just after it, wrapping your transaction between two of their own. Their buy pushes the price up, your trade executes at the worse price, and their sell captures the difference. You are the filling, hence "sandwich."
This is not a bug in any single contract. It is a structural property of public, ordered transaction execution, and it extracts value from ordinary users on every busy chain.
Why a slippage slider isn't protection
The usual defense is a slippage tolerance. Reject the trade if the price moves more than X%. It helps, but it is blunt. Set it too tight and your trades fail in normal volatility. Set it too loose and you leave exactly the room a sandwich needs to be profitable. A fixed percentage cannot know how much room a rational attacker actually has on this trade, in this pool, at this moment.
The right question is not "what percentage feels safe" but "at what point does sandwiching my trade stop being profitable for the attacker". That is a calculation, not a slider.
Protection as a cost-optimization problem
Real protection models the attacker. Given the pool's liquidity, your trade size, and gas and priority-fee costs, you can estimate the attacker's optimal sandwich and the profit it yields. Protection then means shaping the trade (its slippage bound, its routing, sometimes its size or timing) so that the attacker's best-case profit falls below their cost. Squeeze that margin to zero and the attack simply is not worth running.
The other lever is not showing your hand at all. Routing the trade through private orderflow (submitting directly to block builders instead of the public mempool) means a searcher never sees it in time to wrap it. Combined with cost modelling, private submission removes both the opportunity and the incentive.
Simulate before you trust
None of this can be assumed to work. It has to be simulated. Running a protection strategy against historical mempool data and known extractive patterns tells you how it would actually have behaved, rather than how you hoped it would. That simulation-first discipline is how our founder built MEV Shield, a calculus-driven MEV protection and cost-optimization system with sandwich-attack simulation and Flashbots integration.
Common questions
- What is a sandwich attack?
- A searcher places a buy immediately before your swap and a sell immediately after it, wrapping your transaction between two of their own. Their buy moves the price against you, your trade fills at the worse price, and their sell captures the difference.
- Doesn't setting slippage tolerance protect me?
- Only partially. A fixed slippage percentage is blunt. Too tight and normal trades fail, too loose and it leaves exactly the room a sandwich needs. It doesn't account for how much profit an attacker can actually make on your specific trade.
- How does effective MEV protection work?
- It models the attacker's optimal sandwich given pool liquidity, trade size, and costs, then shapes the trade so the attack isn't profitable, then routes through private orderflow so searchers never see the trade in the public mempool. The strategy is simulated against real data before it's trusted.
Working on something like this?
This is the layer we work in. If you have a hard problem underneath a product, tell us the hard part.