What Is a Sandwich Attack? How MEV Bots Steal From Your DEX Trades

A sandwich attack is a type of MEV (Maximal Extractable Value) exploitation where a bot detects a pending swap transaction, places its own trade before and after the victim's, and extracts profit from the resulting price movement.

This attack occurs on every blockchain with AMM-based decentralized exchanges — Solana, Ethereum, BSC, Base, and others. It is one of the most frequent causes of unexpected losses for DEX traders, and most victims are unaware it happened.

This guide covers the mechanics behind sandwich attacks, the conditions that make them profitable, and the methods available to protect against them.

How Blockchain Transactions Are Processed

To understand how sandwich attacks work, it helps to first understand how transactions are processed on blockchains like Solana, Ethereum, and BSC.

Blockchains don't process transactions one by one the moment you click "Swap." Instead, they work in batches. The blockchain collects all incoming transactions, groups them together, and processes the entire batch at once. Each batch is called a block, and the time it takes to produce one block is called the block time.

Blockchain	Block Time
Solana	~0.4 sec
Monad	~0.4 sec
Arbitrum	~0.25 sec
Base	~2 sec
Polygon	~2 sec
Optimism	~2 sec
Avalanche	~2 sec
BNB Chain	~3 sec
Ethereum	~12 sec

On Ethereum, a new block is produced roughly every 12 seconds. The following example shows how five transactions submitted at different times within the same 12-second window are all confirmed together — but executed in an order that has nothing to do with when they were submitted:

Transaction	Submitted	Confirmed	Execution Order
Transaction A	3:00:01 PM	3:00:12 PM	3rd
Transaction B	3:00:03 PM	3:00:12 PM	1st
Transaction C	3:00:05 PM	3:00:12 PM	5th
Transaction D	3:00:08 PM	3:00:12 PM	2nd
Transaction E	3:00:11 PM	3:00:12 PM	4th

All five transactions are confirmed at 3:00:12 PM when the block is created. But the execution order — the order that actually determines who trades first — is decided by the validator that produces the block, not by who submitted first.

Factors like priority fees, MEV tips, or direct relationships with the validator influence which transaction is placed where in the sequence. Transaction B was submitted second but executed first. Transaction A was submitted first but executed third.

This is the fundamental reason sandwich attacks are possible. MEV bots monitor pending transactions in the pipeline, and by paying higher fees, they can manipulate the execution order within a block to place their own transactions before and after yours.

How a Sandwich Attack Works

A sandwich attack exploits the fact that a swap moves the token's price in the liquidity pool. Here's how it plays out step by step.

1. You Submit a Swap: You submit a transaction to buy Token X on a DEX. Before this transaction is included in a block, it enters the network's transaction pipeline — on Ethereum this is the public mempool, on Solana it's the transaction forwarding layer — where it is briefly visible.
2. The Bot Detects Your Transaction: An MEV bot constantly scanning the pipeline spots your pending swap. It sees how much you're buying and calculates how much your trade will move the price. The larger your trade relative to the pool's liquidity, the more the price moves — and the more profitable the attack becomes.
3. The Bot Front-Runs You: The bot submits its own buy transaction with a higher priority fee, ensuring it executes before yours in the same block. The bot's purchase pushes the token price up.
4. Your Transaction Executes: Your swap goes through at the now-higher price. You receive fewer tokens than you would have without the bot's interference.
5. The Bot Back-Runs You: Immediately after your transaction, the bot sells the tokens it bought in Step 3. Your purchase created additional upward price pressure, and the bot sells into that higher price.

After the bot's sell, the price drops back down. You're left holding tokens that are now worth less than what you paid. The bot captured the spread between its buy and sell price — value extracted directly from your trade.

This entire sequence happens within a single block.

The image above shows a real sandwich attack captured on a Ethereum Uniswap V2 Pool. Three transactions executed at the exact same time (06:28:23 AM) within the same block:

1. 1FaE13 (MEV Bot) buys $616.13 worth of DAT token — the front-run.
2. 8a23ff (Victim) buys $1.9 worth of DAT token — executing at the now-higher price.
3. 1FaE13 (MEV Bot) sells $617.84 worth of DAT token — the back-run, capturing roughly $1.71 in profit.

The victim's $1.9 trade was small, but it was enough for the bot to extract profit. The entire attack — buy, victim, sell — happened in a single block.

