Sandwich Attack

What Is a Sandwich Attack?

A sandwich attack is a front-running strategy used on blockchain networks where an attacker "sandwiches" a victim's pending trade between two of their own transactions. The attacker buys the target asset before the victim (driving the price up), lets the victim's trade execute at the inflated price, then immediately sells for a profit.

The attack is possible because most blockchains broadcast pending transactions to a public mempool before they are included in a block. Automated bots monitor this mempool, identify profitable swap transactions, and pay higher priority fees (or submit bundles to block builders) to guarantee their transactions execute in the desired order. The victim receives fewer tokens than expected, while the attacker pockets the difference.

Sandwich attacks are one of the most common forms of MEV extraction on Ethereum and Solana. Research from EigenPhi and Cointelegraph found that sandwich attacks account for roughly 51% of all MEV volume on Ethereum as of 2025, with 60,000 to 90,000 attacks occurring per month: more than one per block on average.

How It Works

A sandwich attack unfolds in three transactions, all typically included in the same block:

1. The attacker's bot detects a pending swap in the mempool (for example, a user buying Token X with ETH on Uniswap)
2. The attacker submits a front-run transaction: buying Token X with a higher gas price or builder tip to ensure it executes before the victim's trade, pushing the price of Token X upward
3. The victim's original swap executes at the now-inflated price, receiving fewer tokens than expected
4. The attacker submits a back-run transaction: immediately selling their Token X at the higher price, capturing the spread as profit

The AMM Price Curve

Sandwich attacks are a direct consequence of how automated market makers (AMMs) calculate prices. Most DEXes use a constant product formula where the product of two token reserves must remain constant:

x * y = k

Where:
  x = reserve of Token X
  y = reserve of Token Y
  k = constant product

Price impact of buying Token Y with amount dx of Token X:
  dy = y - (k / (x + dx))
  new_price = (x + dx) / (y - dy)

Because this formula is deterministic, an attacker can simulate the exact outcome of any trade before committing capital. They calculate the optimal front-run size: large enough to extract meaningful profit, but not so large that gas costs and swap fees consume the gains. The victim's slippage tolerance setting defines the upper bound of how much price impact the attacker can inflict: wider tolerance means a larger attack surface.

Execution Priority

On Ethereum, attackers ensure transaction ordering through MEV infrastructure. Post-Merge, specialized "searchers" submit transaction bundles to block builders with priority tips. The builder includes all three transactions (front-run, victim, back-run) as an atomic bundle in the block. On Solana, attackers use Jito bundles or validator relationships for similar ordering guarantees.

A Real-World Example

In March 2025, a trader lost over $215,000 swapping $220,764 USDC to USDT on Uniswap v3. An MEV bot drained nearly all USDC liquidity from the pool in its front-run trade, causing the victim to receive only $5,271 of USDT instead of the expected amount. The attacker tipped the block builder $200,000 and kept roughly $8,000 in profit. The victim's transaction did not originate from Uniswap's front end (which includes built-in MEV protection and default slippage limits), illustrating the importance of proper tooling.

Scale of the Problem

Sandwich attacks represent a significant tax on DEX users across multiple chains:

On Ethereum, a single operator known as jaredfromsubway.eth has been responsible for roughly 70% of all sandwich attacks, accumulating over $22 million in cumulative profit since March 2023. On Solana, the DeezNode-operated bot executed 1.55 million sandwich transactions in a single 30-day period with an 88.9% success rate.

Protection Methods

Private Transaction Pools

The most effective defense is preventing attackers from seeing your transaction before it lands in a block. Private transaction pools route your swap through a protected channel that bypasses the public mempool:

• Flashbots Protect: routes transactions to a private Flashbots mempool, hiding them from sandwich bots until block inclusion. As of late 2024, it had served over 2.1 million unique Ethereum accounts and shielded $43 billion of DEX volume
• MEV Blocker: built by CoW DAO, it routes transactions through a searcher auction that returns up to 90% of captured back-run value to the user as rebates. It has protected over $60 billion of DEX volume and paid out over 6,100 ETH in cumulative rebates to users

