Frontrunning & Sandwich Attacks

Frontrunning & Sandwich Attacks: Complete Guide to Detection and Prevention

Frontrunning attacks exploit the transparent nature of blockchain mempools to steal value from unsuspecting users. Imagine playing a game of poker where everyone can see your cards before you even place a bet. That’s essentially what happens on public blockchains every second of every day. With over $1.2 billion extracted through MEV (Maximal Extractable Value) and frontrunning on Ethereum alone, and sandwich attacks accounting for 51% of all MEV volume in 2025, this is one of the most profitable - and persistent - threats in DeFi.

Whether you're a smart contract auditor looking to secure protocols or a Web3 developer building the next big DEX, understanding how these predatory bots operate is non-negotiable.

This comprehensive guide covers everything from basic mempool sniping to the sophisticated sandwich attacks that systematically drain millions from DEX traders every single month. Let's dive into the dark forest of the mempool.

What Is a Frontrunning Attack?

A frontrunning attack occurs when a malicious actor (usually an automated bot) monitors the blockchain's public pending transaction pool (the mempool). When it spots a profitable transaction waiting to be processed, the bot submits its own identical or counter-transaction with a significantly higher gas fee. This bribes the network validators to execute the attacker's transaction before the victim's.

By exploiting this advance knowledge of a transaction that will change the blockchain's state, the attacker steals the opportunity. This usually means buying an asset right before a large purchase pushes its price up, or sniping a lucrative protocol reward before the legitimate user can claim it.

The Stock Market Analogy

Imagine a shady stockbroker who receives a client's order to buy 1 million shares of a tech company. The broker knows this massive buy order will instantly drive the stock price up. Before executing the client's order, the broker secretly buys a chunk of shares for themselves at the current low price. The client’s massive order goes through, pumping the price, and the broker immediately dumps their shares at the inflated price for a risk-free profit.

That's frontrunning. It's highly illegal and heavily penalized in traditional finance (TradFi). But on a public blockchain? Every pending transaction is visible to anyone running a node, and there's no SEC regulator to stop it from happening. It’s strictly a battle of code and gas fees.

The Mempool (Memory Pool): On Ethereum, the mempool is essentially a waiting room that holds all unconfirmed transactions in plain sight. Specialized MEV bots monitor this pool 24/7, relentlessly scanning for profitable opportunities to exploit in milliseconds.

Why Frontrunning Attacks Are So Dangerous

Frontrunning and MEV extraction have caused staggering cumulative losses across DeFi:

Frontrunning is one of the OWASP Smart Contract Top 10 vulnerabilities and accounts for over half of all MEV extraction on Ethereum.

Types of Frontrunning

Real-World Frontrunning Exploits

The MIT Brothers: $25 Million in 12 Seconds (April 2023)

In what became the first U.S. criminal prosecution of blockchain frontrunning, two MIT-educated brothers - Anton (24) and James (28) Peraire-Bueno - exploited a vulnerability in MEV-boost relay software.

How they did it:

1. Deployed "bait transactions" to lure MEV sandwich bots

2. Exploited a flaw in MEV-boost that let their validator reorder transactions within a block

3. Stole $25 million in just 12 seconds by intercepting the sandwich bots' own strategy

4. Used shell companies and concealed identities to launder the proceeds

The brothers were charged with wire fraud and conspiracy, each facing up to 20 years in prison. This case proved that MEV exploitation can cross the line from "gray area" into criminal activity.

jaredfromsubway.eth: The Most Notorious MEV Bot (2023–2024)

The most famous sandwich bot in Ethereum history, jaredfromsubway.eth earned over $22 million in profit since March 2023.

At its peak during the PEPE/WOJAK meme coin frenzy, this single bot consumed 7% of all Ethereum gas in a 24-hour period. In one week alone after April 17, 2023, it netted $2.7 million.

In 2024, the operator returned with "Jared 2.0" - an upgraded bot targeting Ethena (ENA) traders.

