MEV, commonly expanded as maximal extractable value, refers to value that may arise from choices about which transactions are included in a block, which are left out, and how included transactions are ordered. For builders, protocol operators, and business decision-makers, the key point is that transaction sequence can affect execution when transactions interact; the existence of that possibility does not establish that value was captured or that a user was harmed.
What MEV means in a blockchain
MEV is a way to describe possible value associated with transaction selection and ordering during block production. The older phrase miner extractable value reflects a setting in which miners were the relevant block producers. “Maximal extractable value” is broader terminology: it does not assume that every system assigns block-production influence to the same role. The details of who can affect inclusion or ordering depend on the chain’s block-production design, so a chain-neutral definition should not name a universal decision-maker.
The word “maximal” should not be read as a promise that a participant can identify or capture all available value. It is part of the term, not a guarantee about outcomes. A possible opportunity, an ordering choice, and realized gains are different things. Evidence that transactions appeared in a particular sequence, for example, would not by itself establish intent, identify who influenced that sequence, or show that anyone profited.
MEV is also distinct from a block reward or an ordinary transaction fee. Those terms refer to other parts of network economics; MEV concerns possible value associated with choices over transaction inclusion, exclusion, and order. The concept is not inherently a claim of misconduct. Some ordering decisions may be part of how a system processes interacting transactions, while particular forms of value extraction may raise concerns. The classification depends on the mechanism and context, not on the label alone.
How transaction ordering can create MEV
Transactions can change the state that later transactions encounter. When two or more instructions interact with shared state, executing them in one sequence can produce a different outcome from executing them in another. If a participant has influence over transaction selection or ordering, that influence can create an opportunity to seek value from the difference. This is the general connection between transaction ordering and MEV.
Consider an illustrative, non-operational example: two trades interact with the same market state, and the first trade changes the conditions under which the second executes. Reversing their order may therefore change the second trade’s result. This example explains why sequence matters; it does not prescribe a trading method, establish that a specific system behaves this way, or show that anyone captured value. The details of execution depend on the system and the transactions involved.
Transaction information can inform ordering decisions, but visibility is not uniform across all systems. The relevant question is what information is available, to whom, and at what stage before inclusion. A general definition cannot establish that every transaction is visible to every block producer, that all participants have the same information, or that every chain offers the same opportunity to affect ordering.
It is useful to separate three stages of reasoning. First, an ordering or inclusion choice may be possible. Second, the choice may alter execution outcomes. Third, a participant may actually capture value from that change. Each step needs evidence: the existence of one does not prove the next. An outcome that differs from a user’s expectation, for example, is not by itself proof that the transaction was deliberately targeted or that a particular actor benefited.
Broad MEV categories and possible effects
Three broad categories often used to discuss MEV are arbitrage, liquidations, and transaction-ordering attacks. These labels identify subjects for analysis, not universal descriptions of how every chain works. At a high level, arbitrage concerns seeking value from differing market conditions; liquidation-related activity concerns transactions associated with positions that meet a system’s liquidation conditions; and ordering attacks describe harmful uses of transaction sequence or inclusion. These are conceptual categories, not operating instructions. Their precise mechanisms and consequences require evidence about the relevant protocol and transaction flow.
Potential effects vary. If ordering changes how an interacting transaction executes, the user’s outcome can differ from what would have resulted under another sequence. Depending on the system and case, this may be discussed in terms of execution quality or additional cost. But a general account cannot establish how often such effects occur, their typical size, or whether a particular user experienced them. Those claims require specific, current evidence rather than inference from the MEV label.
Not every form of MEV is necessarily harmful. Some value associated with transaction sequencing may reflect activity that helps align related market conditions or supports a protocol function. Other forms may disadvantage users or be contentious because of their effect on transaction outcomes. These possibilities should not be collapsed into a single judgment: the relevant distinction is what the mechanism does, who bears its effects, and under what conditions—not simply whether a transaction was ordered.
For decision-makers, category names are therefore a starting point for review. They do not establish that a network is secure or insecure, that an operator acted improperly, or that users face a consistent cost. A system-specific assessment needs to examine the relevant transaction path and the evidence available for its actual behavior.
Mitigation approaches and their trade-offs
Mitigation proposals generally aim to change one or more parts of the process that make ordering-related value possible. Broad examples include private transaction submission, batch execution, and constrained ordering. These are design categories, not guarantees. Their effectiveness, availability, and precise operation cannot be inferred from their names, and any claim about a named implementation requires current primary documentation and independent technical analysis.
Private submission is intended to change who can see transaction information before inclusion. That can alter an information-exposure question, but it does not, by itself, establish how transactions will ultimately be ordered or which parties a user must trust. The relevant trade-offs may include transparency, access, and reliance on the submission arrangement. Those factors need to be evaluated for the specific design rather than assumed to have the same answer everywhere.
Batch execution groups transactions for processing rather than treating each transaction as an isolated ordering decision. It can change the setting in which relative transaction order matters, but the label alone does not establish that all users receive equivalent treatment or that every source of ordering influence disappears. Readers evaluating a batch design should look for documentation on how transactions enter the batch, how outcomes are determined, and what happens when the system cannot process them as expected. These are questions for verification, not claims that every batch system has the same properties.
Constrained ordering seeks to limit discretion over sequence. The central trade-off is that restrictions on ordering may address one source of influence while creating design questions about who defines or enforces the constraints, how exceptions are handled, and what users can observe. Without evidence for a particular implementation, it would be unsupported to say that this approach eliminates MEV, prevents censorship, or improves security.
Across all three categories, compare the problem a design targets with its assumptions and residual limitations. Ask what information the design exposes, who can influence inclusion and order, how transparent its decisions are, and what forms of reliance it introduces. Also distinguish intended behavior from demonstrated behavior. No broad approach should be presented as universally effective, secure, or free of trade-offs.
What a general MEV explanation cannot establish
MEV alone does not measure a chain’s overall security, decentralization, or user costs. Nor does a general explanation establish the legality, tax treatment, or compliance status of any specific activity. Those questions require relevant evidence for the system, conduct, and jurisdiction involved, and are outside this chain-neutral account.
The definition also cannot establish that a particular transaction was targeted. That conclusion would require transaction-level evidence and context sufficient to interpret what happened, including how the relevant system handles execution and ordering. Similarly, claims about fees, availability, security, or recovery need evidence directly tied to a specific design and operating conditions.
The practical takeaway is precise but limited: MEV describes potential value associated with choices about transaction inclusion, exclusion, and ordering. Interacting transactions can make sequence matter, but potential is not proof of capture, harm, or intent. Broad categories and mitigation approaches help frame questions for system-specific review; they do not supply the answers on their own.