Intent-Based DEX Aggregators

Rather than broadcasting a swap transaction, intent-based systems let users sign an off-chain order that professional solvers fill:

• CoW Swap: users sign off-chain intents settled in batch auctions where all orders clear at a uniform price, eliminating transaction-ordering advantage entirely. No pending transaction ever appears in the public mempool
• 1inch Fusion: users create order intents filled by competing resolvers (market makers) through private, bundled transactions. Uses a Dutch auction pricing model where the rate starts favorable and decreases until a resolver fills it

User-Level Defenses

When using a standard DEX interface, the simplest protection is setting a tight slippage tolerance (for example, 0.5% instead of a higher default). This caps the maximum price deviation the attacker can inflict. If the attacker's front-run would push the price beyond the victim's slippage tolerance, the victim's transaction reverts and the attack fails.

Other user-level strategies include trading on deep liquidity pools (where price impact is minimal), splitting large trades into smaller orders, and using DEX front ends with built-in MEV protection.

Protocol-Level Mitigations

Several protocol designs reduce or eliminate sandwich vulnerability:

• Batch auction mechanisms: all trades in a time window clear at a single price, removing ordering advantage
• Encrypted mempools: pending transactions are encrypted until block commitment, hiding their contents from searchers
• Limit-order systems: execution price is determined by the order itself, not by pool state at execution time
• Higher swap fees: when AMM fees exceed a threshold relative to pool depth and trade size, sandwiching becomes unprofitable

Why Bitcoin Lightning Is Immune

Bitcoin Layer 2 payment networks like Lightning and Spark are architecturally immune to sandwich attacks for several reasons:

• No public mempool for pending swaps: Lightning payments route through private, encrypted channels using onion routing. There is no broadcast of pending transaction intent for bots to observe
• No AMM price curves: Lightning channels do not use liquidity pools or automated market makers. There is no deterministic price impact function to exploit
• Atomic settlement: value transfers directly from sender to recipient through pre-established channel paths using HTLCs. The entire payment either completes or fails: there is no intermediate pending state to manipulate
• No transaction ordering games: payments are routed peer-to-peer rather than bundled into blocks by validators, so there is no block builder who can reorder transactions for profit

This architectural advantage extends to stablecoin payments settled over Lightning-compatible networks. A stablecoin transfer on Spark moves directly between parties without passing through an exploitable ordering layer, making it inherently resistant to the MEV extraction that costs DEX users hundreds of millions of dollars annually.

Regulatory Developments

Regulators are beginning to treat sandwich attacks as a form of market manipulation. In July 2025, the European Securities and Markets Authority (ESMA) formally flagged sandwich attacks and harmful front-running as potential market manipulation under MiCA. The MiCA transitional period ends July 1, 2026, meaning EU-regulated platforms must actively address harmful MEV practices.

On Solana, enforcement has taken a validator-level approach: the Solana Foundation removed validator operators from its delegation program for facilitating sandwich attacks in June 2024. Jito subsequently blacklisted nefarious validators through governance proposals, and Marinade Finance blacklisted over 50 malicious validators to protect $2 billion of delegated stake.

Risks and Considerations

For DEX Users

Any trader using an AMM-based DEX without MEV protection is exposed to sandwich attacks. The risk scales with trade size relative to pool depth: larger trades in shallower pools suffer disproportionately worse execution. Even with protection tools, no solution is perfect: private transaction pools depend on trusted builders, and intent-based systems introduce settlement delays.

For Liquidity Providers

Sandwich attacks create adverse selection for liquidity providers. LPs consistently trade against informed (MEV-extracting) counterparties, which can exacerbate liquidity challenges and reduce returns. Some AMM designs attempt to mitigate this through dynamic fees or oracle-based pricing.

Systemic Implications

The "invisible tax" of sandwich attacks erodes user trust in decentralized trading. When 1.2% of all Ethereum DEX trades are sandwiched, with average losses of 0.41% per affected trade, the cumulative effect discourages retail participation and pushes volume toward centralized exchanges or alternative settlement layers like Lightning that are immune to these exploits.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.