A single sandwich attack in January 2025 generated over $800,000 in profit - demonstrating the massive scale of MEV extraction.

The Bancor Rescue Race (June 2020)

When the 1inch Exchange team discovered a critical vulnerability in Bancor's smart contracts, a frontrunning race ensued:

Total damage: $545,423 in user funds drained - including $135,229 stolen by automated frontrunning bots that simply copied Bancor's own rescue transactions.

The "Salmonella" Counter-Attack (March 2021)

In a creative reversal, developer Nathan Worsley deployed a poisoned ERC20 token called "Salmonella" that appeared normal but secretly returned only 10% of expected tokens to anyone other than the owner.

He created bait transactions with low fees and high slippage to lure sandwich bots. Ethermine's frontrunning bots fell into the trap, losing 103 ETH (~$250,000). It was a rare case of a victim turning the tables on frontrunners.

Want to execute frontrunning attacks yourself in a safe lab? The Smart Contract Hacking course includes hands-on MEV and frontrunning exercises where you'll exploit vulnerable contracts - exactly like real security researchers do.

How Frontrunning Attacks Work: Step-by-Step

Understanding the mempool and transaction ordering is crucial. Here's how a basic displacement frontrunning attack unfolds.

The Mempool: A Transparent Waiting Room

When you submit a transaction on Ethereum, it doesn't execute immediately. Instead:

1. Your transaction enters the public mempool - visible to anyone running a node

2. It propagates to ~99% of network nodes within seconds via gossip protocol

3. A block builder selects transactions to include in the next block

4. Transactions with higher priority fees (tips) are included first

This 12-second window between submission and block inclusion is the attack surface.

The Attack Flow

The Attack Phases

Frontrunning Vulnerable Code Example

Let's examine the classic displacement frontrunning vulnerability - a contract that rewards whoever solves a digital puzzle first. It sounds fun, but on a public blockchain, it's a disaster waiting to happen.

🚨 Warning: This contract is intentionally vulnerable. Never use this pattern in production!

The Vulnerable Reward Contract

// VULNERABLE CONTRACT - DO NOT USE IN PRODUCTION
pragma solidity ^0.8.20;

contract VulnerableReward {
    bytes32 public constant targetHash =
        0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2;

    constructor() payable {}

    // VULNERABILITY: Solution is visible in the mempool before execution
    function solve(string memory solution) public {
        require(
            keccak256(abi.encodePacked(solution)) == targetHash,
            "Wrong answer"
        );

        // Winner takes the entire reward
        (bool sent, ) = msg.sender.call{value: 10 ether}("");
        require(sent, "Transfer failed");
    }
}

Why Is This Vulnerable?

The core issue here is transparency:

1. Alice desperately works to find the solution, discovers it is "Ethereum", and calls solve("Ethereum").

2. Her transaction enters the public mempool with the plaintext solution completely visible in the calldata.

3. An attacker's bot instantly decodes the calldata and spots the string "Ethereum".

4. The bot immediately submits its own solve("Ethereum") transaction with a 10x higher gas price.

5. The miners/validators (greedy for the higher fee) execute the attacker's transaction first, handing them the 10 ETH reward.

6. Alice's legitimate transaction finally executes but reverts, because the contract balance has already been drained.

The victim did everything right. They solved the puzzle and submitted the valid transaction. But the transparent nature of the mempool allowed a sniper bot to swoop in and steal their hard-earned reward.

The Sandwich Attack: Advanced Frontrunning Example

Sandwich attacks are the bread and butter (pun intended) of frontrunning on Decentralized Exchanges (DEXes). Here's exactly how they drain traders.

Vulnerable DEX Swap (No Slippage Protection)

// VULNERABLE CONTRACT - DO NOT USE IN PRODUCTION
pragma solidity ^0.8.20;

