Imagine placing an order at a market stall. Before the vendor serves you, someone buys up the entire stock ahead of you, drives up the price, then resells the products to you at a markup. Within seconds, you've paid more without even realizing it. That's exactly how a sandwich attack works in decentralized finance.
This type of attack exploits a fundamental characteristic of blockchain: all transactions are visible before they're validated. A malicious actor can observe your pending exchange order, place their own transaction just before yours to drive up the price, then resell immediately after. You take the hit on costs, they pocket the difference. All within a few blocks.
For anyone participating in Uniswap liquidity pools or making regular trades on other protocols, understanding this risk isn't optional. Sandwich attacks represent millions of euros in annual losses for users. Yet concrete MEV protection methods can significantly reduce this exposure. Like any investment, understanding the real risks before acting remains your first line of defense.
How a sandwich attack works on Uniswap
The mechanism relies on three successive steps—hence the name "sandwich." Let's take a concrete example: you want to swap 10 ETH for USDC on Uniswap.
Your transaction enters the mempool, a waiting area where all unvalidated transactions are publicly visible. A specialized bot detects your order and analyzes its potential impact on the liquidity pool's price. If your transaction is large enough to move the price, the attack triggers.
First transaction: the bot places a USDC buy order just before yours, with slightly higher transaction fees (gas) to jump the queue. This transaction drives up the USDC price in the pool.
Your transaction: it executes at the new, now unfavorable price. You receive less USDC than you should have at the original price. This is forced trading slippage orchestrated by the attacker.
Third transaction: immediately after, the bot resells its USDC at the inflated price you just created. It pockets the difference between its purchase price (before your transaction) and its sale price (after your transaction).
These three operations happen in the same block or within a few blocks. For you, the result looks like high slippage. But it's not natural market volatility—it's an orchestrated manipulation that costs you directly.
The real impact on your DeFi operations
Sandwich attacks on Uniswap primarily affect two types of users: those swapping tokens, and those adding or removing liquidity from pools.
For a simple swap, losses depend on your transaction size and pool depth. On a shallow pool, even a swap worth a few thousand euros can lose 2 to 5% to a sandwich attack. On the most-used pools like ETH/USDC, the impact is typically lower (0.5 to 1%), but remains significant for large volumes.
Here's a documented case: a user swaps 50 ETH for USDC on Uniswap V2, accepting 3% slippage. A sandwich attack occurs. Instead of receiving 98,500 USDC (the expected price with 1.5% natural slippage), they receive 96,200 USDC. The difference—2,300 USDC—goes straight to the attacker's wallet. The actual cost overrun reaches 2.3%.
For yield farming, the impact is twofold. First, each liquidity addition or withdrawal can be attacked, eroding your target returns. Second, some users automate their operations (position rebalancing, reward harvesting), exposing them repeatedly. Over a strategy with multiple actions per month, cumulative losses can reduce your annual target yield by several percentage points. Like with other technical vulnerabilities, constant vigilance is required.
The protocols themselves aren't responsible for these attacks. Uniswap, like other DEXs, functions exactly as designed: transactions execute in the order determined by gas fees. This very logic enables sandwich attacks, without any malicious code involved.
Detecting a sandwich attack after the fact
Identifying an attack after it happens helps you understand what occurred and adjust your approach for future operations.
Check transaction history: go to Etherscan (or the relevant blockchain's explorer) and search your transaction. Look at the transactions immediately before and after it. If you see an address that bought the same token just before you, then resold it right after, with consistent amounts, it's likely a sandwich attack.
A telltale sign: the three transactions (bot purchase, your transaction, bot resale) often come from the same block or consecutive blocks. The attacker uses slightly higher gas fees than yours to guarantee positioning.
Compare executed price to expected price: if the gap significantly exceeds your accepted slippage, or if you hit maximum slippage while the market was stable, manipulation probably occurred.
Specialized tools make this easier. EigenPhi offers visual analysis of sandwich attacks on Ethereum. Enter your transaction address, and the service tells you if it was caught in an attack, including the amount extracted. Bloxroute provides similar services, focusing on visualizing MEV flows (Maximal Extractable Value, the technical category sandwich attacks belong to).
This retrospective analysis mainly helps you calibrate future operations. If you spot repeated attacks on a specific pool or at certain times, you can adjust your strategy accordingly.
Practical methods for front-running prevention
Reducing exposure to sandwich attacks doesn't require advanced technical skills. A few adjustments to how you operate are enough.
Limit tolerated slippage
Slippage is the price difference you accept between when you confirm a transaction and when it executes. By default, many interfaces suggest 2 to 3% slippage. That's an open door for attacks.
By reducing tolerated slippage to 0.5% or 1%, you force your transaction to fail if the price moves too far from validation. Sure, your transaction might get rejected if the market shifts slightly. But you avoid paying a hefty markup to an attacker. It's a trade-off: preferring failure to robbery.
This method works particularly well on liquid pools, where natural price movements are limited. On a shallower pool, you may sometimes need to accept slightly higher slippage for the transaction to go through, increasing the risk.
Split large transactions
Sandwich attacks are profitable when the targeted transaction is large enough to move the price. By splitting a big swap into several smaller operations, you reduce the appeal of each individual transaction.
Example: instead of swapping 50 ETH at once, split it into 5 or 10 transactions of 5-10 ETH each. Each transaction will have less impact on the pool, making the attack less economically attractive for the bot (its gas fees might exceed potential gains on a small transaction).
Caution: this method has a cost. You pay transaction fees for each operation. On Ethereum during high congestion, this can quickly become prohibitive. The trade-off between splitting and gas costs depends on market context.
Use private RPCs for DeFi MEV protection
RPCs (Remote Procedure Call) are relays that transmit your transactions to the blockchain. By default, your transaction goes through a public RPC, meaning it's visible in the public mempool before validation. Bots exploit this visibility.
Some services offer private RPCs that send your transaction directly to validators, bypassing the public mempool. Your transaction stays invisible until it's included in a block. Bots can't anticipate it, so no sandwich attack.
Flashbots Protect is the most well-known service. It integrates easily with MetaMask and works on Ethereum. You simply change the RPC used in your wallet settings. Your transactions then route through Flashbots, which sends them directly to partner miners (or validators).
This solution is free and effective. However, it has one drawback: if your transaction fails for technical reasons (contract error, insufficient balance), you don't pay gas fees. This might encourage behavior where you test transactions without being certain of success, knowing failure costs nothing. It's a point to watch, but it remains the most robust method against sandwich attacks.
Use aggregators with MEV protection
Aggregators like CowSwap natively integrate protection against sandwich attacks. The principle: instead of sending your transaction directly to a DEX, you submit it to a group of solvers who find the best possible price and batch multiple orders together. Transactions then execute in batches, complicating the attack.
CowSwap also uses an intent-based order system: you sign an order with a price limit, and the protocol only executes it if that price can be achieved. No execution, no loss. The trade-off: execution may take slightly longer than a direct Uniswap swap.
Key takeaways on liquidity pool risks
Sandwich attacks are a structural risk in decentralized finance, inherent to blockchain's transparency. They affect all users who swap tokens or manage positions in Uniswap liquidity pools and other DEXs. The impact varies by transaction size and pool depth, but it's never negligible.
Protecting yourself means understanding how these attacks work, then adopting simple practices: limit slippage, split large volumes, use a private RPC, or go through an aggregator with DeFi MEV protection. No single method offers complete immunity, but combining them drastically reduces risk.
For those aiming for yield through farming or liquidity pool participation, ignoring this risk means watching part of your target return erode. Capital loss risk exists through these technical attacks, in addition to market fluctuations. Technical risk vigilance is an integral part of risk management in decentralized finance. The question isn't whether you'll ever be a sandwich attack victim, but how much it will cost you and how to limit that exposure.
```
