I have a browser tab open right now with the first page of search results for "what is maximal extractable value." I have read — carefully, not skimmed — the top twelve articles. Nine of them open with a variation of the same sentence: "Maximal Extractable Value, formerly known as Miner Extractable Value, refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees by including, excluding, and changing the order of transactions in a block." Then they explain validators. Then they explain transaction ordering. Then they give the sandwich-attack diagram. Then they close with a paragraph about Flashbots. The diagram is sometimes different. The conclusion never is.
Every single one of these articles is technically correct. That is the problem. They are all correct in the same way, which means they are all incomplete in the same way. They treat MEV as a concept to be defined — a piece of blockchain infrastructure trivia that lives in the same mental drawer as "Byzantine fault tolerance" or "Merkle trees." Something you learn to sound knowledgeable. Something you file away and never apply to an actual trading decision. The definition is not wrong. The framing is catastrophically insufficient.
What They All Get Wrong
The standard MEV explainer goes like this. Block producers — validators on proof-of-stake chains, miners on legacy proof-of-work chains — get to decide the order of transactions inside a block. This ordering power is valuable because it allows them to front-run, back-run, or sandwich other users' trades. Automated programs called "searchers" compete for this ordering by bidding gas fees. The total extractable value from this reordering is MEV.
That is all true. And it is framed as if MEV is a property of the blockchain protocol. As if it is an engineering problem that proposer-builder separation, order-flow auctions, and private mempools are steadily solving.
I will concede the strongest version of this framing: the MEV infrastructure ecosystem has genuinely reduced the chaos of the pre-PBS era. Builder marketplaces, MEV-aware relay networks, and order-flow auctions are real infrastructure built by serious engineers. The progress is not fake. The reduction in naive sandwich-attack frequency on major chains is measurable. I do not dispute any of that.
But the conclusion that the conventional coverage draws from this progress — that MEV is a solvable protocol-level problem and that users should wait for the solution — is where the framing collapses. MEV is not a protocol problem. MEV is an execution cost. It sits in the same analytical category as maker-taker fees, spread slippage, and gas. It should be decomposed the same way.
When you swap tokens on a DEX automated market maker, you pay several cost layers simultaneously: the AMM's liquidity-pool fee, the gas cost of submitting the transaction, the slippage between the quoted price and the executed price, and — if a searcher detects your pending transaction in the mempool — the MEV extraction from a sandwich or front-run. The standard explainer describes that last layer and ignores the first three. Or it describes all four but never adds them up. Nobody runs the total cost of execution.
Compare that to a centralized exchange execution. On Binance, the maker fee is 0.1% and the taker fee is 0.1% on spot. On OKX, the maker fee is 0.08%. On MEXC, the maker fee is 0.0% — zero — with a taker fee of 0.02%. These numbers are public, flat, and known before the trade is placed. There is no mempool. There is no sandwich attack vector. There is no variable gas cost. The execution cost is the fee, and the fee is the fee.
MEXC: maker fee 0.0%, taker fee 0.02%, across 2400 listed pairs. That is a known cost envelope. There is no hidden MEV layer on top of it.
The error across conventional MEV coverage is not factual. It is categorical. They classify MEV under "blockchain technology." It belongs under "trading costs."
What Is Almost Always Missing
What I have never seen in a standard MEV explainer is this question: what does MEV cost, per trade, for a specific swap size, on a specific pair, at a specific time of day?
The reason that question is never asked is that the people writing MEV explainers are not traders. They are protocol researchers, or they are content teams rewriting protocol researchers. The framing is always "MEV is extracted from the network" — an aggregate, systemic view. It is never "MEV cost me $14 on a $2,000 swap at 3am UTC when liquidity was thin and the mempool was exposed."
That per-trade framing matters because it is the only framing that allows comparison. If I know my MEV exposure on a given DEX swap is, say, some fraction of a percent of notional on an average-liquidity pair during off-peak hours, I can compare that against the 0.1% taker fee I would pay on Binance for the same notional. Or the 0.02% taker on MEXC. Or the 0.1% on Bybit. The comparison becomes trivial arithmetic, and the conclusion — for most retail swap sizes on most liquid pairs — is not flattering to the DEX execution model.
This is what is genuinely missing from the coverage: MEV is the single strongest argument for centralized exchange execution for the average retail trader. Not because centralized exchanges are inherently trustworthy — the proof-of-reserves record across the industry is uneven, with Binance's last PoR audit dated 2025-03-01, Bybit's dated 2025-03-12, and MEXC's last audit showing only partial reserve verification as of 2024-12-10. Not because centralized exchanges offer philosophical purity. But because their cost of execution is deterministic. You know what you will pay before you click.
The second thing that is missing: MEV is not uniformly distributed. It is concentrated on specific pairs, at specific times, on specific chains. A high-cap swap on a deep-liquidity AMM pool during US trading hours has a very different MEV profile than a low-cap token swap on a layer-2 AMM at 4am UTC with three active searchers monitoring the mempool. The standard explainer treats MEV as a monolithic phenomenon. It is not. It is a function of liquidity depth, mempool visibility, block time, and the competitive dynamics of the searcher market — and the per-trade variance is enormous.
Nobody writes about that variance. They write about the aggregate annual MEV extraction figure and present it as if every swap carries the average cost. That is like quoting the average spread across all Binance futures pairs and applying it to every pair at every hour. Spreads are not averages. Costs are not averages. MEV is not an average.
What I Would Say Instead
If I were writing the canonical MEV explainer — and I suppose this is what I am doing right now — I would not start with validators. I would not start with block production. I would not start with relay networks.
I would start with the trade.
You submit a swap on a decentralized exchange. Between the moment you sign the transaction and the moment it is included in a block, your transaction sits in a queue — the mempool — visible to anyone monitoring it. During that window, automated programs called searchers can see your trade, estimate its impact on the pool's price curve, and submit their own transactions around yours. They buy before you, pushing the price up. Your trade executes at the worse price. They sell after you, capturing the difference. This is a sandwich attack. It is the most common form of MEV extraction at the retail level.
The cost to you is the difference between the price you would have gotten in a fair-ordering system and the price you actually received. That difference is MEV. It is not a concept. It is a line item on your trade.
I would then do what no standard explainer does. I would decompose the full cost stack of a DEX swap versus a CEX trade.
On the DEX side: AMM pool fee (set by the pool's fee tier), gas cost (variable, chain-dependent), price impact from pool depth (variable, size-dependent), and MEV exposure (variable, mempool-visibility-dependent). Four cost layers, three of which are variable, none of which are known with certainty at the moment you decide to trade.
On the CEX side: maker or taker fee. On Binance, that is 0.1% for both sides. On OKX, 0.08% maker and 0.1% taker. On Bitget, 0.1% for both. On MEXC, 0.0% maker and 0.02% taker. One cost layer. Fixed. Published. Known before execution.
I am not arguing that centralized exchanges are better than decentralized ones. That framing — which model is "better" — is precisely the kind of comparison that obscures more than it reveals. I am arguing that MEV is a cost, that costs should be compared against alternatives, and that the comparison should be denominated in basis points per trade, not in philosophical commitments to decentralization.
The concession, again, because it is real: DEX execution gives you self-custody. No counterparty risk. No exchange insolvency exposure. Those properties matter — especially in light of the industry's track record. Bybit holds a CER security score of 9.1 and verified proof of reserves as of 2025-03-12. OKX holds a provisional VARA license in Dubai and a full license from the Bahamas SCB. These are real credentials. But they are not guarantees, and anyone who has watched this market since 2022 understands why self-custody carries weight that no security score can fully replicate.
The point is not that one model wins. The point is that MEV is the cost of self-custody execution, and it should be measured, published, and compared on equal terms with centralized fee schedules — not explained in a textbook diagram and forgotten by the next paragraph. The question worth asking next is whether the emerging MEV-protection layers — private transaction submission, order-flow auctions, intent-based routing architectures — will close that cost gap to the point where the comparison reverses. Answering that question requires per-trade, per-pair, per-hour MEV cost data presented in a format that is directly comparable to a CEX fee table, and almost nobody is collecting it that way, and building that dataset is where the real analytical work starts.