Guide

MEV explained: maximal extractable value and transaction ordering

When you submit a swap on a decentralized exchange, your transaction does not execute in isolation. It lands in a public queue where specialized bots scan for profitable opportunities — buying before you to push the price up, then selling after you at your expense. That profit from transaction ordering is called MEV (maximal extractable value, formerly “miner extractable value”). MEV is not a bug in blockchains; it is an economic consequence of giving block producers the power to choose which transactions appear, and in what order, within each block or slot. On Ethereum, searchers compete through DeFi mempools and builder auctions; on Solana, bundle auctions through Jito and aggressive priority fees play a similar role. This guide explains what MEV is, the main attack types users encounter, who captures the revenue, how flash loans amplify certain strategies, and practical steps to reduce harm when you trade, mint, or liquidate on-chain.

What MEV is — and why block order matters

Blockchains batch transactions into blocks (Ethereum) or slots (Solana). The entity that produces each block — a validator, miner, or builder they delegate to — decides inclusion and ordering within consensus rules. That discretion creates arbitrage: if your pending swap will move a pool price, a bot that sees it in the mempool can insert its own trades around yours and capture the spread.

MEV is the maximum value theoretically extractable from that ordering power in a given block, not necessarily what any one actor actually keeps. In practice, specialized searchers (often running colocated infrastructure) detect opportunities, construct transaction bundles, and bid for block space. Validators or builders take a cut; searchers keep the remainder. Ordinary users pay indirectly through worse execution prices, failed transactions, and higher fees bidding for priority.

MEV exists wherever transaction content is visible before finality and ordering affects economic outcomes — DEX swaps, lending liquidations, NFT mints with fixed supply, governance votes, and even cross-chain bridge deposits. It is distinct from protocol bugs, though MEV bots frequently combine ordering advantages with oracle manipulation or smart contract logic flaws.

Common MEV strategies

Front-running and back-running

Front-running places a competing transaction ahead of a victim's in the block, typically buying an asset the victim intends to buy (driving price up) or selling before the victim sells (driving price down). Back-running executes immediately after the victim's trade to arbitrage the price dislocation the victim created — for example, buying back tokens after a large sell pushed the pool below fair value.

Sandwich attacks

A sandwich combines both: the attacker buys token A before your swap (front-run), your swap executes at a worse price because liquidity shifted, then the attacker sells token A back to the pool (back-run), pocketing the difference minus fees. Sandwich attacks target large DEX trades with loose slippage tolerance on constant-product AMMs where price impact is predictable from mempool data.

Arbitrage and liquidations

Not all MEV is adversarial to users. Atomic arbitrage across DEXs corrects mispriced pools and is often considered “good MEV” because it improves market efficiency — though searchers still capture the spread. Lending protocol liquidations are another competitive MEV category: bots race to repay underwater debt and seize collateral when health factors cross thresholds. Delayed liquidations harm protocol solvency; aggressive liquidation MEV keeps lending markets functional, but borrowers may receive worse collateral recovery if bots optimize for speed over user surplus.

NFT and mint sniping

Fixed-price mints with public metadata create ordering races. Bots monitor mempool or mempool-equivalent feeds for mint transactions and insert higher-fee competing mints or buy floor listings ahead of human users. On Solana's high-throughput slots, mint sniping often depends on validator-adjacent bundle placement rather than classic Ethereum mempool watching.

Who captures MEV — searchers, builders, relays, validators

Modern MEV supply chains split roles so validators do not need to run sophisticated bot infrastructure themselves:

Searchers — monitor pending transactions, simulate outcomes, and assemble profitable bundles (ordered transaction sets with revert protection).
Builders — aggregate bundles from many searchers, optimize block construction, and bid for the right to propose a block to the network.
Relays — trusted intermediaries between builders and validators that blind or reveal bundle contents according to protocol rules (e.g. Flashbots MEV-Boost on Ethereum).
Validators / block producers — choose which built block to attest or publish, collecting priority fees and MEV payments from winning bids.

Revenue splits vary by chain and auction design. Ethereum post-merge often routes builder payments through relays; Solana's Jito distributes tips to validators that include winning bundles. The net effect for retail users is similar: execution quality becomes a function of who wins the ordering auction, not just gas price.

MEV on Ethereum vs Solana

Ethereum: mempools, Flashbots, and private order flow

Ethereum's public mempool historically exposed pending transactions globally, enabling widespread sandwich bots. Responses include Flashbots Protect and other private RPC endpoints that route transactions directly to builders without public broadcast, MEV-Boost separating block building from validation, and wallet-level integrations that default users to protected submission paths. EIP-1559 base fees burn ETH; priority fees (tips) still bid for inclusion and compete with MEV payments.

Solana: Jito bundles, priority fees, and slot leaders

Solana processes transactions in parallel with a leader schedule per slot (~400 ms). There is no single global mempool identical to Ethereum's, but pending transactions are still visible to infrastructure providers. Jito operates bundle auctions where searchers pay validators tips to guarantee atomic multi-transaction execution at the front of a block. Users compete via priority fees and compute-unit limits; during congestion, under-tipped swaps fail or land late while MEV bots with optimized bundle paths execute first. Understanding slot leaders and finality helps explain why inclusion is probabilistic until confirmed.

How MEV hurts users — and when it helps