contract VulnerableSwap {
    uint256 public reserveA;
    uint256 public reserveB;

    // Constant product AMM: reserveA * reserveB = k
    function swapAforB(uint256 amountA) external returns (uint256 amountB) {
        uint256 amountInWithFee = amountA * 997; // 0.3% fee
        amountB = (amountInWithFee * reserveB) /
            (reserveA * 1000 + amountInWithFee);

        // VULNERABILITY: No minimum output check! (Slippage protection missing)
        // Attacker can manipulate reserves before this executes
        // Transfer tokens...
    }
}

The Sandwich Attack Flow

{
  "title": "🥪 The sandwich: watch the bot bracket Alice's swap",
  "stage": { "width": 920, "height": 440 },
  "nodes": [
    { "id": "mempool", "label": "Public Mempool", "role": "pending txs are visible", "emoji": "📡", "x": 360, "y": 40, "color": "slate" },
    { "id": "victim", "label": "Alice (Victim)", "role": "swaps 40 ETH", "emoji": "🧑", "x": 60, "y": 300, "color": "cyan" },
    { "id": "pool", "label": "DEX Pool", "role": "1,000 ETH / 2,000,000 USDC", "emoji": "🏊", "x": 380, "y": 300, "color": "purple" },
    { "id": "attacker", "label": "Attacker Bot", "role": "front-run + back-run", "emoji": "🤖", "x": 720, "y": 300, "color": "red" }
  ],
  "links": [
    { "from": "victim", "to": "mempool" },
    { "from": "mempool", "to": "attacker" },
    { "from": "attacker", "to": "pool" },
    { "from": "victim", "to": "pool" }
  ],
  "nets": [
    { "id": "atk", "label": "Attacker Net" },
    { "id": "victim", "label": "Alice vs fair price" }
  ],
  "legend": [
    { "cls": "call", "label": "observe / call" },
    { "cls": "token", "label": "token swap" },
    { "cls": "sig", "label": "slippage guard" },
    { "cls": "fail", "label": "reverted / blocked" }
  ],
  "scenarios": {
    "Vulnerable (no slippage)": [
      { "note": "Alice broadcasts a swap: <b>40 ETH</b>, expecting ~78,431 USDC at the fair price. The transaction sits in the public mempool first.", "hi": ["victim","mempool"], "bal": { "victim": "40 ETH", "pool": "fair price", "attacker": "watching" }, "net": { "atk": "$0", "victim": "fair: 78,431" }, "chip": { "from": "victim", "to": "mempool", "label": "📢 swap 40 ETH", "cls": "call" } },
      { "note": "The bot spots the pending swap and copies it with <b>higher gas</b> so its own transactions mine first and last.", "hi": ["mempool","attacker"], "chip": { "from": "mempool", "to": "attacker", "label": "👀 sees pending tx", "cls": "call" } },
      { "note": "<b>Front-run:</b> the bot buys first - 18.59 ETH in - pushing ETH's price along the curve before Alice trades.", "tone": "bad", "hi": ["attacker","pool"], "bal": { "pool": "price skewed ↑" }, "net": { "atk": "-18.59 ETH" }, "chip": { "from": "attacker", "to": "pool", "label": "① buy 18.59 ETH", "cls": "token" } },
      { "note": "Alice's swap now fills on the worse price: 40 ETH for only <b>76,712 USDC</b> - she is short 1,719 USDC versus the fair quote.", "tone": "bad", "hi": ["victim","pool"], "bal": { "victim": "76,712 USDC" }, "net": { "victim": "-1,719 USDC" }, "chip": { "from": "victim", "to": "pool", "label": "② swap 40 ETH", "cls": "token" } },
      { "note": "<b>Back-run:</b> the bot immediately sells the USDC it just bought back into the pool, receiving 19.45 ETH.", "hi": ["attacker","pool"], "chip": { "from": "attacker", "to": "pool", "label": "③ sell back", "cls": "token" }, "net": { "atk": "+0.86 ETH" } },
      { "note": "The sandwich closes: the bot nets <b>~0.86 ETH</b> at zero market risk, and Alice silently ate the 1,719 USDC of slippage.", "tone": "bad", "hi": ["attacker","victim"], "bal": { "attacker": "+0.86 ETH", "victim": "lost 1,719 USDC" }, "net": { "atk": "+0.86 ETH", "victim": "-1,719 USDC" } }
    ],
    "Fixed (slippage protection)": [
      { "note": "Alice sends the same 40 ETH swap, but now with <b>minOut = 78,000 USDC</b> - a slippage guard that reverts if she would receive less.", "hi": ["victim","mempool"], "bal": { "victim": "40 ETH", "attacker": "watching" }, "chip": { "from": "victim", "to": "mempool", "label": "📢 swap + minOut", "cls": "sig" } },
      { "note": "The bot front-runs exactly as before, buying first to skew the price.", "hi": ["attacker","pool"], "chip": { "from": "attacker", "to": "pool", "label": "① front-run buy", "cls": "token" }, "net": { "atk": "-18.59 ETH" } },
      { "note": "Alice's swap would now return only 76,712 USDC - below her 78,000 minimum - so the swap <b>reverts</b>. She loses nothing but gas.", "tone": "ok", "hi": ["victim","pool"], "bal": { "victim": "40 ETH (kept)" }, "net": { "victim": "no loss" }, "chip": { "from": "victim", "to": "pool", "label": "② revert < minOut", "cls": "fail" } },
      { "note": "The bot is now stuck holding USDC it overpaid for, and unwinding only burns gas. With slippage limits, the sandwich stops being profitable.", "tone": "ok", "hi": ["attacker"], "bal": { "attacker": "stuck inventory" }, "net": { "atk": "≤ 0 (gas lost)" } }
    ]
  }
}

