Liquidity Pool Trading: A $15,000 Loss to Sandwich Attacks

The trade simply broadcast its intentions to a public mempool, and a bot placed transactions before and after it before the network could confirm anything.

That is the side of liquidity pool trading that does not appear in the marketing copy. Swapping tokens without a centralized intermediary is convenient, fast, and often remarkably efficient. But every transaction sent through a public mempool is also a visible order waiting to be interpreted. Automated systems can read its size, route, slippage limit, and likely effect on the pool before the swap becomes final.

The broader extraction problem is substantial. Ethereum DEX users lost roughly $1.4 billion to MEV-related activity in 2025 alone, according to the research cited for this analysis. For an individual trader, the damage usually does not arrive as one spectacular loss. More often, it is distributed across ordinary-looking executions: a quote that moves just before confirmation, a stablecoin swap that returns less than expected, or a transaction that lands at the worst price allowed by its settings.

A sandwich attack is not hacking your wallet. It is reading your intentions before the network confirms them and trading against you with surgical precision.

The Anatomy of a Sandwich Attack: How Bots Front-Run Your Trades

The name is descriptive, not metaphorical. A sandwich attack is a three-part transaction sequence in which a user's trade is squeezed between two automated orders placed by an MEV bot. MEV, or Maximal Extractable Value, describes the profit available when transactions are reordered, inserted, or otherwise positioned to take advantage of information visible before confirmation.

Here is the process without the jargon wall:

1. You submit a swap on a liquidity pool, such as USDC for USDT. Your transaction enters the public mempool, a staging area where pending transactions wait to be processed.

2. A searcher bot sees the transaction before it confirms. It simulates the swap, estimates how your order will change the pool's price ratio, and calculates how much value might be extracted.

3. The bot front-runs your trade by buying the asset you are trying to acquire. That purchase moves the pool's price against you.

4. Your swap executes at the worse price. You receive fewer tokens than the original quote suggested, although the result may still remain within the slippage tolerance you approved.

5. The bot back-runs the trade by selling immediately after your transaction. It captures the price difference created around your order.

The bot is not guessing in the way a human trader guesses. It can inspect the pending transaction, model the pool's current reserves or liquidity distribution, and submit its own transactions with a fee structure designed to place them in the desired order. The opportunity exists because the user's transaction is both predictable and temporarily exposed.

From the user's point of view, the swap may look completely normal. The wallet shows a successful transaction. The DEX interface reports an execution price. The tokens arrive. There may be no obvious warning that another trader inserted two orders around yours and took a meaningful portion of the trade's value.

That is why sandwich attacks are easy to underestimate. A failed transaction is visible. A drained wallet is visible. A bad execution caused by MEV can look like routine liquidity pool slippage, particularly when the loss is small enough to disappear inside the gap between the quoted and final price.

Why concentrated liquidity changes the calculation

Concentrated liquidity pools, including Uniswap v3 pools, do not distribute capital evenly across every possible price. Liquidity providers assign capital to defined price ranges. This can make capital more efficient when the market remains inside those ranges, but it also means that effective depth can change sharply as a trade moves through the pool.

For a large order, the relevant question is not simply how much liquidity the pool contains in total. It is how much usable liquidity is available at the exact prices through which the transaction will move. A pool can look deep in aggregate while offering considerably less resistance at the execution point that matters.

That distinction gives searcher bots a useful advantage. Once they see the size and direction of a pending order, they can estimate how far through the available liquidity the trade will move. If the user's slippage limit is wide enough, the bot has room to push the price, let the victim trade execute, and unwind the position afterward.

The trade does not need to be exotic. It can involve a major stablecoin pair, a familiar DEX, and an asset that barely moves on ordinary charts. The vulnerability comes from the interaction between order size, pool depth, transaction visibility, and the maximum slippage the user has authorized.

The $215,000 Warning: Analyzing High-Slippage Catastrophes on Uniswap

The March 2025 USDC-USDT incident deserves attention because it shows how severe the result can be when a large trade meets an openly visible mempool transaction.

The trader was using Uniswap v3, one of the best-known venues for stablecoin liquidity. The swap was worth $220,764, but the trader received only $5,272. A sandwich bot positioned its transactions around the trade, and the sequence completed in under eight seconds. The difference—$215,492—was not caused by a compromised private key or a bug in the protocol's basic swap mechanism. It was the consequence of allowing a large, predictable order to execute with enough slippage room for the attacker to manipulate the path around it.