Harmful MEV manifests as:

Worse execution price — sandwiches and front-runs widen effective slippage beyond your configured tolerance if settings are too loose.
Failed transactions — you still pay base fees (and on Solana, priority fees on attempts) when a trade is outbid or lands after state changed.
Griefing and spam — bots may flood competing transactions to deny your inclusion in time-sensitive mints or liquidations.
Centralization pressure — validators with superior MEV infrastructure earn more, potentially concentrating stake and block production.

Beneficial or neutral MEV includes cross-DEX arbitrage that tightens spreads, timely liquidations that protect lenders, and some forms of back-running that restore pool prices after large trades. The line is economic, not moral: the same infrastructure extracts rent from uninformed flow while providing liquidity services the protocol depends on.

Protection strategies for traders and builders

For end users

Tight slippage limits — set maximum slippage to the minimum acceptable for trade size; reject sandwiches that exceed your bound (transaction reverts rather than overpaying).
Private or protected RPC — use wallet settings or RPC providers that do not broadcast pending swaps to public mempools (Flashbots Protect on Ethereum; MEV-aware Solana RPCs where available).
Split large trades — smaller chunks reduce predictable price impact that attracts sandwich bots, at the cost of more transactions and fees.
Limit orders and intent-based protocols — sign intents executed by solvers at agreed prices rather than sending raw swap transactions into public queues.
Time trades away from volatility — large moves increase MEV competition; illiquid pools amplify extractable spread.

For protocol and dApp developers

Commit-reveal schemes — hide trade parameters until reveal phase prevents pre-trade front-running (adds latency and UX friction).
Batch auctions (CoW-style) — match trades at uniform clearing prices within a batch, reducing single-transaction ordering advantage.
Oracle design — TWAP and manipulation-resistant feeds reduce oracle-driven MEV covered in the oracles guide.
Rate limits and minimum delays — on custom chains or appchains, enforce ordering rules that cap per-block extraction (trade-offs with composability).

MEV and flash loans — amplification, not creation

Flash loans do not create MEV by themselves, but they amplify strategies that require large temporary capital: oracle manipulation across multiple pools, governance vote buying, and cross-protocol arbitrage in a single atomic transaction. A searcher without upfront collateral can borrow millions, move prices, extract MEV or exploit logic errors, and repay — all reverted if unprofitable. Evaluating protocol risk means assuming adversarial ordering and uncollateralized capital in the same block. See the dedicated flash loans guide for repay-or-revert mechanics and exploit patterns.

Measuring and researching MEV

Public dashboards (e.g. Flashbots explorers, Jito tip analytics, Dune community queries) estimate daily MEV volume by chain, attack type, and winning searcher addresses. Figures are approximate — private order flow and failed simulations are invisible — but trends matter: rising sandwich share signals worsening retail execution; rising liquidation MEV may indicate volatile collateral markets rather than user harm.

Researchers classify MEV into atomic (all-or-nothing within one tx), non-atomic (multi-block strategies), and cev (centralized exchange vs on-chain arbitrage). Protocol designers use these categories when deciding whether to internalize MEV (protocol-owned liquidity, validator rebates to users) or externalize it to open searcher competition.

Common mistakes

Max slippage on every swap — wallet defaults of 1–5% on large trades invite sandwiches; calculate impact from pool depth instead.
Assuming private RPC is always on — verify wallet network settings; a misconfigured RPC re-exposes transactions to public feeds.
Ignoring failed tx costs — on Solana, repeated failed attempts during NFT mints or launches still burn priority fees.
Equating all MEV with theft — over-regulating arbitrage and liquidations can harm protocol liveness; target sandwich and oracle manipulation paths.
Underestimating latency — human click speed cannot compete with colocated searchers on time-sensitive events; use limits or accept worse odds.
Building protocols that depend on FIFO fairness — public blockchains do not guarantee first-come-first-served; design economic games accordingly.

User and builder checklist

Set slippage from pool depth simulation, not wallet defaults, for trades above trivial size.
Use MEV-protected or private submission paths when your wallet and chain support them.
Prefer batch auctions, limit orders, or intent protocols for large illiquid swaps.
Monitor effective vs quoted price (price impact + fees) after execution, not just success/fail.
During launches, assume bots — cap personal spend and avoid FOMO-driven max slippage.
Protocol teams: threat-model ordering + flash loans together in security reviews.
Document whether your dApp RPC broadcasts publicly or routes to private builders.
Track failed transaction rate and priority fee spend — spikes often correlate with MEV congestion.
Validators: understand relay trust assumptions and tip distribution to delegators.
Revisit settings quarterly — MEV infrastructure and wallet defaults change fast.

Key takeaways

MEV is profit from transaction ordering within blocks — swaps, liquidations, mints, and governance are all in scope.
Sandwich attacks are the most visible retail harm; tight slippage and private submission reduce exposure.
Searchers, builders, relays, and validators split MEV revenue; users pay via worse execution and higher fees.
Ethereum uses Flashbots-style private flow; Solana uses Jito bundles and priority fee auctions.
Some MEV (arbitrage, liquidations) supports protocol health; the goal is minimizing extractive ordering, not eliminating all reordering.
Combine user-side protections with protocol design — batch auctions, oracles, and commit-reveal — for durable reduction.