What Is MEV (Maximal Extractable Value)?

What MEV actually is

MEV stands for maximal extractable value, though the term originally meant something narrower: "miner extractable value," coined back when Ethereum ran on proof of work and miners were the ones assembling blocks. Once Ethereum moved to proof of stake, validators took over that job instead of miners, so the industry renamed it to describe the actual mechanic rather than one specific role. MEV is profit that can be extracted by controlling or influencing the order in which transactions get included and arranged within a block.

It's worth being precise about what MEV isn't. It's not a hack, and it isn't an exploit in the sense of breaking a smart contract's rules. Nobody has to find a bug or bypass a security check to capture it. MEV exists because public blockchains are, by design, transparent (see our blockchain explainer for the underlying mechanics): pending transactions are visible before they're finalized, and whoever controls or influences their ordering can profit from that visibility. It's a subtle but very real cost baked into how these systems work.

The mempool: where MEV starts

Before a transaction gets confirmed, it usually sits for a short stretch in a public waiting area called the mempool, short for "memory pool." Every node running the network's software can see what's sitting in there: transactions that have been broadcast but haven't been picked up and included in a block yet. That's the same kind of public visibility that makes on-chain analysis possible in the first place, except here you're not looking at wallets after the fact, you're watching trades that are about to happen.

That visibility cuts both ways. If a large token swap is sitting in the mempool waiting to be confirmed, anyone watching, usually a bot rather than a person, can see it coming and react before it executes. That's the entire setup MEV strategies depend on: spotting a transaction before it's final and acting on that information faster than the person who sent it.

Front-running and sandwich attacks

The most common, well-documented form of MEV is the sandwich attack, a specific kind of front-running. Here's how it plays out: a bot watching the mempool spots a large pending swap big enough to move a token's price. The bot immediately places its own buy order just ahead of it, paying a slightly higher fee so its transaction gets prioritized and lands first in the block. The name comes from the shape of it: the bot's buy order and its later sell order "sandwich" the victim's trade in between.

The victim's trade then executes exactly as sent, except now it's buying at a price the bot's own order already pushed up, and the victim's trade pushes that price further still. The instant that happens, the bot sells right back out, capturing the price movement that the victim's own trade caused. The victim isn't hacked. They just get worse execution, more slippage, than they otherwise would have, and the difference is the bot's profit.

Arbitrage MEV: the more benign side

Not all MEV works against traders. Arbitrage bots scan for price differences on the same asset across different pools or exchanges and trade to capture the gap. If a token is priced slightly lower on one venue than another, an arbitrage bot buys low and sells high almost instantly, and in doing so, nudges both prices back toward each other. That's genuinely useful: it's a big part of why prices stay roughly consistent across a fragmented ecosystem of exchanges and liquidity pools instead of drifting apart. Arbitrage MEV is still extraction, but it's extraction that does real work for everyone else too.

How the industry has responded

The response to sandwich-style MEV has mostly moved in two directions. One is private transaction relays and "MEV protection" services that let you submit a transaction without it ever touching the public mempool first, which removes the window bots need to spot and react to it before it confirms. The other is ongoing research into fairer block-building and transaction-ordering rules generally, aimed at making it harder for whoever assembles a block to reorder transactions purely for their own profit. Neither approach eliminates MEV outright, but both shrink how much of it a given trade is exposed to.

Why this matters for your trades

Large trades on public decentralized exchanges are more exposed to this dynamic than trades on platforms that don't broadcast pending orders to a public mempool the same way. If you're moving meaningful size, it's worth understanding that "the price you saw" when you clicked submit and "the price you actually got" can differ for a reason that isn't just ordinary slippage from thin market depth. Part of that gap can be MEV: a bot that saw your order coming and traded around it before you did.

This is also why order size matters more on public, mempool-based exchanges than it might seem at first. A small swap usually isn't worth a bot's attention, since the fee it pays to jump the queue has to be smaller than the profit it expects to make. A large swap is a different story: the bigger the trade, the more price impact it causes, and the more room there is for a bot to sandwich it profitably. If you're routinely trading size, it's worth knowing whether the venue you're using exposes your pending order to the public mempool at all before you assume slippage alone explains your fill.

The bottom line

MEV is an inherent property of transparent, public blockchains, not a bug that will eventually get patched out. As long as pending transactions are visible before they're final and someone controls the order they get included in, some form of extractable value will exist. It's worth factoring into how you think about trading costs the same way you'd factor in gas fees or spread: not something to panic about, but a real, structural cost of using open, public rails. If any of the terms above are unfamiliar, the Crypto & Trading Glossary covers MEV and related jargon in plain language too.