3.11.3 Maximal Extractable Value (MEV)

For most of Ethereum's history, the security model implicitly assumed that the order of transactions in a block was either random or determined by gas-price auctions. Neither assumption is true. Block producers — miners until September 2022, then validators / proposers / builders after the Merge — can include, exclude, and reorder transactions arbitrarily within the blocks they propose. The value they can extract by doing so is called Maximal Extractable Value (MEV), and as of 2026 it represents a multi-billion-dollar annual flow extracted from users by sophisticated actors who control transaction ordering.

For a smart contract developer, MEV matters because it shapes how transactions interact with your protocol. A user submitting a trade to your AMM is, by default, broadcasting their intent to the public mempool, where searchers can detect it, simulate it, and submit transactions ahead of and behind it that capture some of the value the user would otherwise receive. The same user's protocol-level security against bugs may be excellent; their economic security against ordering attacks may be poor. MEV is the security problem that exists at the layer above the contract code.

This subsection covers MEV from the developer's perspective. Not "what is MEV in general" — the topic has substantial dedicated literature. Instead: what design decisions in your protocol affect how much MEV your users lose, and what mitigations exist? The space is changing quickly — private mempools, batch auctions, intents-based architectures, threshold encryption mempools — and a developer building today must choose among options that are themselves under active development.

Section 3.8.7 (Front-Running & MEV Exposure) covers MEV as a vulnerability class. This subsection covers the architectural design problem.

What MEV Is, Concretely

Three concrete patterns capture most extracted value:

1. Arbitrage. A price discrepancy exists between two venues (e.g., ETH is $3000 on Uniswap and $3010 on Curve). A searcher captures the difference. Arbitrage is generally considered beneficial — it keeps prices consistent across venues — and is the cleanest form of MEV.

2. Liquidations. A position becomes liquidatable; multiple searchers compete to perform the liquidation and capture the liquidation incentive. Like arbitrage, this is broadly beneficial (the protocol needs liquidations to happen), but the competition for the liquidation can produce gas wars and other inefficiencies.

3. Sandwich attacks. A user submits a large swap to an AMM. A searcher detects it, submits a buy of the same asset just before (pushing the price up), lets the user's swap execute at the now-worse price, then submits a sell just after (capturing the price difference). The user receives less than they would have in a private execution; the searcher captures the difference minus fees.

