What is MEV exposure in a DeFi swap?

Maximal extractable value — MEV — is the quiet tax on DeFi swaps: value that block builders and searchers can capture by reordering, inserting, or front-running the transactions in a block. For a normal swap it shows up as worse execution than the mid quote suggested, and "MEV exposure" is the modeled estimate of how vulnerable a given route is to that activity at a point in time. This explainer covers what MEV is, how sandwich attacks differ from frontrunning, why a swap can clear below the mid quote, and how a modeled, route-scoped exposure figure is built from public detector signals — read-only decision support, not an execution guarantee.

What MEV actually is

On Ethereum and similar chains, transactions do not settle in the order you send them. Whoever assembles a block — the builder, acting for searchers who bid for position — chooses how to order, insert, or omit the pending transactions. MEV is the profit available from that ordering power. Some of it is benign (arbitrage that keeps prices aligned across pools); some of it comes directly out of a retail swapper's execution.

The key idea is that your swap sits in a public mempool before it confirms. Anyone watching can see the trade you are about to make, simulate its price impact, and build their own transactions around it to capture part of the move. None of that requires breaking anything — it is an emergent property of a transparent, openly ordered system. That is also why it is hard to model precisely: the behavior is adversarial and changes block to block.

Sandwich attacks versus frontrunning

The two forms that matter most for an everyday swap are sandwich attacks and frontrunning. They are related but not identical.

• Frontrunning — a searcher sees your pending buy, places their own buy ahead of it (paying for priority), and lets your trade push the price up before they sell into it. You end up buying at a worse price than you would have a moment earlier.
• Sandwiching — the same idea on both sides. A searcher buys just before your trade and sells just after it, so your swap is the filling between their two transactions. The buy moves the price against you; the sell harvests the difference your trade created.
• Backrunning — a transaction placed immediately after yours to capture a resulting arbitrage. This is often harmless to you, but it is part of the same ordering economy.

A sandwich is essentially a frontrun plus a matching backrun, engineered so your own price impact becomes the searcher's profit. The deeper and more liquid the pool relative to your trade, the less room there is to do this; the thinner the pool or the larger the trade, the more attractive your swap becomes as a target.

Why a swap can clear worse than the mid quote

The mid quote is the midpoint between the best bid and ask on a pool — a clean theoretical price. The price you actually clear at is almost always worse, and MEV is only one of the reasons. It helps to separate the pieces:

• Price impact / slippage — your own trade moves the pool's price as it executes. Bigger trade, thinner pool, more impact. This happens even with no adversary present.
• Swap fee and gas — the pool's fee and the network cost are deducted separately; they are not slippage, though they widen the all-in gap.
• MEV — on top of the mechanical slippage, a sandwich deliberately worsens the price you receive so a searcher can pocket the difference.

So a swap clears below the mid quote partly because of physics (price impact) and partly because of adversaries (MEV). Modeled MEV exposure tries to isolate that second component: how much extra execution erosion is plausible because the route and trade size make you a worthwhile target.

How modeled MEV exposure is estimated

Routescore expresses exposure as a modeled figure tied to a specific route and trade size, built from public detector signals — the same on-chain patterns anyone can observe in confirmed blocks. At a high level, the detector classifies historical swap activity on supported routes (the tell-tale buy-around-buy ordering of a sandwich, for instance), turns that into a base rate of sandwich and frontrun activity for the route, and scopes it to the notional you enter. Larger trades and thinner pools push the modeled exposure up; deeper liquidity pulls it down.

Two properties are deliberate and stated on every artifact:

• Point-in-time — the figure reflects conditions when the model was built, not a live read of the mempool the instant you swap.
• Route-scoped — it describes the named route and size you entered, not your wallet's history and not some global "MEV score."

Inside the Routescore methodology, this becomes a risk penalty that is subtracted from the route-quality grade, alongside slippage, while quality terms like gas efficiency and liquidity depth are added. The output you see is a route-quality grade plus an expected leak figure in basis points for your trade size.

A small worked example makes the shape concrete. The numbers below are illustrative, not a live quote. Imagine a USDC → WETH swap. At an illustrative $5,000 on a deep pool, modeled MEV exposure might land near the low end of the band — you are a small, unappealing target, so the expected leak attributable to MEV is a handful of basis points. Push the same pair to an illustrative $250,000 and the picture changes: your price impact is now large enough to be worth sandwiching, the modeled exposure rises, and the expected leak band widens. Same pair, very different exposure — which is exactly why the figure is scoped to trade size rather than quoted once for the token.

What a modeled figure cannot know

Modeled MEV exposure is necessarily incomplete, and being honest about its blind spots is the point. It cannot see live mempool state at the moment you submit, future block-builder behavior, or shifts in searcher competition — all of which move block to block. It does not know your private settings, your timing, or whether a particular searcher happens to be watching. Unsupported routes and chains are marked as out of scope rather than silently scored, so a coverage gap never reads as a low-risk result. And because the system is adversarial and fast-moving, no tool can guarantee a swap avoids MEV — the figure describes modeled exposure, not a realized outcome, and it is not a guarantee that any single trade will or will not be attacked.

How to act on a high modeled exposure

Treat the exposure figure as pre-decision context, not a verdict. A high modeled number is a reason to look harder before you act, not a prediction about your specific swap. Practical moves:

• Compare routes. Run the same pair and notional across supported route scenarios and see whether a lower-leak alternative exists. Routescore shows the comparison and the caveats and lets you decide; it does not pick a route for you or send anything.
• Resize or split. Because exposure scales with trade size, a smaller clip — or splitting a large order — often lands lower in the modeled band.
• Consider a protected submission path. Where a public protected-RPC option exists for Ethereum mainnet, it is surfaced as external context for you to review and select yourself. Evaluate it on its own terms; no route or RPC can promise that a swap avoids MEV.
• Keep a record. Save the scenario so the route, notional, model version, freshness, and caveats are captured, and attach an outcome label later to see whether the modeled call held up.

Throughout, Routescore stays read-only and non-custodial: it models and compares exposure so you can decide and act in your own venue with your own settings. It never holds, moves, or executes your funds.

Where to go next

• MEV checker — see modeled MEV exposure for a supported route and trade size.
• Route check — compare supported routes side by side at the same notional.
• Methodology — how the score, including the MEV risk penalty, is built.
• Risk disclosure — what the model does not cover and what you are responsible for.