It is more accurate to think of this as the trade being overwhelmed than the pool being “drained.” The pool continued operating. The contract followed its rules. The failure was at the level of execution protection: the user exposed a valuable transaction, and the bot found enough room to make that exposure profitable.

A separate March 2025 case involved a DeFi user losing more than $714,000 across six transactions on the same pair. The key detail was a 100% slippage tolerance. In practical terms, that setting gave the transaction permission to settle at almost any price the pool would accept. It did not guarantee that the user would receive a fair price, and it did not shield the trade from volatility or MEV. It merely reduced the conditions under which the transaction would revert.

Wide slippage does not protect you from price movement. It gives bots a license to extract everything the pool will bear.

Slippage tolerance is often treated as a technical setting that can be left to the interface. That is a mistake, particularly for large orders. It defines the boundary between an acceptable execution and an execution the user has authorized regardless of how far the market moves. A bot does not need to extract every possible dollar if a tighter limit would make the transaction fail. It only needs to identify the amount of room available and decide whether the expected profit exceeds the cost of placing the surrounding transactions.

This is also why “the pool is deep” is not a sufficient safety argument. Depth can reduce ordinary price impact, but it does not make a public transaction private. A large stablecoin pool may offer good baseline execution and still be attractive to MEV searchers because it processes substantial volume and provides predictable routes.

The practical risk is the combination of factors:

• a transaction large enough to move the pool's price;
• a public mempool where the order can be inspected;
• a slippage limit wide enough to accommodate a worse execution;
• a route or liquidity range that makes the price movement easy to model;
• sufficient expected profit to justify priority fees and execution costs.

Remove one of these conditions and the attack may no longer be worthwhile. Leave all of them in place, and a trade that looks routine on the interface can become an unusually valuable target.

Quantifying the Silent Drain: Why Regular Traders Lose $12,000 Annually

Most traders will never lose $215,000 in a single transaction. That does not make smaller losses harmless. The more common problem is that MEV extraction blends into normal execution costs, making it difficult to separate a sandwich attack from ordinary market movement.

The research describes a specific simulation involving a DeFi trader who made three swaps per week, with each swap valued at $3,000. In that simulation, the trader experienced an average silent loss of 2.65% per trade to sandwich attacks. Projected across the simulated trading pattern for a year, the result was $12,406 in lost value.

That figure is not an average for all public-mempool users. It is not a demonstrated worst-case comparison, either. It is the outcome of one defined simulation with a particular trade frequency, transaction size, and assumed extraction rate. The number is useful because it translates an abstract percentage into a recognizable trading routine, but it should not be presented as a universal annual bill for every DEX user.

The simulation still makes the underlying point uncomfortable. A trader does not need to make one enormous mistake to lose a significant amount. Repeated swaps can create repeated exposure, and a small percentage taken from each execution compounds into a meaningful total when the same workflow continues week after week.

The loss may appear in several places:

• the difference between the displayed quote and the final amount received;
• a price impact figure that is larger than expected;
• a route that becomes less favorable between submission and confirmation;
• a transaction that succeeds, but only after using most of the permitted slippage;
• a pattern of executions that is consistently worse than a private or protected route.

This is why looking only for failed transactions is not enough. Sandwich attacks are generally designed to make the victim's transaction succeed. A reverted swap produces no victim-side trade for the bot to exploit. A successful swap within a loose tolerance can produce exactly the opposite.

In August 2024, Ethereum DEXs recorded more than 130,000 sandwiched transactions. That corresponds to roughly one sandwiched transaction every 20 seconds over the month, on average—not one every few seconds. The sourced count is important because it shows the scale of the activity without turning it into a more dramatic claim than the data supports.

The count also does not mean that every one of those transactions represented the same level of damage. Some involved small trades and limited extraction. Others were substantially more expensive for the user. Nor does the monthly figure establish that every ordinary trader is targeted at the same rate. It establishes that sandwiching was frequent enough to be a persistent market feature rather than an isolated trick.

The pattern is especially relevant to anyone who trades regularly. A one-off swap may produce a modest loss that is difficult to notice. A repeated workflow creates a larger surface area: more transactions visible to searchers, more opportunities for a wide tolerance setting to be used, and more chances for a trade to interact poorly with a thin section of a concentrated-liquidity pool.