These patterns shade into each other. A liquidation is a kind of arbitrage (between the violator's collateral and the market price). A sandwich is a kind of arbitrage with the user's slippage absorbed as profit. The mechanism is the same: the searcher controls execution ordering and extracts value that would otherwise have gone to the user or stayed in the system.

Two additional categories matter:

4. Backrunning. A searcher submits a transaction immediately after a target transaction to capture a temporary state. Often benign (e.g., capturing arbitrage created by a large swap), occasionally harmful (e.g., immediately liquidating a position that became unhealthy).

5. Just-in-time (JIT) liquidity. A searcher adds liquidity to an AMM range immediately before a known large swap and removes it immediately after. Captures most of the trade's fees without bearing impermanent loss risk. Harmful to passive liquidity providers; nearly invisible to the swapping user.

The full taxonomy is broader, but these five cover most of the MEV that affects ordinary protocol users.

How MEV Reaches Your Protocol

MEV's effect on your protocol depends on the path transactions take from user to inclusion. The path has evolved substantially since 2020.

Pre-Merge: Public Mempool + Miner Extraction

Before September 2022, the canonical path was:

  1. User signs transaction, broadcasts to public mempool
  2. Searchers monitor mempool, identify MEV opportunities
  3. Searchers submit competing transactions with higher gas prices
  4. Miner picks transactions, generally maximizing fees + MEV
  5. Block is produced

Sandwich attacks in this era were straightforward: detect the pending swap, submit front-run + back-run pair with higher gas, profit. Users could pay for "private" submission via services like Eden or Taichi, but these were small relative to the public mempool.

Post-Merge: Proposer-Builder Separation (PBS)

After the Merge, Ethereum adopted Proposer-Builder Separation as a practical equilibrium:

  1. User signs transaction
  2. Transaction goes either to public mempool OR to a private order flow (Flashbots, MEV-Share, Beaverbuild, etc.)
  3. Searchers construct bundles of transactions, including the user's
  4. Builders assemble blocks from bundles, optimizing for total revenue
  5. Proposers (validators) pick the most profitable block from competing builders
  6. Block is produced

The architecture concentrates ordering power at the builder layer. Builders see flows that proposers don't and that public-mempool observers don't. As of 2026, the majority of Ethereum mainnet blocks are built by 3-5 dominant builders.

For a protocol, this means the route a user's transaction takes determines what MEV exposure they have. Public-mempool transactions are vulnerable to sandwich attacks; private-orderflow transactions are protected against some patterns but not all. A protocol designer's choices affect which route users naturally end up using.

Order Flow Auctions

Several services (CoW Protocol, 1inch Fusion, UniswapX, MEV-Share) now broker user order flow to searchers in ways that share extracted value back with users. The general pattern:

  1. User signs an intent (not a transaction): "I want at least 1000 USDC for my 1 ETH"
  2. The intent is broadcast to a permissioned set of solvers
  3. Solvers compete to fulfill the intent; the best price wins
  4. The winning solver constructs the actual transactions; user signs the result

These designs are explicitly anti-sandwich: the user's slippage is fixed by their signed intent, so a sandwich attacker has nothing to capture. They are gaining adoption rapidly, partly because they protect users and partly because they redistribute MEV revenue to participants other than builders.

Sandwich-Resistance: Protocol Design Choices

For protocols where users execute large trades against shared liquidity (AMMs, lending markets opening big positions, etc.), sandwich resistance is the main MEV concern. Several design choices affect exposure.

Slippage Tolerance

The user-side defense against sandwiches is to set strict slippage tolerances. If the user is willing to accept 1% slippage, the maximum a sandwich can extract is roughly that 1% (minus fees). If the user accepts 5%, the sandwich window is wider.

// AMM contract enforces a minimum-out specified by the user
function swap(uint256 amountIn, uint256 minAmountOut, address recipient) external {
    uint256 amountOut = _computeSwap(amountIn);
    require(amountOut >= minAmountOut, "slippage exceeded");
    // ... execute
}

This is universal in AMM design. The defense is real but limited: users routinely set high slippage tolerances (5%, sometimes 10%+) to avoid failed transactions during volatile periods. A high tolerance is, mechanically, an authorization for a sandwich attacker to extract up to that amount.

Auction-Based Pricing

Instead of executing trades at the marginal price of the AMM, auction-based DEXes batch user orders and clear them at a single uniform price. CoW Protocol is the leading example.

Block N:
  User A: swap 100 ETH for USDC
  User B: swap 200,000 USDC for ETH
  User C: swap 50 ETH for USDC

Solver finds:
  A and C trade with B internally (CoW = "Coincidence of Wants")
  Residual goes to external liquidity
  All users get the batch-clearing price

Because the price is determined by the batch as a whole rather than by the order of execution within the batch, there is no sandwich opportunity. The batch is the unit of ordering, and within the batch, ordering is uniform.

The tradeoff: batches require waiting for the next solver run (typically 10-30 seconds), and the protocol depends on an off-chain solver mechanism to find good clearings.

Time-Weighted AMMs

Instead of pricing trades by current pool state, some designs price by time-weighted state over a window. CoW's TWAMM (time-weighted average market maker) approach lets users specify a trade that executes incrementally over many blocks. Sandwich attacks become uneconomic because the trade is too gradual to extract from.

The tradeoff: trades take time to fill; the protocol must handle the case where market conditions change during the execution window.

Slippage-Independent Pricing (Intents)

The newest pattern: users sign intents that specify outcomes rather than transactions. "Give me at least 1000 USDC for my 1 ETH" is an intent. The solver figures out how to satisfy it.

Because the user has signed for a specific minimum outcome, a sandwich attack has nothing to extract beyond that minimum. The protocol enforces the intent at settlement; the solver is incentivized to deliver the best possible outcome above the minimum (because the solver competes with other solvers, who would have offered better outcomes if they could).

This is the architecture behind UniswapX, 1inch Fusion, and CoW Protocol. As of 2026 it is gaining substantial adoption.

Liquidation Design and MEV

Liquidations are MEV-positive: someone needs to perform them, and there's a built-in incentive for whoever does. The design question for the protocol is who captures the value.

First-Come-First-Served Liquidations

The classic pattern: any liquidator can submit a transaction; the first to land captures the liquidation bonus. Compound, Aave, and Euler historically used this.

The MEV impact: liquidations become a gas war. Multiple bots simultaneously attempt the same liquidation; only one succeeds; the others have paid gas for nothing. The "winning" bot has often paid most of the liquidation bonus in gas (priority fees). The user is indifferent — they're being liquidated either way — but the system overall has wasted resources.

Liquidation Auctions

Instead of awarding the liquidation to the first transaction, run an auction. The Dutch auction pattern:

  1. A position becomes liquidatable
  2. The liquidation is auctioned, starting at a high price (close to the violator's debt)
  3. The price decreases over time
  4. The first liquidator to accept the current price captures the position

This converts gas wars into price discovery. The "winning" liquidator only pays the price they were willing to pay; the protocol captures the difference between the auction price and a flat liquidation bonus.

MakerDAO's Liquidations 2.0 (introduced in 2021) uses this pattern. The principle is broadly applicable.

Soft Liquidations

Section 3.10.8 (Euler) covered the soft liquidation pattern: the liquidation bonus scales with how unhealthy the position is. This is good for protocol-level liquidations (incentivizes liquidators in proportion to risk) but has known attack patterns (Euler's self-liquidation exploit).

The design tension: aggressive liquidations protect the protocol but harm legitimate borrowers near the threshold; soft liquidations are gentler but expose more surface to manipulation. Each protocol must choose based on its risk profile.

Frontrunning Resistance: Specific Mitigations

For operations beyond AMM swaps — auctions, NFT mints, governance votes, etc. — MEV concerns take different forms. Some specific mitigations:

Commit-Reveal

For operations where revealing intent in advance enables MEV (NFT mints, sealed bids), use commit-reveal:

  1. User commits a hash of their intended action (with a salt)
  2. After all commits are recorded, users reveal the original action + salt
  3. Contract validates the hash matches and executes
contract CommitReveal {
    mapping(address => bytes32) public commits;
    uint256 public commitDeadline;
    uint256 public revealDeadline;

    function commit(bytes32 commitHash) external {
        require(block.timestamp < commitDeadline, "commit phase ended");
        commits[msg.sender] = commitHash;
    }

    function reveal(uint256 amount, bytes32 salt) external {
        require(block.timestamp >= commitDeadline, "reveal not started");
        require(block.timestamp < revealDeadline, "reveal ended");
        require(commits[msg.sender] == keccak256(abi.encodePacked(amount, salt)),
                "commit mismatch");

        // Execute the action
        _execute(msg.sender, amount);
        delete commits[msg.sender];
    }
}

Commit-reveal works for operations where:

  • The commit and reveal phases can be separated by time (UX-acceptable)
  • The action's correctness doesn't depend on state that may change between phases
  • The salt provides sufficient entropy to make pre-imaging the commit infeasible

It does not work for time-sensitive operations (trades, liquidations) where the reveal-window state may have changed dramatically.

Pre-Signed Messages with Deadlines

For permit-style operations, signed messages with explicit deadlines prevent old signatures from being used to capture MEV:

function executeWithPermit(
    address user,
    uint256 amount,
    uint256 deadline,
    bytes calldata signature
) external {
    require(block.timestamp <= deadline, "expired");
    bytes32 hash = keccak256(abi.encodePacked(user, amount, deadline, nonce[user]++));
    require(_verifySig(hash, signature, user), "bad sig");
    // execute
}

A short deadline (1-5 minutes for most user-facing operations) limits how long an MEV-equipped adversary can sit on a signature waiting for favorable conditions.

Private Mempools

For high-value operations, users can submit transactions to private mempool services rather than the public mempool. Flashbots Protect, MEV-Share, and similar services route transactions through builders who include them in blocks without revealing them publicly until inclusion.

The tradeoffs:

  • Private mempools centralize routing through specific operators
  • Inclusion latency may be longer than public-mempool inclusion
  • Failed transactions don't reveal their failure publicly (good for privacy, bad for monitoring)

A protocol cannot generally force users to use private mempools — that's a user-side choice — but the protocol can document the recommendation prominently and design UX to default to private routing where possible.

Batch Operations

For governance votes, NFT mints, or other operations where order within the batch doesn't matter, batch operations into a single transaction that processes everyone together. Each individual sub-operation does not have a discrete inclusion moment that can be MEV-attacked.

function batchVote(uint256[] calldata proposalIds, bool[] calldata supports) external {
    require(proposalIds.length == supports.length);
    for (uint256 i = 0; i < proposalIds.length; i++) {
        _vote(msg.sender, proposalIds[i], supports[i]);
    }
}

Batching also reduces gas costs, so users have a non-MEV reason to use it.

MEV in Governance

A specific category of MEV worth its own treatment: extraction from governance voting. The patterns:

1. Vote-buying. A token-holder votes for whatever proposal pays them most. Markets like Cobra, Hidden Hand, and (defunct) Compound Treasury have facilitated this directly. The mechanism is not strictly MEV but it captures the same dynamic: a privileged actor (voter) extracts value from the system.

2. Flash loan governance attacks. An attacker takes out a flash loan, deposits into a protocol whose governance token represents pool ownership, votes during their brief tenure, and exits before the loan expires. Section 3.11.6 covers governance-specific defenses.

3. Proposal MEV. A governance vote that, if passed, will change a protocol parameter in a way that creates an arbitrage opportunity. Searchers position trades immediately before the vote's execution to capture the change.

Each requires specific defenses; Section 3.11.6 covers them in depth.

Threshold Encryption and Encrypted Mempools

The frontier of MEV defense as of 2026: encrypted mempools where transactions are visible to no one (including builders) until inclusion. The general idea:

  1. Users submit encrypted transactions
  2. Validators/proposers include the encrypted blob in the block
  3. After inclusion, the transaction is decrypted (via threshold cryptography or time-locked encryption)
  4. The decrypted transaction is executed

If implemented correctly, the builder/proposer cannot see what they're including. Sandwich attacks become infeasible because no one knows what to sandwich.

Several projects (Shutter Network, Chainlink Fair Sequencing Services, Aztec's various designs) are working on production-grade encrypted mempools. None is yet the dominant pattern; the cryptographic and operational challenges are substantial. For a protocol designer, the practical question is whether to design assuming encrypted mempools will become widely available (in which case some current MEV defenses become unnecessary) or assuming they won't (in which case the current state continues).

The honest answer: design for the current state, but architect the protocol to be compatible with encrypted-mempool patterns when they ship. Protocols whose security depends on transaction ordering being adversarial are robust to either future; protocols whose security depends on transaction ordering being friendly are fragile to both.

L2-Specific MEV Considerations

Most L2s have different MEV dynamics than mainnet. Some patterns:

  • Centralized sequencers (Optimism, Arbitrum, Base, etc., as of 2026) typically order transactions FIFO. Sandwich attacks via reordering are infeasible because the sequencer doesn't reorder. But the sequencer itself could extract MEV by reordering; most sequencers operationally do not, but the trust assumption is that they won't.
  • Decentralized sequencer auctions (planned for most major L2s) will reintroduce ordering-based MEV but in a more structured form than mainnet's builder competition.
  • Same-chain composability on L2s often provides more atomicity guarantees than mainnet, which can affect what flash-loan-style attacks are possible.
  • Cross-L2 arbitrage is a major source of MEV — searchers move price-differentials between L1 and L2 or between L2s. This affects oracle freshness and arbitrage-incentive design for L2-deployed protocols.

Section 3.11.8 covers L2 considerations more broadly.

Practical Checklist

For a protocol designing under MEV assumptions:

  • User-side slippage tolerance is exposed and well-defaulted in your UI / SDK
  • AMM pricing is sandwich-resistant by design (auction-based, intents-based) or users are clearly aware of slippage tolerance
  • Liquidation mechanism is auction-based rather than first-come-first-served (where stakes warrant)
  • Operations where intent revelation enables MEV use commit-reveal or pre-signed messages
  • Signed messages have explicit deadlines, sized to limit MEV exposure
  • Documentation recommends private mempool routing for users where applicable
  • Batch operations are available where they reduce per-operation MEV surface
  • No predictable randomness from chain data (Section 3.11.2)
  • Governance is protected against flash-loan-based voting (Section 3.11.6)
  • Tests cover the protocol's behavior when an MEV searcher front-runs, back-runs, or sandwiches each significant operation
  • The protocol's design assumes ordering is adversarial, not friendly

A protocol that addresses every item has done thorough MEV work. A protocol that addresses none has accepted whatever MEV its users will lose — which, for high-volume protocols, can easily reach millions of dollars annually.

Cross-References

  • Front-running as a vulnerability class — Section 3.8.7 covers the bug-level treatment of frontrunning, sandwich attacks, and related patterns
  • Defensive patterns — Section 3.7.5 covers commit-reveal as a defensive pattern
  • Oracles — Section 3.11.1 covers oracle manipulation, which composes with MEV at protocol boundaries
  • Composability — Section 3.11.2 covers the broader composability surface that MEV exploits
  • Flash loans — Section 3.11.4 covers flash loans as the capital primitive that enables many MEV strategies
  • Governance attacks — Section 3.11.6 covers MEV-adjacent attacks specific to governance systems
  • L2 considerations — Section 3.11.8 covers MEV in L2 environments
  • Flashbots documentation — for current Protect, MEV-Share, and builder details: https://docs.flashbots.net
  • The Flash Boys 2.0 paper (Daian et al., 2019) — the original academic treatment that named MEV