MEV and protocol risk

On a public blockchain, users decide what their transactions do but not when they run relative to everyone else’s. That decision belongs to whoever builds the block, and it is worth money: a trade placed just before a large swap, or a liquidation placed just after a price update, captures value that would otherwise go to someone else.

Maximal extractable value (MEV) is the value that can be extracted by including, excluding or reordering transactions. Some of it is benign, such as arbitrage that keeps prices consistent across markets. Some of it is a direct transfer from users. For protocol designers, the question is which of their functions create extractable value, who captures it, and whether the protocol’s own users bear the cost.

Ordering is a resource

Daian et al. documented in Flash Boys 2.0 how bots competed for transaction ordering on Ethereum through priority gas auctions, and coined the term miner extractable value; the field has since adopted “maximal” as block production moved away from mining. The paper’s central observation still holds: whenever the order of transactions affects their outcome, ordering becomes a market, and that market will be used.

Torres et al. measured front-running on Ethereum at scale in Frontrunner Jones and the Raiders of the Dark Forest, and Paradigm’s Ethereum is a Dark Forest described generalised bots that copy any profitable pending transaction. The consequence for protocols is simple: assume that every transaction in a public mempool is read, simulated and, if profitable, front-run.

How a transaction reaches a block

On Ethereum today, most blocks are produced through proposer-builder separation implemented outside the protocol by MEV-Boost. Searchers watch the mempool and other sources of opportunity and submit bundles of transactions. Builders combine bundles and ordinary transactions into full blocks and bid for inclusion. Relays pass the highest bids to the validator scheduled to propose, who signs the most valuable header without seeing the block’s contents. Enshrining this separation in the protocol is on Ethereum’s roadmap.

Private order flow, sending transactions directly to builders or through protected endpoints instead of the public mempool, removes them from view of public searchers. It does not remove ordering power; it moves trust to whichever builder or service receives the transaction.

How value is extracted

The arithmetic of a sandwich

A sandwich is bounded by the victim’s own slippage tolerance. The attacker trades in the same direction as the victim first, so the victim executes at a worse price, then trades back. The victim’s transaction reverts if it would receive less than its amountOutMin, so the attacker sizes the front-run to stay just inside that limit.

The table below is computed for a constant-product pool holding 1,000 ETH and 2,000,000 USDC with a 0.3% fee. A user sells 10 ETH; without interference they would receive 19,743 USDC.

The victim’s loss is roughly proportional to the tolerance they allowed, and a transaction with no minimum at all can lose almost everything when the attacker has enough capital for the front-run. The attacker’s profit is smaller than the victim’s loss: the difference goes to fees paid to liquidity providers and to the price impact of the attacker’s own trades. Gas and builder payments reduce it further, which is why very tight tolerances are rarely sandwiched.

When MEV becomes a protocol vulnerability

For a protocol, MEV turns into a vulnerability when the protocol itself sends transactions that can be sandwiched or front-run, or when its design lets someone profit from ordering at its users’ expense. A frequent case is a public function that swaps protocol-owned tokens without a meaningful minimum output.

1// Simplified, illustrative yield strategy. Not production code.2function harvest() external {3    uint256 rewards = farm.claim();4    // amountOutMin = 0 and deadline = now: any price is accepted.5    router.swapExactTokensForTokens(rewards, 0, path, address(this), block.timestamp);6    _reinvest();7}

Anyone can call harvest, and an attacker can call it inside a bundle with a front-run and a back-run. The deadline of block.timestamp provides no protection, because it is evaluated when the transaction runs. The bounded version checks the minimum against an independent price and restricts who may trigger the swap.

1// Bounded version: the minimum output is checked against an independent price.2uint256 constant MAX_SLIPPAGE_BPS = 50;  // 0.5%3 4function harvest(uint256 minOut, uint256 deadline) external onlyKeeper {5    uint256 rewards = farm.claim();6    uint256 fair = priceOracle.quote(rewardToken, asset, rewards);7    if (minOut < (fair * (10_000 - MAX_SLIPPAGE_BPS)) / 10_000) revert MinOutTooLow();8    router.swapExactTokensForTokens(rewards, minOut, path, address(this), deadline);9    _reinvest();10}

Other protocol-level surfaces follow the same logic:

• Oracle updates. A transaction that updates a price which the protocol then acts on can be back-run by anyone who sees it first, for example to liquidate or mint at the new price.
• First-come rewards. Claims, airdrops and bounties paid to the first caller are front-run by bots that copy the call.
• Liquidation design. Fixed liquidation bonuses invite a race in which the winner overpays the builder and the borrower pays the bonus. Auctions can return part of that value to the borrower.
• Rebalancing. Large, predictable trades, such as index rebalances at known times, can be traded ahead of.

Design responses

Bound every swap. Every trade the protocol makes, or makes on behalf of a user, should carry a minimum output derived from an independent price and a real deadline. Remove the ordering advantage. Batch auctions, used for example by CoW Protocol, settle many orders at a uniform clearing price so that ordering within the batch does not change the outcome. Commit-reveal schemes hide the content of an action until it can no longer be front-run. Return value to users. Dutch auctions for liquidations and order flow arrangements that rebate back-running value pass part of the MEV back to the user who created it.

Rollups and sequencers

Many rollups currently order transactions through a single sequencer, often on a first-come, first-served basis with a private mempool. That changes the form of MEV rather than eliminating it: latency to the sequencer becomes the competitive advantage, and users trust the sequencer operator not to reorder or censor. Protocols deployed on rollups should document what ordering guarantees their sequencer actually provides, and should apply the same slippage and deadline discipline as on Ethereum.

Conclusions

MEV is the predictable consequence of a public ordering market. It cannot be designed away at the application layer, but its cost to users can be bounded. The bound is almost always the slippage limit and deadline on each transaction, and the protocol’s own swaps are the most common place where that bound is missing.

Beyond bounding, the effective designs either make ordering irrelevant, as batch auctions do, or return the value of ordering to the user who created it.

Recommendations