When Your Trade Becomes a Sandwich Attack Target

Not every swap gets sandwiched. MEV bots only attack when the expected profit outweighs the cost. The following conditions make your trade a target:

• Large trade relative to pool size. A $50 swap in a pool with $500 liquidity moves the price by roughly 10% or more — a profitable target for sandwich bots. The same $50 in a pool with $5,000,000 liquidity barely moves the price, making it not worth attacking.
• High slippage tolerance. Setting slippage to 10% or higher signals that you'll accept a significantly worse price. This gives bots more room to push the price before your transaction would revert.
• Low-liquidity tokens. Newly launched tokens and memecoins tend to have small pools. Even a modest swap creates enough price movement for bots to exploit.

How to Protect Sandwich Attack

1. Use MEV-Protected Transaction Routing

The most effective protection is preventing bots from seeing your transaction in the first place.

• On Solana: Jito Bundles bypass the public transaction pipeline and send your swap directly to the Jito Block Engine, where MEV bots can't observe it. Most Solana trading tools already support this — if you see a "Jito Tip" field, your transactions are being routed through Jito. Jito also offers the jitodontfront mechanism, which ensures your transaction must appear first in any bundle it's included in.
• On Ethereum and EVM chains: Services like Flashbots Protect, MEV Blocker, and private RPCs route your transaction through a private mempool instead of the public one. Some wallets and DEX frontends offer this as a built-in option.

2. Set Tight Slippage

Slippage tolerance defines the worst price you're willing to accept. If you set 1% slippage, your transaction will fail rather than execute at a price more than 1% worse than expected.

This limits the bot's profit margin. If the bot can only extract a tiny amount before your transaction would revert, the attack becomes unprofitable after accounting for the bot's own fees and tip costs.

For most swaps, 1–3% slippage is sufficient. Only increase it for extremely volatile tokens or during launches where you're willing to accept a worse price.

3. Split Large Trades

Instead of swapping a large amount in one transaction, split it into smaller swaps. Each smaller trade has less price impact, making each one less attractive to sandwich bots.

The downside is more transactions and more fees, but the savings from avoiding a sandwich attack usually outweigh the extra cost.

4. Avoid Extremely Low Liquidity Pools

If a pool has very low liquidity, even a small trade creates enormous price impact. These pools are the easiest targets for sandwich bots. Check the pool's liquidity on DEXScreener, Birdeye, or DexTools before swapping.

5. Check Your Transactions After the Fact

Tools like sandwiched.me let you check if your wallet has been affected by sandwich attacks. Reviewing your past transactions helps you identify patterns and adjust your strategy — tighter slippage, smaller trades, or switching to MEV-protected routing.

Sandwich Attacks vs. Other Price Drops

Not every loss after buying is a sandwich attack.

• Sandwich attack: The price spikes right before your transaction and drops immediately after — within the same block or the next. On a block explorer, you can see a large buy right before yours and a large sell right after, from the same wallet or program.
• Normal sell pressure: The price gradually declines over minutes or hours after your buy. Other holders are selling, which is normal market behavior.
• Rug pull: The developer removes all liquidity from the pool. The price drops to near zero instantly and the token becomes untradeable.

Summary

Sandwich attacks exploit the fact that DEX prices move based on trade size relative to pool liquidity, and that transaction ordering within a block is controlled by validators — not determined by who submitted first.

To protect yourself: use MEV-protected routing (Jito on Solana, Flashbots Protect on Ethereum), set tight slippage, split large trades, and check pool liquidity before swapping.

FAQ

Can I get sandwiched on any chain?

Yes. Any chain with AMM-based DEXs is susceptible — Solana, Ethereum, BSC, Base, Polygon, Arbitrum, and others. The vulnerability comes from how AMMs calculate prices, not from any specific chain or DEX.

Does high slippage mean I'll get sandwiched?

Not automatically, but it increases your risk significantly. High slippage tells the network you'll accept a worse price, which gives bots more room to extract profit. Keep slippage as low as possible.

Is sandwich attacking illegal?

There's no clear legal framework in most jurisdictions. On Solana, the Solana Foundation and Jito have taken action against validators participating in sandwich attacks by removing them from delegation programs. On Ethereum, Flashbots and other infrastructure providers work to reduce MEV extraction.