What the number does—and does not—tell you

The $12,406 simulation result should be read as a risk illustration, not as a personal forecast. Your outcome may be lower if you trade smaller amounts, use tighter limits, choose deeper routes, or avoid public exposure. It may be higher if you trade volatile assets, submit large orders, use permissive slippage, or repeatedly trade during periods of congested execution.

The important measurement is not whether every transaction is profitable relative to a displayed quote. It is whether the execution process gives an external searcher a predictable and valuable opportunity. Once that opportunity exists, routine trading activity can turn into a recurring transfer of value.

Stablecoin Pools and the 38% Target: Why Liquidity Depth Matters

It is tempting to assume that volatile tokens carry the greatest MEV risk. Large price swings certainly create hazards, but the data points to another important target: stablecoin pools.

According to EigenPhi's 2025 analysis, stablecoin pools accounted for 38% of sandwich attacks on Ethereum. That means a substantial share of the observed activity involved pools for assets such as USDC, USDT, DAI, and similar tokens—assets many users treat as operationally boring.

The appeal for bots is straightforward. Stablecoin pools attract high trading volume, and high volume creates a steady supply of pending transactions. Users also tend to approach stablecoin swaps with less caution. They may assume that a small expected price difference makes the trade safe, leave the default slippage setting unchanged, or treat a large stablecoin order as too predictable to be interesting.

Predictability is exactly what makes it interesting.

A searcher can often estimate the expected price impact of a stablecoin swap more easily than the future price of a volatile token. If the order is large, the route is visible, and the tolerance is broad, the bot does not need to make a complicated directional bet. It can focus on the mechanical price movement caused by the victim's own trade.

Stablecoin status also creates a psychological trap. Traders often think about volatility risk first: will the asset move before the transaction confirms? In a sandwich attack, the issue is different. The asset may remain close to its expected value while the pool's execution price is temporarily moved around the victim's order.

Depth is not a single number

When assessing liquidity pool trading, “depth” needs to be treated as an execution property rather than a headline statistic. Total value locked can be useful context, but it does not tell you precisely how a particular order will behave.

What matters is the interaction among:

• the amount available around the current price;
• the position of active liquidity ranges;
• the size and direction of the swap;
• the number of pools and hops in the route;
• the slippage ceiling;
• the time the transaction remains exposed before confirmation.

A route through several pools may reduce ordinary price impact, but it can also make the transaction more complex and reveal more information about the user's intended execution. A single deep pool may be simpler, yet still vulnerable if a large order can move its price significantly. There is no universal rule that says the shortest route is safest or that the pool with the highest advertised liquidity is automatically the best venue.

For stablecoin swaps, a narrow slippage setting can be particularly valuable because the expected market movement is often limited under normal conditions. That does not eliminate the risk of a revert, and it does not guarantee a better price in every market state. It does reduce the room available for a bot to push the execution against you while still getting the transaction confirmed.

Defensive Routing: Bypassing Public Mempools to Eliminate MEV Exposure

The most useful shift in thinking is to stop treating the DEX interface as the entire trading system. The visible swap screen is only the beginning. Between the moment you approve a transaction and the moment it is confirmed, the order passes through a routing and transaction-delivery environment where its visibility matters.

Several defenses can reduce that exposure. None is perfect for every asset, chain, or trading size, but they are practical tools rather than theoretical protections.

Tight slippage settings

A slippage tolerance of 0.1% to 0.5% can cap the amount a bot is able to extract from a single trade, assuming the transaction reverts when the execution moves beyond that boundary. The trade-off is real. In a volatile market or a thin pool, a tight setting can cause the transaction to fail, and the user may still pay network fees for the attempt.

For stablecoin swaps and larger trades through relatively deep pools, a lower ceiling is often more defensible than leaving a broad default in place. The correct setting depends on the asset pair, route, and current market conditions, but a tolerance above 1% on a stablecoin swap deserves a specific justification. “The interface selected it” is not one.

A slippage limit should be understood as an authorization boundary. It does not predict the price you will receive. It tells the protocol the worst execution you are willing to accept before the transaction stops. That makes it one of the few controls a trader can use directly at the point of submission.

Private mempools and MEV-protected relays

The strongest way to reduce public sandwich exposure is to keep the pending transaction out of the public mempool. Private transaction routes and MEV-protected relays can send the order directly to participating block builders or validators rather than broadcasting it for every searcher to inspect.