Real Sandwich Attack Example

Let's look at a Uniswap pool containing 1,000 ETH and 2,000,000 USDC.

The innocent scenario (no attack):

• Alice swaps 40 ETH → receives an expected ~78,431 USDC.

The nightmare scenario (with sandwich attack):

1. The attacker front-runs Alice: swaps 18.59 ETH → receives ~36,320 USDC (pumping the price of USDC).

2. Alice's original swap executes: 40 ETH → receives only ~76,712 USDC (she lost 1,719 USDC!).

3. The attacker back-runs Alice: sells the 36,320 USDC back to the pool → receives ~19.45 ETH.

4. Attacker's net profit: ~0.86 ETH (≈1,719 USDC) for literally zero market risk.

In real-world testing, victims routinely lose dozens of tokens per trade while attacker bots rake in the difference. What's worse? These bots execute thousands of attacks every single day.

A Protocol-Level Vulnerable Pattern

This isn't just theory. Here is a pattern taken straight from real audit findings (like Sherlock and Code4Rena) demonstrating how protocols inadvertently enable sandwich attacks:

// VULNERABLE - From a real Sherlock audit finding (2024)
// Missing slippage protection on a Uniswap Router call
IUniswapRouterV2(SUSHI_ROUTER).swapExactTokensForTokens(
    toSwap,
    0,                    // 🚨 VULNERABLE: accepts ANY output amount!
    path,
    address(this),
    type(uint256).max     // 🚨 VULNERABLE: no deadline!
);

The two critical, fatal flaws here:

• amountOutMin = 0 means the swap will passively accept any output amount - even just 1 wei!

• deadline = type(uint256).max means the transaction never expires, allowing a malicious miner or bot to hold it and execute it at the most mathematically destructive moment.

