MEV (maximal extractable value)

The definition, and the clause everyone drops

Ethereum's own developer documentation defines it precisely: 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.² Three verbs, and the third one does most of the damage. Inclusion and exclusion are censorship questions. Ordering is where the money is.

In theory the whole amount accrues to validators, because they are the only party that can guarantee a profitable transaction executes. In practice a large share is taken by searchers, independent operators running bots that scan chain data for opportunities and submit transactions automatically. Validators still get paid, because a rational searcher will hand over gas fees up to the full size of the opportunity: if the fee were higher, the trade would lose money.²

The name changed for a reason worth knowing. Philip Daian and co-authors coined miner extractable value in 2019, when proof of work miners held the ordering power, and measured a lower bound of over six million dollars on the pure revenue arbitrage economy alone at that point.¹ After the Merge, validators took over inclusion and ordering, the extraction methods survived unchanged, and the M was redefined to maximal.² Anyone still reading MEV as a mining problem has the wrong mental model of who is doing what.

Four extraction types, and they are not one problem

Start with the harmless looking one. If the same pair trades at different prices on two venues, a searcher buys on the cheap one and sells on the rich one inside a single transaction, which makes it atomic and riskless. Ethereum's documentation gives a live example: a searcher turned 1,000 ETH into 1,045 ETH on the ETH and DAI pair across Uniswap and Sushiswap.² Nobody was targeted. The 45 ETH came out of the liquidity providers who were still quoting the old price.

Liquidations are the second type and they are contractual. Lending protocols require collateral, and when a position falls under its maintenance level anyone may close it and collect a fee. Aave's published risk parameters set that trigger explicitly: a liquidation threshold of 80% means the position is undercollateralised once borrowings pass 80% of collateral value, summarised in a health factor that makes a position liquidatable below 1.³ Searchers then race to parse the chain first and submit the liquidation before anyone else.² The borrower funds the bonus. The gas war over who collects it is pure waste.

Sandwiching is the third and it is the one users mean when they say they got MEV'd. A searcher watches the mempool for a large trade, calculates its price effect, buys immediately in front of it and sells immediately behind it. Ethereum's docs walk through a 10,000 UNI purchase on Uniswap as the worked case, and note that unlike atomic arbitrage this one carries real risk, since the two legs are separate transactions and can be defended against.²

The fourth type attacks settlement itself. When the MEV sitting in a block is worth more than the block reward, validators have a reason to reorganise the chain and take it, which is a direct threat to consensus stability.² The 2019 paper named the extreme version time bandit attacks, where block producers rewrite history to seize funds that contracts had already allocated in the past.¹ That is not a trading cost. That is the finality assumption your product is built on quietly repricing itself.

A sandwich, step by step

Follow the sequence and note that every step is a legal, ordinary transaction. A large buy order enters the public mempool, where it is visible to everyone before it settles. A searcher computes the price impact that order will have on the pool. The searcher's own buy lands first in the same block, moving the pool price up. The original order then fills at that worse price. The searcher's sell lands immediately after, into the strength the victim's own order created.²

The user did not get hacked. They authorised the whole thing when they set a slippage tolerance wide enough to accommodate it. That is the practical design lesson: the slippage limit on a transaction is not a safety setting, it is a public statement of how much you are willing to lose, and it is read as an offer.

This is also why the fix is procedural rather than clever. Split large orders, use private order flow so the trade is never broadcast to the mempool, or execute where the venue batches trades so there is no queue position to buy. None of those make MEV disappear. They change whether your treasury is the one paying for it.

What the measured numbers actually measure

Two figures get quoted constantly and they count different things. The 2019 paper's lower bound of over six million dollars covered atomic pure revenue arbitrage on decentralised exchanges up to that date, on the authors' own experimental measurement.¹ It was never a total, it excluded sandwiching and liquidations entirely, and it is now old. Treat it as the first serious attempt to size the category, not as a current number.