Services such as Flashbots Protect and MEV Blocker are examples of infrastructure built around this idea. CoW Swap uses batch auctions, where orders can be grouped and matched through a different execution process instead of being exposed as individual public transactions in the same way.

Private routing does not mean that every execution will be perfect. The transaction still has to be included, the route still needs adequate liquidity, and the service's guarantees depend on its implementation and participating infrastructure. It may also introduce different timing or availability trade-offs. What it changes is the most important part of the sandwich equation: the bot no longer receives the same straightforward view of your pending order in the public mempool.

Batch auctions take a related but distinct approach. By grouping orders and finding an execution path for them together, they can reduce the incentive and ability to place a traditional front-run and back-run around one visible user transaction. In some cases, the resulting execution can also be competitive with direct public-pool routing.

Wallet-level integration

Wallets and trading interfaces increasingly expose MEV protection as a default setting or an optional toggle. If the wallet supports a protected route, it is worth checking whether the setting applies to the chain, token pair, and transaction type you are actually using. A label that says “MEV protection” is not enough to explain the exact execution path.

This is an important distinction in wallet evaluation. Security is not only about whether the wallet protects private keys or supports hardware signing. It also concerns the path from intent to confirmation:

1. What transaction does the interface construct?

2. Which router or aggregator receives it?

3. Is the transaction broadcast publicly?

4. What slippage limit is attached?

5. Can the wallet use a private relay or protected RPC endpoint?

6. What happens if the preferred route is unavailable?

A wallet that makes protected execution easy can remove several opportunities for user error. A wallet that merely displays an attractive quote but defaults to a public broadcast leaves the final risk decision hidden behind a familiar-looking button.

Large trades need a different workflow

A trader swapping a modest amount does not need to approach every transaction like a market-structure specialist. Large orders deserve more deliberate handling because the cost of being visible scales with the order's likely impact.

Breaking a large swap into smaller pieces can reduce the price impact of any one transaction, although it may increase total fees, expose multiple transactions, or create execution risk if the market moves between them. Splitting an order is therefore not a universal defense against sandwich attacks. It works best when combined with sensible slippage and protected routing.

An aggregator can compare several pools and routes, but aggregation alone is not the same as MEV protection. A better route may improve ordinary execution while the transaction remains publicly visible. Conversely, a private route can reduce sandwich exposure without guaranteeing the lowest possible price. These are separate dimensions of execution quality and should be evaluated separately.

For especially large trades, a test transaction can reveal whether the chosen route behaves as expected, but the test itself does not guarantee that a later transaction will face the same liquidity or mempool conditions. The point is not to create a ritual around every swap. It is to recognize when the amount at risk justifies more than clicking the default confirmation button.

Who This Matters For

If you swap tokens occasionally, in small amounts, on a major pair such as ETH to USDC, sandwich attacks may be a real cost without becoming a life-changing event. Tighten the slippage setting, use a protected route when it is available, and avoid assuming that a successful transaction was necessarily an efficient one.

If you make regular liquidity pool trades, move meaningful capital, or operate mostly in stablecoin pairs because you assumed they were safe by default, the calculation changes quickly. The $12,406 annual figure comes from a specific simulation of a defined trading pattern. It should not be treated as the average loss suffered by all public-mempool users. But it does show how recurring, moderate extraction can become a five-figure result when a trader makes repeated swaps under the same exposed conditions.

The distinction between ordinary liquidity pool slippage and MEV extraction is not always visible from one transaction. That is precisely why the workflow matters more than any single execution. If the same wallet repeatedly sends sizable orders to a public mempool with permissive slippage, it is repeatedly offering searchers the information they need.

The bots are not going anywhere. They are automated, economically motivated, and integrated into the way public blockspace is searched. The practical question is not whether a DEX is decentralized or whether a stablecoin pair is usually calm. It is whether the route from your trading intent to on-chain confirmation gives someone else a clean opportunity to trade around you.

The fix does not require a computer science degree. It requires treating transaction visibility as part of execution risk. Set a slippage limit that reflects the trade rather than the interface's default. Use private or MEV-protected routing when the amount justifies it. Look at effective liquidity, not only the pool's headline size. And remember that a successful swap can still be an expensive one.

In liquidity pool trading, the transaction is not finished when you press “confirm.” Until it is included, it is information—and on a public mempool, information is often the thing the bots are buying.