MEV risk
MEV risk is the possibility that transaction inclusion, exclusion, or ordering transfers value away from users or changes whether their intended state transition succeeds.
Category: RiskWarning cross category cue
System record
Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.
Why it exists
Block producers, builders, searchers, sequencers, and competing users influence transaction order, while public transactions reveal constraints and opportunities before final settlement.
Traditional-finance analogy
Order-flow, priority, and latency-arbitrage risk is the closest comparison recorded for this concept.
Where the analogy stops
- Atomic composability lets ordering strategies combine trades, liquidations, oracle updates, and temporary liquidity inside one block.
- Consensus and block-building rules determine inclusion and ordering rather than one regulated venue's matching and best-execution framework.
Main actors
- ActorUser or protocol submitting a transaction
- ActorSearcher, arbitrageur, or liquidator
- ActorValidator, builder, relayer, or sequencer
- ActorWallet, router, solver, or private-order-flow provider
Assets and claims
Assets — controlled or transformed resources
Assets are resources the mechanism moves, holds, values, or transforms.
- AssetTransaction inputs, outputs, collateral, and gas payments
- AssetExtracted arbitrage, liquidation, or ordering value
Claims — entitlements and corresponding dependencies
Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.
- ClaimPending trade, liquidation, auction, or settlement outcome before inclusion
MEV risk is the possibility that who includes a transaction, when it is included, and what runs around it changes execution or transfers value away from the user.
Why it exists
Section titled “Why it exists”Transactions are not final when submitted. Public contents can reveal a trade, liquidation, oracle update, auction, or rebalance before block settlement. Searchers, builders, validators, sequencers, and competing users can construct or influence an ordering that captures an available state-dependent profit.
Traditional-finance analogy
Section titled “Traditional-finance analogy”Order-flow, priority, and latency arbitrage are useful analogies. Atomic composability lets one ordered bundle combine temporary liquidity, trades, liquidations, oracle-dependent actions, and repayment. Consensus and block building—not one venue’s matching and best-execution rules—determine inclusion.
Actors, assets, and claims
Section titled “Actors, assets, and claims”| Actor | Capability or exposure |
|---|---|
| User or protocol | Submit a transaction with constraints and deadline |
| Searcher, arbitrageur, or liquidator | Observe state and compete for ordering-dependent opportunities |
| Builder, validator, relayer, or sequencer | Construct, select, include, exclude, or order transactions under its protocol |
| Wallet, router, solver, or private-order-flow service | Route and disclose order information under stated guarantees |
Transaction inputs, outputs, collateral, and gas are the assets at risk. A pending transaction is not a settled claim, but its intended trade, auction, liquidation, or rebalance outcome is exposed until inclusion or expiry.
Mechanism and flows
Section titled “Mechanism and flows”- A user signs and submits a transaction with visible or privately shared constraints.
- Other actors simulate the state change and possible preceding or following actions.
- A builder or sequencer selects and orders transactions under available rules.
- Execution changes prices, collateral, oracle state, gas use, or eligibility.
- The user settles within constraints, reverts, is delayed, or receives a worse permitted outcome.
Information flow reveals order intent. Capital flow includes trade amounts, gas, arbitrage, and liquidation proceeds. Claim flow changes when ordering affects debt or collateral eligibility. Return flow pays the actor who captures the ordering opportunity. Risk flow can propagate through liquidations, rebalances, auctions, and oracle-dependent protocols.
State and loss allocation
Section titled “State and loss allocation”| Ordering effect | User or protocol result | Value recipient |
|---|---|---|
| Sandwich or adverse back-run | Swap executes at a worse price within its limit | Searcher, pool, builder, validator, or several actors |
| Priority liquidation or arbitrage | Intended actor loses execution opportunity | Winning liquidator or arbitrage path |
| Censorship or delay | Deadline, hedge, auction, or safety action fails | Loss remains with exposed position; censor may gain indirectly |
MEV is a transfer or allocation of value, not automatically new productive return. Arbitrage can align prices and liquidation can repay debt, while ordering power can also impose execution loss. The exact payer and recipient must be traced per transaction and block-building design.
Protocol and engineering context
Section titled “Protocol and engineering context”Flashbots describes its work as mitigating negative externalities from maximal extractable value and documents a competitive MEV-Boost block-building flow. Those systems change submission and block-building paths; they do not eliminate all ordering, censorship, relay, builder, or information-leakage risk. The documentation was reviewed 2026-08-10.
An engineer or auditor should test adversarial insertion before and after every price-sensitive transition, enforce minimum output, maximum input, deadline, nonce, recipient, and route constraints, and document assumptions for batches, commitments, solvers, private submission, sequencers, auctions, and failed inclusion.
Common misunderstandings
Section titled “Common misunderstandings”- “MEV is only front-running.” Back-running, sandwiching, liquidation priority, arbitrage, censorship, and auction ordering are distinct paths.
- “Private submission removes MEV.” It changes who sees and orders the transaction and introduces provider and inclusion assumptions.
- “Arbitrage profit proves a protocol was exploited.” Some value follows intended pricing rules; classify the state transition and violated property before calling it a defect.
See swap, arbitrage, and oracle risk.
Machine-readable model
Key equations
Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.
This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.
Assurance contract
Security properties
These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.
Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.
User transactions enforce minimum output, maximum input, deadline, recipient, nonce, and authorized route regardless of ordering
Protocol state transitions remain safe when arbitrage, liquidation, oracle, and callback transactions are inserted before or after them
Auctions, batches, commitments, private submission, or solver competition state their ordering and information assumptions without promising elimination of MEV
Failed, censored, or delayed inclusion cannot leave an unauthorized partial state or reusable approval beyond the stated transaction lifecycle
Knowledge check
Quiz
Answer in your own words, then open the model answer.
What problem does MEV risk exist to address?
Model answer
Block producers, builders, searchers, sequencers, and competing users influence transaction order, while public transactions reveal constraints and opportunities before final settlement.