Asymmetric Information Sandwich Attacks on Liquidity Providers

By DeFi Intel Research · Reviewed 2026-07-02 · 8 min read · intermediate

Sandwich attacks liquidity providers by exploiting asymmetric information: the attacker sees a pending trade in the mempool and executes a front-running buy followed by a back-running sell, profiting from the price impact while the liquidity provider absorbs the loss. This guide explains how the imbalance of information between attackers and passive LPs makes sandwich attacks particularly devastating.

Unlike traditional impermanent loss—which arises from price moves outside the LP's control—sandwich attacks are a deliberate extraction of value from LPs by entities with superior real-time data. Understanding this vulnerability is essential for anyone providing liquidity on automated market makers (AMMs) like Uniswap, SushiSwap, or Balancer.

What Is a Sandwich Attack on Liquidity Providers?

A sandwich attack is a form of maximal extractable value (MEV) targeting decentralized exchange (DEX) trades. The attacker monitors the public mempool for a pending transaction (the victim's trade), then submits two transactions:

• A front-run buy order just before the victim’s trade, driving the price up.
• A back-run sell order immediately after, selling at the inflated price back to the LP pool.

The attacker profits from the price difference, but the cost is borne by the liquidity provider (LP) who underpins the pool. The LP effectively sells at a worse price (due to front-run) and buys back higher (due to back-run), losing value on both sides. This is fundamentally an exploitation of asymmetric information: the attacker sees the order flow, the LP does not.

Real-world examples are abundant on Ethereum, where MEV bots execute thousands of such attacks daily on pairs like ETH/USDC on Uniswap V2 and V3. The LP’s role is purely passive—they provide assets and wait for swaps—while the attacker actively extracts value using superior real-time knowledge.

How Asymmetric Information Gives Attackers an Edge

The core enabler of sandwich attacks is the public mempool. On Ethereum and other EVM chains, every pending transaction is visible to all nodes until confirmed. MEV bots scrape the mempool, identify large trades that will cause slippage, and instantly calculate profitable sandwich candidates.

Liquidity providers, by contrast, have no visibility into pending trades. They commit funds to a pool and earn fees based on average trading volume, but they are blind to the individual transactions that cause temporary price dislocations. This information asymmetry is structurally embedded: the attacker sees the flow, the LP only sees the average outcome.

Tools like Flashbots allow searchers to submit bundles directly to block builders, reducing competition, but even then the information asymmetry persists. LPs cannot know in real-time when a large order will hit the pool, so they cannot adjust their positions to avoid being sandwiched. Some protocols try to mitigate this with private mempools (e.g., CowSwap’s batch auctions) or by hiding order flow (e.g., Uniswap X), but most LPs still operate on public AMMs.

Why Are Liquidity Providers the Ultimate Victims?

Liquidity providers bear the cost of sandwich attacks in two ways: adverse selection and uncompensated slippage. When a sandwich occurs, the LP effectively sells low and buys high around the victim trade. The attacker’s profit comes directly from the pool’s reserves, reducing LP holdings.

Unlike the victim trader (who may suffer only slight slippage on their intended price), the LP experiences a permanent loss because the attacker’s trades are real swaps that change the pool ratio. Over many attacks, the LP’s share of the pool loses value even if fees are considered.

Furthermore, LPs are always at risk because they provide liquidity without any control over which trades execute. On a busy DEX, a large swap will inevitably attract sandwich bots. LPs using concentrated liquidity (e.g., Uniswap V3) are even more exposed if their range is tight, as a single sandwich can push the price outside their range, causing them to miss further fees.

Anatomy of a Sandwich Attack: A Step-by-Step Example

Consider a Uniswap V2 ETH/USDC pool with 1000 ETH and 4,000,000 USDC (price 4000 USDC/ETH). A user submits a buy order of 10 ETH (cost ~40,000 USDC). The attacker’s bot sees this pending transaction in the mempool.

1. Front-run: Bot buys 50 ETH for ~200,000 USDC. This pushes the price to ~(4,000,000 + 200,000) / (1000 - 50) = 4200 / 950 = ~4421 USDC/ETH.
2. Victim trade: The victim buys 10 ETH at the new, higher price, spending ~44,210 USDC for 10 ETH (instead of 40,000). The pool now has 940 ETH and 4,044,210 USDC.
3. Back-run: Bot sells its 50 ETH back into the pool at the elevated post-victim price. Because the victim's buy pushed the price higher, the bot receives more USDC than the ~200,000 it spent on the front-run, netting the attacker a profit (detailed constant-product math omitted for brevity).

Net result: bot profits ~2,000 USDC; victim paid more than fair price; LP’s pool lost value because the attacker extracted more than the victim’s slippage. The LP’s share of the pool decreased in dollar terms even after fees.

Real bots use gas auctions to ensure their front-run and back-run are placed immediately around the victim’s tx. Without mempool visibility, the LP cannot defend against this.

Quantifying the Damage: Illustrative Numbers

To illustrate, suppose a single sandwich attack on a $10M pool causes the LP to lose $500 in value (the attacker’s profit plus slippage). If 100 such attacks happen per day, the LP loses $50,000 daily—far exceeding typical fee earnings (often 0.3% of volume, maybe $30,000 daily volume leading to $90 in fees). Over a week, the LP is net negative.

In practice, the size of the attack scales with the victim trade size and pool liquidity. Low-liquidity pools are especially vulnerable because even a small trade causes high slippage, making sandwich profit large relative to the trade. On high-liquidity pairs, attacks still occur but profits per attack are smaller; nevertheless, many small attacks can accumulate.

Data from MEV research (e.g., Flashbots dashboard) shows that sandwich attacks account for a significant share of MEV—often 10-30% of all extracted value. LPs unknowingly subsidize this extraction.

Real Protocols and Tools Involved in Sandwich Attacks

Sandwich attacks are chain-agnostic where a public mempool exists. Key protocols and tools include:

• Uniswap V2 / V3 / SushiSwap / PancakeSwap – Common targets due to their constant-product AMM design and high liquidity.
• Flashbots – Used by MEV searchers to submit bundles privately to block builders, reducing competition and ensuring execution.
• Mempool data providers (e.g., bloXroute) – Provide fast mempool data and transaction simulation used by MEV bots.
• Private mempool services (e.g., Flashbots Protect, Eden Network) – Let users submit transactions privately, reducing sandwich risk but not eliminating it entirely.
• CowSwap and Uniswap X – Use batch auctions or off-chain order matching to hide order flow from miners, protecting traders and indirectly LPs.

LPs do not use any tool per se; they are passive. But understanding the ecosystem helps LPs choose where to provide liquidity (e.g., on CowSwap, MEV is reduced because orders are settled via batch auctions with competition).

Comparison: Sandwich Attacks vs Other LP Exploits

Sandwich attacks are unique because they are persistent and exploitative rather than market-driven. LPs must treat them as a routine cost of doing business unless they take active steps to avoid pools with high MEV.

Defensive Strategies for Liquidity Providers

Although LPs lack the attacker’s informational edge, they can reduce exposure:

• Use pools with MEV resistance: Protocols like CowSwap (using batch auctions) can mitigate sandwich attacks. Uniswap v4 hooks allow dynamic fees that could be adjusted per trade, but are not yet widely deployed.
• Provide liquidity in stable pools (e.g., USDC/DAI): Slippage is minimal, so sandwich profit is near zero. However, stable pairs attract arbitrageurs for price stability, not large volatile trades.
• Use concentrated liquidity with wide ranges: In Uniswap V3, a wide range reduces leverage and thus the impact of a single sandwich. But this also lowers fee efficiency.
• Utilize private RPC endpoints: Submit transactions via Flashbots Protect so your trades are not seen by public mempool. This protects your own trades, not your LP position, but reduces the number of potential sandwich triggers from your own activity.
• Monitor and adjust: LPs can use tools like Zapper to track performance and detect abnormal losses indicative of sandwich attacks. Exit if losses exceed fees.

No defense is perfect; the best approach is to understand the risks and only provide liquidity when fee rewards sufficiently compensate for expected sandwich losses.

Future Outlook: Protocol-Level Mitigations

The DeFi ecosystem is actively working to reduce sandwich attacks. Key developments:

• Order flow auctions (OFAs): Platforms like Flashbots are building MEV-Share, allowing users to auction their order flow to searchers, capturing some MEV for themselves while reducing adversarial sandwiching.
• Intent-based architectures: Anoma, Uniswap X, and CoW Protocol let users specify trading intents rather than specific swap paths, hiding details from the mempool until settlement. This makes sandwiching much harder.
• Cross-chain MEV mitigation: LayerZero and other bridges may incorporate protections, but LPs should be careful when providing liquidity on new chains with immature infrastructure.
• Dynamic fees and AMM redesign: New AMMs like Trader Joe v2 (Liquidity Book) use discrete bins that can front-run detection; future designs may incorporate anti-MEV mechanisms.

LPs should pay attention to which protocols adopt these technologies, as they can drastically reduce the asymmetric information advantage that attackers currently enjoy.

Conclusion: Key Takeaways for Liquidity Providers

Sandwich attacks are a persistent threat to LPs due to the fundamental information asymmetry between passive liquidity provision and active mempool monitoring. LPs must measure not just fee yield but also invisible MEV losses.

To thrive, LPs should diversify across protocols, favor those with MEV protection, and regularly audit their real returns. Education is the first step: understanding that every large swap on a public AMM is a potential sandwich target. By adjusting strategies and choosing the right marketplaces, LPs can reduce exploitation and earn more predictable returns.

Common mistakes to avoid

• Assuming that earning high fees automatically covers sandwich losses – many LPs underestimate cumulative extraction.
• Providing liquidity on low-liquidity pools (e.g., new tokens) where even small trades cause high slippage, inviting sandwich attacks.
• Using narrow price ranges in Uniswap V3 without considering that a single sandwich can push price out of range, losing all fee earning potential.
• Ignoring the role of the mempool and using public RPCs for personal trades, which also triggers more sandwiches on the pool.
• Not monitoring actual returns vs. expected returns; failing to exit a pool that is consistently net negative due to MEV.
• Believing that stablecoin pools are completely safe – while sandwich profit is tiny, frequent small losses still add up over time.

Frequently asked questions

Related reading

• Front Running
• Impermanent Loss
• Liquidity Pool
• Sandwich Attack
• Advanced Concentrated Liquidity Uniswap V4
• Impermanent Loss Hedging Options
• Flash Loan
• Liquid Staking