Sandwich Attacks: How Your DEX Trade Gets Front-Run

A sandwich attack is a classic form of MEV on DEXs: the attacker buys before your trade, your trade pushes the price up, and the attacker sells after your trade to profit from the price movement. Your transaction may still go through as expected, but you end up with fewer tokens than an ideal fill would have given you.

What is a sandwich attack?

A sandwich attack is essentially a combination of a front transaction, your transaction and a back transaction. By watching pending transactions in the public mempool, the attacker judges whether a given DEX swap has enough price impact and profit potential, then tries to place their own trades before and after the victim's trade.

Take a user buying a token with USDT as an example:

1. The user submits a relatively large USDT → Token trade.

2. The attacker notices that this trade is likely to push the token price up noticeably.

3. The attacker buys the token first — this is front-running.

4. The user's swap executes as planned, but because the pool price has already been pushed up, the user receives fewer tokens than expected.

5. Once the user's trade is done, the attacker immediately sells the tokens bought earlier — this is back-running.

6. The attacker profits from the price difference between the two trades.

This is what "sandwich" means: the user's trade is squeezed between the attacker's buy and sell. Uniswap's explanation of sandwich attacks follows the same basic process, and notes that price slippage and the transparency of blockchain transactions are important preconditions for this attack to work.

Why are DEXs so vulnerable to sandwich attacks?

The core reason is not some simple "bug" in DEXs. It is the combination of AMM pricing mechanics, publicly visible transaction information and intra-block transaction ordering, which creates exploitable room for MEV searchers.

In an AMM, a large swap can by itself change the asset ratio in the liquidity pool and therefore affect the price of subsequent trades. If the attacker can see that trade in advance, they can estimate the price change it is likely to cause and decide whether buying before it and selling after it is worth doing.

Ethereum's official documentation classifies extracting value by adjusting the inclusion, exclusion and ordering of transactions in a block as MEV. Sandwich trading is one of the more typical forms, and unlike arbitrage it directly worsens the execution results of ordinary users.

So the chain of events that really matters is this:

Public pending transaction → attacker spots a large swap → front buy → user fills → back sell → attacker profits

If you are still unclear about what Slippage, Price Impact and MEV each mean, start with Slippage and MEV: The Hidden Costs of DEX Trading — sandwich attacks are much easier to understand afterwards.

Where exactly does the attacker make money?

Sandwich attack profits come mainly from the price change caused by the victim's trade.

Suppose Token A is priced at 100 USDT in a liquidity pool. A user submits a large buy order, and under normal conditions the price could rise to 105 USDT once that order executes.

If the attacker can buy Token A before the user's trade, they buy at the lower price; once the user's large buy order pushes the price up, selling Token A can capture the spread.

One thing deserves special attention here: the attacker does not simply "take" the user's money out of thin air. They trade on the price impact that the user's large order has on the pool. The loss the user bears usually shows up as a worse fill price, higher price impact and extra slippage cost.

Real profits must also cover gas, competition costs for transaction inclusion, price changes and failed transactions. So seeing a large swap does not automatically mean there is a profitable sandwich opportunity.

Why are large trades more likely to be targeted?

Sandwich attacks focus especially on trades that have a big price impact on the liquidity pool.

If a pool has very deep liquidity, an ordinary-sized trade usually will not move the pool price much, and even an attacker who buys early may not earn enough profit.

Conversely, if the trade size is large relative to the pool's liquidity, buying the same amount of tokens can cause a more visible price change. Uniswap explicitly recommends that users prefer pools with deeper liquidity, because attackers find opportunities more easily in the large price swings of low-liquidity pools.

So when judging risk, do not only ask "how much am I trading" — look at this:

Trade size ÷ effective liquidity of that pool

The higher this ratio, the more pronounced the trade's price impact generally is.

Why does high slippage amplify sandwich attack risk?

Slippage tolerance determines the maximum price deviation you are willing to accept on a fill.

For example, you are buying a token and the quote shows an estimated 1,000 tokens. If you set a high slippage tolerance, the trade can still go through despite a fairly noticeable price change, as long as the final fill stays within the allowed range.

That leaves the attacker more room to operate.

So high slippage does not mean you will definitely be sandwiched, but it can widen the price space the attacker can exploit. On the other hand, set slippage too low and the trade may fail because the market price moved.

The sensible approach is not to set slippage "as low as possible", but to adjust it according to token liquidity, trade size, network conditions and your actual execution needs.

How is a sandwich attack different from ordinary front-running?

Both are MEV-related behaviours, but the trade structures are not identical.

