Detecting MEV & Sandwich Attacks On-Chain: A Practical Methodology

Canonical version: rantum.xyz

A practical methodology for separating adversarial extraction from normal execution cost — and why the naive approach gets it badly wrong.

The Challenge

Sandwich attacks are the most common form of on-chain MEV against retail traders. A bot spots a pending swap in the mempool, inserts a frontrun buy just before it and a backrun sell just after — capturing the price impact the victim caused, at the victim’s expense. The victim’s trade executes at a worse price than expected, and the difference flows to the bot.

The problem for anyone trying to measure this: sandwich attacks are invisible in standard analytics. They look like normal slippage. A $10,000 swap that gets sandwiched shows up in a dashboard as “executed at 42 bps of slippage” — indistinguishable from a large trade in a thin pool. Without a methodology that isolates the adversarial component, every slippage number is a mix of real execution cost and extraction, and you cannot act on either.

This matters most to DEX aggregators, L2 foundations, and grant programs that are trying to evaluate which protocols actually protect their users — and which ones quietly route flow into sandwichable positions.

What We Built

ClearTrace’s MEV detection layer covers Ethereum, Base, Arbitrum, and Optimism. It identifies victim swaps, quantifies the volume sandwiched over rolling 7-day windows, and reports MEV exposure as a distinct metric — kept separate from the execution quality score so they can be read independently.

The v1 Mistake: tx_hash Is Not Execution Order

The first cut at sandwich detection tried to reconstruct in-block ordering directly from dex.trades, using tx_hash comparisons as a proxy for sequencer position — treating a lower hash as an earlier transaction. That logic is wrong: tx_hash is a cryptographic hash, not a sequence number. Sorting by hash produces an arbitrary permutation of transactions, not the order they were actually included in the block. A "sandwich" identified this way is noise.

The correct source is Dune’s curated dex.sandwiched table, built from Dune's Spellbook detection macro — which uses actual evt_index (on-chain event position) to reconstruct frontrun → victim → backrun triples across every block. Switching to this source eliminated the false positives entirely.

The Detection Query

WITH victims AS (
    SELECT
        blockchain,
        block_time,
        project,
        token_pair,
        amount_usd,
        tx_hash,
        tx_from
    FROM dex.sandwiched
    WHERE block_time >= NOW() - INTERVAL '7' DAY
      AND blockchain IN ('ethereum', 'base', 'arbitrum', 'optimism')
      AND amount_usd BETWEEN 1 AND 100000000
),
enriched AS (
    SELECT
        v.*,
        COUNT(*) OVER () AS total_attacks_7d,
        SUM(amount_usd) OVER () AS total_sandwiched_usd_7d,
        COUNT(*) OVER (PARTITION BY blockchain) AS chain_attacks_7d,
        SUM(amount_usd) OVER (PARTITION BY blockchain) AS chain_sandwiched_usd_7d
    FROM victims v
)
SELECT *
FROM enriched
ORDER BY block_time DESC
LIMIT 500;

The window columns mean the 7-day KPIs are accurate across the full dataset — not just the 500-row page — so a per-chain breakdown shows the right totals without a second query.

Separating MEV from Slippage

Slippage and MEV exposure are both costs, but they have different causes and different remedies. ClearTrace scores them separately. Execution quality compares each fill’s realized price against a 1-minute VWAP oracle — both legs valued explicitly against prices.usd, avoiding the circular-pricing trap of comparing against Dune's internally derived amount_usd.

The benchmark across major aggregators:

| Aggregator | Median slippage vs VWAP | MEV toxicity | Revert rate | | — -| — -| — -| — -| | CoW Swap | −0.1 bps | Zero | 0.0% | | 1inch | −0.4 bps | Low | 1.2% | | Odos | −0.6 bps | Medium | 2.1% |

CoW Swap’s zero MEV toxicity is structural: its batch-auction settlement mechanism bypasses the public mempool entirely, making sandwich attacks impossible by design.

The L2 Finding: Structural Protection vs Coverage Gap

Arbitrum and Optimism show near-zero sandwich counts compared to Ethereum. This is worth stating carefully — two very different things can produce near-zero counts: the detector runs and finds little (structural protection), or the detector has no data for the chain (a coverage gap that would be wrong to call protection).

The verification checks active_days alongside sandwich_victims_30d. If the chain has ~30 active days but tiny victim counts, the detector is running and genuinely finding almost nothing — the Arbitrum case, consistent with its FCFS private-mempool sequencing that eliminates the pending mempool window bots need to frontrun.

What It Shows

The ability to detect adversarial extraction in data that’s structured to hide it — and to distinguish a real signal from an absence of data. The v1 → v2 rewrite is the concrete example: identifying why the wrong model was wrong (hash ≠ sequence) required understanding the underlying data structures deeply enough to know what to use instead.

What It Proves

That you can build measurement infrastructure that holds up to scrutiny. ClearTrace’s MEV layer gives L2 foundations, DEX aggregators, and grant programs a neutral answer to a question their own analytics cannot answer honestly: how much of the slippage users pay is real execution cost, and how much is being extracted by bots?

Andrew Maury is the founder of Rantum, a senior data science & ML studio. He previously scaled data infrastructure at 0x Labs and contributed to Dune’s open-source Spellbook. ClearTrace is live at cleartracedata.com.