MEV

On-chain MEV detector. Five patterns are detected live: atomic arbitrage and wash trading from the canonical trade stream, liquidation cascades from Blend auctions correlated with oracle updates, and sandwich / oracle-update sandwich using intra-ledger transaction ordering (tx_index) resolved from the raw ledger lake. Every event records evidence plus a note stating exactly what is — and is not — claimed.

Detected MEV events

All kinds, newest first. Positional/structural evidence — direction and profit are never inferred; each event's detail.note states exactly what is claimed.

Loading…

What we look for

Pattern catalogue — evidence-first, false-positive-tolerant

Atomic arbitrage

live

One taker trades a closed asset cycle (≥2 legs returning to the starting asset) inside a single transaction, across pools/venues. The structure itself is the evidence.

Profit is not estimated — leg direction is ambiguous in the served rows.

Sandwich

live

One account's trades in two different transactions bracket another account's trade on the same pair within one ledger. Transaction application order (tx_index) comes from the raw ledger lake — the signal the served rows don't carry.

Positional signature only: front/back direction opposition is not verified, so a bracketing DCA bot can look identical. Candidates, not verdicts.

Oracle-update sandwich

live

One account's trades sit on BOTH sides (by tx_index) of an on-chain oracle update for an asset those trades touch, all within a single ledger — e.g. positioning around a Reflector price write.

The trade/update relationship is timing evidence, not proven profitability.

Liquidation cascade

live

A Blend liquidation-auction fill following another fill against a different position within a 12-ledger window, with an on-chain oracle update inside the bracket.

Correlation, not causality: the cluster + oracle timing is recorded; "the first liquidation moved the price" is not proven.

Wash trading

live

Self-crosses (the same account is maker AND taker of one trade) and round trips (two accounts repeatedly filling each other in both directions on one pair within a UTC day).

Round trips are also what tight two-party market-making looks like; self-crosses are unambiguous.

Why this matters for pricing

MEV trades show up as ordinary swaps on the wire. Without detection, a sandwich pair would inflate observation count on the same pair the victim contributed to, and an oracle- update sandwich would skew the oracle reading the liquidation price was set against.

Detected events get a per-trade flag in mev_events (migration 0021). The aggregator can then optionally exclude flagged trades from VWAP — the policy lever lives at the aggregator, not the decoder, so we keep the raw observation and let downstream methodology decide.

Known limits

Detection is deliberately conservative about what it claims. The served trade rows carry no direction (buy vs sell), so no detector asserts front-run/back-run intent or estimates attacker profit — profit_usd is always null and each event's detail.notesays what the evidence actually shows. Sandwich kinds depend on the lake's transaction-order index and degrade to not-detected (never guessed) when a transaction isn't indexed yet. An oracle_deviation kind remains reserved. Sub-invocation call-tree attribution (who invoked whom inside a transaction) awaits diagnostic-event capture in the lake. For the underlying methodology see the research index.