Front-Running and MEV Audit Vectors

MEV — originally "Miner Extractable Value", now usually "Maximal Extractable Value" — is the profit that can be extracted by anyone with the power to order transactions in a block. Every public blockchain that supports an open mempool and provides ordering control to validators has MEV; Ethereum, with its rich DeFi ecosystem, has the most.

From an auditor's perspective, MEV is not just an economics topic. It is a class of attack vectors against smart contracts that assume the order of transactions is benign, the prices observed at execution time are honest, or the mempool is private. Contracts that make those assumptions are exploitable by anyone with a working mempool listener and a private-mempool relay — capabilities now available as commodity SaaS.

This chapter covers what an auditor needs to know:

  • What MEV is, mechanically. How the mempool, block production, and order flow create the opportunity.
  • The standard attack patterns. Sandwich, back-running, just-in-time (JIT) liquidity, sniping, generalized arbitrage.
  • Smart-contract defenses. Commit-reveal schemes, batching, deadline parameters, slippage bounds, sealed-bid mechanisms.
  • Private mempool routes. Flashbots Protect, MEV-Share, MEV-Blocker, and what they do and don't protect against.
  • Auditor heuristics. What patterns to look for and what questions to ask of any contract that takes a price-sensitive transaction.

Why This Matters for Audits

A contract can be functionally correct — every state transition valid, every invariant preserved — and still expose its users to predictable losses every time they interact with it. Those losses are not "bugs" in the strict sense; they are the gap between the user's intended outcome and the realistic outcome when an adversarial searcher sits between them and finality.

A modern audit should treat MEV exposure as a first-class concern for any contract that:

  • Accepts an asset and gives back another asset at a price determined at execution time (DEX swaps, NFT mints with bonding curves, ICO purchases).
  • Settles a position against an on-chain oracle whose value can be moved by a transaction in the same block.
  • Has a "first valid caller wins" mechanic (liquidations, MEV-style auctions, rebalancing rewards).
  • Exposes a public action that becomes profitable to call at some threshold (oracle update bounties, rebase triggers).

Each of these patterns has known MEV failure modes and known mitigations. The sections that follow walk through them.

Scope Note: L1 vs L2

The MEV landscape differs significantly across chains:

  • Ethereum L1: Public mempool, MEV-Boost-driven block production via builders and relays, mature private-mempool ecosystem (Flashbots Protect, MEV-Share). All classical MEV patterns are live and actively extracted.
  • Optimistic rollups (Optimism, Arbitrum, Base): Currently single-sequencer; no public mempool in the same sense. Front-running by external searchers is largely absent, but sequencer-extractable value (SEV) and reordering by the sequencer is possible and depends on the sequencer's policies.
  • ZK rollups (zkSync, Scroll, Linea, Starknet): Similar to optimistic rollups in mempool/ordering structure; specifics vary by chain.
  • Decentralized sequencer rollups (forthcoming on most L2s): Will gain public-mempool-like properties as sequencing decentralizes. Audits today should not assume the current L2 ordering model is permanent.
  • Other L1s (BNB, Polygon, Avalanche, etc.): Each has its own mempool model and MEV economics; the Ethereum heuristics largely transfer but specifics differ.

For audits scoped to multi-chain deployments, an MEV finding on Ethereum may be a non-issue on Arbitrum today but a known future risk; the report should reflect that.