Ordinary front-running is closer to "I see your trade and complete a similar trade ahead of you" — the attacker's goal is to gain first-mover advantage.

A sandwich attack, by contrast, needs two trades that form a complete structure:

attacker buys → user trades → attacker sells

So a sandwich attack requires not only predicting the user's trade, but also completing two trades around it while bearing price change and transaction failure risk.

Ethereum's official documentation also lists Sandwich Trading separately as a common form of MEV extraction, and notes that it leaves sandwiched users facing higher slippage and worse execution results.

How can ordinary users reduce sandwich attack risk?

1. Avoid blind, single, large swaps

If the amount is large, consider splitting the trade so that a single order does not hit the liquidity pool price too hard.

Splitting does not mean absolute safety, though. If the split orders are still exposed to the public trading environment, MEV risk remains, so judge it together with actual liquidity and the execution environment.

2. Prefer deeper liquidity pools

The deeper the liquidity, the smaller the price change a single trade usually causes.

So when trading a token, do not just compare the quoted price on screen — also look at which liquidity sources are actually used and the Price Impact at your trade size.

3. Set a reasonable Slippage Tolerance

Do not set slippage tolerance too high just to "make sure the trade succeeds".

At the same time, do not mechanically set an extremely low slippage that makes trades fail constantly. A reasonable principle is to keep the allowed price deviation small while staying within a fill range you can accept.

4. Prefer trading routes with MEV protection

Some wallets, trading tools and protocols reduce how much of a trade is exposed to the public mempool, using private transaction channels, order intents or other mechanisms.

Flashbots' Protect service, for example, is a transaction protection mechanism designed for front-running and other MEV risks.

Some 1inch trading products also use an intent-based architecture and offer MEV Protection; its Wallet swap feature is currently also labelled as supporting MEV protection.

Note that using so-called "MEV protection" does not mean every trading risk disappears. The actual scope of protection still depends on the wallet, network, trading mode and execution mechanism you use.

5. Be especially careful with low-liquidity tokens

If a token has very low liquidity but your trade size is large, then beyond sandwich attacks you may also face severe Price Impact, slippage and insufficient liquidity.

So when you find that a token only lets you complete a trade with a very high slippage setting, do not treat it as a question of "which parameters to set" — reassess whether this pool is suitable to trade in at all.

How can you tell if you may have been sandwiched?

A sandwich attack does not necessarily come with an obvious "you were attacked" notice. You usually need to examine on-chain transaction records.

Key things to check:

• Was there a large buy of the same token before your trade;

• Was there a large sell from the same address after your trade;

• Did the token price move abnormally around your trade;

• Did your actual fill price deviate noticeably from the quote when you submitted;

• Was the liquidity of the pool you traded in relatively low;

• Were the attacker's two trades in the same block as yours, forming a clear squeeze structure.

If you see an on-chain structure like "attacker buys → my swap → attacker sells" and the attacker profited from the price change, that is a fairly clear sign of a sandwich attack.

Still, transaction order alone cannot confirm an attack with 100% certainty. You need to consider trade size, pool state, gas, routing and the actual price change.

Can sandwich attacks be avoided completely?

It is very hard to eliminate sandwich attack risk entirely through any single parameter.

What is involved is the combined relationship between blockchain transaction transparency, transaction ordering, AMM pricing mechanics and the MEV market. The Ethereum ecosystem is also continuing to explore MEV mitigation approaches including PBS, the Builder API and private transaction channels.

For ordinary DEX users, the more realistic goal is not "never get sandwiched", but to lower the odds of becoming a high-value target and to reduce the damage any single attack can do.

You can boil risk control down to one simple formula:

large trade ↓ + deep liquidity pool ↑ + sensible slippage ↓ + MEV protection ↑ = sandwich attack risk ↓

Summary

At its core, a sandwich attack is an attacker using public pending transactions and transaction ordering to insert their own trades before and after a user's swap, and to profit from the price change caused by that swap.

What ordinary users should focus on is not "is there a setting that guarantees I will never be attacked", but trade size, liquidity, Price Impact, slippage tolerance and whether the trade goes through an MEV-protected channel.

Especially when trading low-liquidity tokens or doing large swaps, do not look only at the quote shown in the trading interface. Understanding the full chain of "quote → Price Impact → Slippage → MEV → final fill" is what lets you judge the real cost and risk of a DEX trade.

Crypto and DeFi trading carries significant risk, and prices, liquidity, smart contracts and network conditions can all change rapidly. This article is for information and educational purposes only and does not constitute investment advice.