MEV and On-Chain Execution for Crypto Quants

MEV (Maximal Extractable Value) is profit extracted by reordering, inserting, or censoring transactions within a block — primarily on Ethereum-style chains. For crypto quants, MEV is the on-chain analogue of latency arbitrage and adverse selection: your swap is an option gifted to searchers unless you execute defensively. This article covers MEV types, execution tactics, and research implications.

Where MEV comes from

Users submit transactions to a public mempool. Searchers simulate profitable bundles. Builders/validators include the highest-paying bundles. Your trade's price impact is visible before it is finalized.

MEV type	Mechanism
Sandwich	Front-run your buy, let you lift price, back-run sell
Back-run	Trade after a large swap moves a pool
Arb	Cross-DEX or CEX–DEX price gaps in-block
Liquidation	Race to liquidate undercollateralized positions

your_swap_slippage ≈ honest_impact + sandwich_tax + priority_fee

Sandwiching in one diagram

Searcher buy → Your buy (worse price) → Searcher sell

You set amountoutmin too loose → sandwich space widens. You set it tight → tx reverts more often. That tradeoff is the core execution parameter on AMMs.

Defensive execution

Tight slippage limits — reduce sandwich surface; accept higher fail rate
Private orderflow — Flashbots Protect / private RPCs / intent solvers so txs

skip the public mempool

RFQ / intent DEXs — fillers compete off-chain; less mempool exposure
Split size — multiple blocks; watch impact
Avoid thin pools — low liquidity → huge sandwich P&L for searchers

def amm_min_out(amount_in: float, reserve_in: float, reserve_out: float,
                fee: float = 0.003, slip_tol: float = 0.005) -> float:
    """Uniswap-v2 style minOut with slippage tolerance."""
    ain = amount_in * (1 - fee)
    out = reserve_out * ain / (reserve_in + ain)
    return out * (1 - slip_tol)

If slip_tol is 1–2% on a large trade in a medium pool, you are often paying MEV.

CEX vs DEX for quants

	CEX	DEX / on-chain
Latency game	Colo, API (CCXT)	Block time, priority gas
Adversary	Faster HFT	Searchers + builders
Settlement	Custodial credit	Atomic, capital intensive
Failures	Rejects, partials	Reverts, MEV

Many "DEX arb" bots are MEV searchers. If your strategy submits vanilla router swaps, you are inventory — not the searcher.

Measuring MEV cost in research

Backtests that use mid pool price at block t without adversary simulation overstate edge. Better:

Assume sandwich takes X% of your tolerance band
Use historical realized execution from private relays if available
Penalize size by pool depth (similar to ADV participation on CEX)

def effective_edge(gross_bps: float, slip_tol_bps: float,
                   mev_capture_frac: float = 0.5) -> float:
    """Crude net edge after searchers eat part of slippage budget."""
    return gross_bps - mev_capture_frac * slip_tol_bps

MEV as a strategy (advanced)

Running searchers requires:

Simulation infrastructure and bundle submission
Latency to builders
Capital for inventory and failed gas
Constant adversary competition (capacity

collapses as more searchers enter)

This is closer to HFT than to medium-frequency factor trading. Most readers should focus on not being sandwiched, not on becoming a searcher.

Stablecoin and gas risk

Priority fees spike in congestion; liquidations cascade with depeg events. Gas is a transaction cost regime-dependent — model it like a vol-of-cost term in TCA.

Key takeaways

MEV extracts value from visible pending transactions — especially AMM swaps
Tight slippage + private orderflow are the main defenses
Naive DEX backtests ignore sandwich tax and overstate alpha
Searcher strategies are HFT-competitive; most quants should optimize execution instead
Treat gas and MEV as state-dependent costs, not a flat bps line item