The current, dated reading is adoption rather than dollars. The mevboost.pics dashboard, run by Toni Wahrstätter on Xatu data from ethpandaops, showed 89.94% of blocks built through MEV-Boost over the trailing 14 days, with 46 builders and 10 relays active in that window and an average payment of 0.00681 ETH from builder to proposer, read at 06:00 UTC on 3 August 2026.⁴ Nine blocks in ten on Ethereum are now assembled by an outsourced builder rather than by the validator whose name is on them.

Flashbots, which wrote the software, estimates that validators running MEV-Boost increase staking rewards by over 60%.⁵ That is the vendor's own figure and it is a reward uplift, not a measure of extraction. The honest summary: nobody publishes a reliable total dollar figure for MEV, while block share and the builder to proposer payment are both measured well. Ask anyone quoting a headline MEV number which of those three they are reporting.

What proposer builder separation fixes

Proposer builder separation splits the job. Specialist block builders order transactions, assemble candidate blocks and bid for them to be used. The validator selected to propose the next block reads the bids and takes the highest one, without needing to construct the block itself.² MEV-Boost is Flashbots' implementation of that design for proof of stake Ethereum, sitting as a sidecar next to the consensus client and querying a market of builders through relays.⁵

Three things genuinely improve. MEV extraction moves out of validators' hands, and once validators are not optimising their own extraction, the incentive behind time bandit reorganisations weakens.² A commit and reveal scheme means builders no longer have to trust proposers not to steal the opportunity, and proposers get paid whether or not the block body shows up, so neither side has to trust the other.² That combination lowers the barrier for a solo staker to earn the same MEV income a large pool earns, which was the outcome the design was reaching for.

What it does not fix, precisely

It does not remove MEV income from validators. Ethereum's documentation is explicit that builders must bid high to get blocks accepted, so proposers keep earning from extraction they no longer perform.² The measured average payment of 0.00681 ETH per block is exactly that flow.⁴

It does not stop sandwiching, arbitrage or liquidation racing. Those happen inside the block a builder assembles, and a builder optimising for total block value has every reason to include them. PBS changes who assembles the ordering, not whether your transaction is visible before it settles or whether somebody profits from where it lands.

It is also not finished. The Builder API that makes this work today is described in Ethereum's own docs as a temporary solution with higher trust assumptions, because in protocol proposer builder separation needs changes to the consensus protocol including the Beacon Chain fork choice rule.² And the concentration question is live: 46 builders and 10 relays served roughly nine in ten blocks in the measured fortnight.⁴ Flashbots states the underlying problem plainly, calling MEV a centralising force on Ethereum, which is the framing to keep rather than the reassurance.⁵

Where MEV lands on a token design

Three places, and none of them are the token contract. The first is treasury execution. Buybacks, liquidity rebalances, vesting distributions that get sold, and market making top ups are all large trades against a pool whose depth you know, sent from an address anyone can watch. In our experience teams model the emission schedule to four decimal places and then send a seven figure swap through a public mempool with default slippage settings.

The second is liquidation flow. If your token is accepted as collateral anywhere, every position opened against it becomes latent sell pressure that arrives as a race, routed through whichever venue is deepest, which is usually the pool you seeded. The liquidation bonus is the discount your token gets sold at, and it is set by somebody else's governance.³

The third is oracle timing. Any mechanism that acts on a price update, whether a rebase, a fee switch, a rebalance or a liquidation, creates a queue position worth paying for the moment the update is predictable. Design so the profitable action is not a race: batch it, delay it, or make its trigger unpredictable.

Our position is that MEV belongs in the treasury operating plan as a named execution cost with a written policy, not in the risk appendix as a market curiosity. Write down the maximum size you will send in one transaction, the venues you will route through, and the slippage limit, and set all three against measured pool depth rather than a total value locked figure. That is mechanism behaviour and a design decision, not advice on any asset.