On most chains, a transaction sits briefly in a public waiting room — the mempool — before it's included in a block. During that window, it's often visible to anyone watching, and on some venues, that visibility lets others act on it before the transaction confirms. That's the space MEV, short for maximal extractable value, operates in.

MEV is the value that can be extracted by controlling or influencing the order in which transactions get included in a block. The term traces back to "miner extractable value" from the proof-of-work era, when miners chose transaction order directly. After Ethereum moved to proof of stake, the term shifted to "maximal" to reflect that validators, and the searchers and bots working alongside them, can all participate in extracting it — not just whoever produces the block.

Not all MEV is adversarial. Arbitrage bots that close price gaps between venues are technically extracting MEV, and that activity generally pushes prices toward consistency across the market. The forms that matter to traders are the ones that come at their direct expense.

Front-running. A bot watches the mempool for a profitable pending transaction and submits its own version first, paying a higher fee to get included ahead of it — capturing the profit the original trader was positioned to get.

Back-running. The inverse: a bot waits for a large trade to land, then immediately trades right after it to capture the price movement that trade caused.

Sandwich attacks. Front-running and back-running combined around a single target trade — a buy order placed just before it, a sell order placed just after, with the original trader's transaction sandwiched in between and executed at a worse price than expected.

These tactics are especially relevant on automated market makers, where a large trade visibly moves the price along the AMM curve. A bot can see the trade coming, estimate how much the price will move, and position around it with reasonable precision — because the AMM's pricing formula is public and deterministic.

Single-block price manipulation. A more aggressive version of the same idea: an attacker uses a flash loan to momentarily move an asset's price within a single block, triggering liquidations on lending or trading protocols that reference that price, then reverses the trade and pockets the difference — all before the block finalizes.

No single defense eliminates MEV, but several mechanisms reduce its impact:

Slippage limits cap how far a price can move between when a trader submits a trade and when it executes, automatically cancelling the transaction if the market moves further than the trader's tolerance.

TWAP (time-weighted average price) references smooth price inputs over a window of time rather than relying on a single block's spot price, making it harder for a single flash-loan-funded spike to manipulate the price a protocol actually uses.

Private mempools hide pending transactions until they're confirmed, removing the visibility that front-running and sandwich bots depend on — though this doesn't prevent block producers themselves from acting on the information they hold.

Fair sequencing processes transactions in the order received rather than by fee priority, removing the incentive to bid for reordering — at the cost of also removing some beneficial MEV, like fast arbitrage and liquidation bots that help keep markets efficient.

Classic sandwich attacks and AMM front-running depend on a specific structural feature: a visible, deterministic pricing curve that a large trade will move in a predictable way, giving a bot something precise to position around.

LeverUp doesn't price trades against an on-chain order book or an AMM curve. Positions are settled through LeverUp's protocol-managed virtual liquidity architecture — the VMMV — where trades reference oracle pricing rather than a local liquidity curve that a trade itself moves. That changes what there is to front-run: there's no AMM price impact from your own trade size for a bot to anticipate and sandwich.

The single-block manipulation risk — flash-loan-driven price spikes used to trigger false liquidations — is a different, oracle-specific threat, and it's one LeverUp's oracle design is built to address. LeverUp's price feed relies exclusively on Pyth's permissioned validator set, plus reference-based protection triggers that catch price updates deviating sharply from recent history before they're applied to live positions. → Full breakdown of the oracle integrity design

None of this makes MEV irrelevant to LeverUp traders — execution quality, oracle freshness, and liquidation timing are all still worth understanding. It means the specific attack surface classic AMM-based MEV depends on doesn't map directly onto how LeverUp settles trades. For the fuller picture of how execution and settlement work, see What is LeverUp?

Trade on LeverUp: app.leverup.xyz