Ready to write exploits like this yourself and learn how to defend against them? The Smart Contract Hacking course covers frontrunning, sandwich attacks, and MEV in-depth with hands-on, real-world scenarios. Learn directly from JohnnyTime (12+ years in cybersecurity) and Trust (#1 Code4rena warden).

How to Prevent Frontrunning Attacks

Preventing frontrunning requires a layered defense approach. You must combine smart contract design patterns, robust infrastructure solutions, and operational awareness.

Prevention Effectiveness Comparison

Frontrunning Secure Code Examples

Secure Pattern 1: Commit-Reveal for Reward Contracts

// SECURE CONTRACT - Production-ready
pragma solidity ^0.8.20;

contract SecureReward {
    struct Commit {
        bytes32 solutionHash;
        uint256 commitTime;
        bool revealed;
    }

    bytes32 public targetHash =
        0x564ccaf7594d66b1eaaea24fe01f0585bf52ee70852af4eac0cc4b04711cd0e2;
    address public winner;
    bool public ended;
    mapping(address => Commit) public commits;

    event SolutionCommitted(address indexed solver);
    event SolutionRevealed(address indexed solver);
    event RewardClaimed(address indexed winner, uint256 amount);

    constructor() payable {}

    // STEP 1: Commit a hash that includes msg.sender
    function commitSolution(bytes32 _solutionHash) external {
        require(!ended, "Already solved");
        require(commits[msg.sender].commitTime == 0, "Already committed");

        commits[msg.sender] = Commit({
            solutionHash: _solutionHash,
            commitTime: block.timestamp,
            revealed: false
        });
        emit SolutionCommitted(msg.sender);
    }

    // STEP 2: Reveal the solution (must be a different block)
    function revealSolution(
        string memory _solution,
        string memory _secret
    ) external {
        require(!ended, "Already solved");
        Commit storage commit = commits[msg.sender];
        require(commit.commitTime != 0, "Not committed");
        require(commit.commitTime < block.timestamp, "Same block");
        require(!commit.revealed, "Already revealed");

        // Hash includes msg.sender - attacker can't copy this
        bytes32 solutionHash = keccak256(
            abi.encodePacked(msg.sender, _solution, _secret)
        );
        require(solutionHash == commit.solutionHash, "Hash mismatch");
        require(
            keccak256(abi.encodePacked(_solution)) == targetHash,
            "Wrong answer"
        );

        commit.revealed = true;
        winner = msg.sender;
        ended = true;

        (bool sent, ) = payable(msg.sender).call{value: address(this).balance}("");
        require(sent, "Transfer failed");
        emit RewardClaimed(msg.sender, address(this).balance);
    }
}

Security Features at a Glance

Secure Pattern 2: DEX Swap with Slippage Protection

// SECURE CONTRACT - Production-ready
pragma solidity ^0.8.20;

contract SecureSwap {
    uint256 public reserveA;
    uint256 public reserveB;

    event Swap(
        address indexed user,
        uint256 amountIn,
        uint256 amountOut,
        uint256 deadline
    );

    function swapAforB(
        uint256 amountA,
        uint256 minAmountB,   // PROTECTION: User sets minimum output
        uint256 deadline       // PROTECTION: Transaction expiration
    ) external returns (uint256 amountB) {
        // STEP 1: CHECKS
        require(block.timestamp <= deadline, "Transaction expired");
        require(amountA > 0, "Invalid input amount");
        require(minAmountB > 0, "Set a minimum output");

        // STEP 2: Calculate output
        uint256 amountInWithFee = amountA * 997;
        amountB = (amountInWithFee * reserveB) /
            (reserveA * 1000 + amountInWithFee);

        // STEP 3: Enforce slippage protection
        require(amountB >= minAmountB, "Slippage tolerance exceeded");

        // STEP 4: Execute transfer...
        emit Swap(msg.sender, amountA, amountB, deadline);
    }
}

The require(amountB >= minAmountB) check is the critical defense. If a sandwich attacker front-runs and moves the price, the victim's swap will revert because the output falls below slippage tolerance - making the sandwich attack unprofitable.

Advanced Frontrunning Variations

As the MEV ecosystem has matured, attackers have developed increasingly sophisticated techniques beyond basic displacement.

Comparing Advanced Attack Types

Real Audit Findings (2024)

Frontrunning vulnerabilities continue to appear in production protocols. Here are findings from Sherlock and Code4rena audits:

The ERC-20 Approve Race Condition

A lesser-known but critical frontrunning vector exists in the standard approve() function:

// User wants to change approval from 100 to 50
token.approve(spender, 50);

The attack:

1. Spender sees the approve(50) transaction in the mempool

2. Spender front-runs with transferFrom() for the current 100 allowance

3. After victim's approve(50) executes, spender calls transferFrom() again for 50

4. Result: Spender extracts 150 tokens instead of the intended 50

Prevention: Use increaseAllowance() / decreaseAllowance() from OpenZeppelin, or reset approval to 0 before setting the new value.

The MEV Supply Chain

Understanding who profits from frontrunning reveals the full ecosystem:

~90% of Ethereum validators use MEV-Boost to outsource block construction. This means most blocks are built by specialized builders who maximize MEV extraction.

These advanced patterns separate junior auditors from senior researchers. The Smart Contract Hacking course covers frontrunning, sandwich attacks, and MEV alongside flash loans, oracle manipulation, and more. Join 2,000+ security researchers in our Discord community.

Common Misconceptions

Related Vulnerabilities

Frontrunning attacks are deeply connected to other smart contract vulnerability classes. Flash loan attacks often combine with frontrunning strategies - attackers use flash-borrowed capital to execute massive sandwich attacks that would otherwise require millions in upfront capital, making MEV extraction accessible to anyone.

Frontrunning also shares common ground with oracle manipulation attacks. When protocols rely on spot prices from AMM pools, a frontrunner can manipulate the price just before an oracle read, causing the protocol to act on incorrect data. Using time-weighted average prices (TWAP) over longer intervals helps defend against both single-block price manipulation and frontrunning-based oracle attacks.

Frequently Asked Questions About Frontrunning Attacks

Quick Reference: Frontrunning Prevention Checklist

Before deploying any contract with publicly observable valuable transactions:

• Add slippage protection (minAmountOut) to every swap and exchange function

• Set transaction deadlines to prevent stale execution at unfavorable prices

• Use commit-reveal schemes for puzzles, auctions, and secret submissions

• Never hardcode amountOutMin = 0 in protocol-level swap calls

• Use increaseAllowance() instead of approve() to prevent the approval race condition

• Recommend private RPCs (Flashbots Protect, MEV Blocker) to your users

• Consider batch auction integration (CoW Protocol) for high-value swap functionality

• Audit for frontrunning vectors - check every function where transaction ordering matters

• Monitor for sandwich attacks on your protocol's pools post-deployment

• Test MEV scenarios in your test suite with simulated mempool adversaries

Conclusion: The Invisible Tax on Every DeFi User

Frontrunning isn't just a technical curiosity - it's an invisible tax that extracts billions from DeFi users every year:

• $1.2 billion+ extracted through MEV on Ethereum

• $290 million in sandwich attacks in 2025 alone

• 60,000–90,000 sandwich attacks every month

The good news? Frontrunning is increasingly preventable.

Use commit-reveal schemes for sensitive transactions. Enforce slippage protection in your smart contracts. Route transactions through private mempools. The tools exist - you just need to use them.

Don't let your protocol become the next data point in MEV extraction statistics.

Take Your Security Skills to the Next Level

Understanding frontrunning is just the beginning. To become a professional smart contract auditor, you need hands-on experience with real exploit scenarios.

The Smart Contract Hacking course delivers:

• 320+ videos covering frontrunning, flash loans, oracle manipulation, and more

• 40+ hands-on exercises exploiting and securing real contracts

• Expert instruction from JohnnyTime, Trust (#1 Code4rena warden), and Pashov

• 2,000+ member Discord for support and job opportunities

• SSCH Certification to validate your expertise

Our students win audit contests, land security jobs, and earn significant bug bounties. See their success stories.

Start Your Security Researcher Journey

Curious what's covered? Browse the full course curriculum or try a free lesson first.