MEV and execution quality

A cost that appears in no quoted return — and that an organization pays regardless.

This lesson has had no expert review. It was written for this platform and against the evidence it cites; nobody has gone through it independently.

Learning objectives

You can explain where MEV comes from, and who captures it.
You can report execution quality as a cost item of its own.

Check your prior knowledge

Answer these for yourself before reading on. Wherever you hesitate is where this lesson pays off.

Who determines the order of transactions in a block?
What does an observer see before a transaction executes?
Why is a high slippage tolerance exploitable?

Core concept

Fact

Ordering has a value

Whoever decides the order in which transactions enter a block can extract value from it: place an order before or after another, execute a liquidation first, take an arbitrage. That value arises from the structure rather than from a bug — which is why naming it does not make it disappear.

Risk

Your own tolerance is the attack surface

A pending order is visible before it executes, including the deviation it accepts. Anyone seeing it can move the rate inside that band, let the order fire, and move it back. The loss stays formally within the tolerance set — the order counts as successfully executed, and no metric records what it actually cost.

Interpretation

Execution quality is a cost, not an annoyance

For an organization trading regularly, the difference between expected and achieved rate adds up to a measurable quantity — comparable to transaction costs in traditional trading. It should be measured and reported, not accepted. That it appears in no APY does not make it smaller; it only makes it invisible.

Definitions

MEV: Value extractable from how transactions are ordered within a block.
Execution quality: The difference between an order's expected and actually achieved rate.
Private order flow: A way of submitting a transaction without making it publicly visible first.

Model

Decision — the rate is noted
Submission — the order becomes visible, tolerance included
Ordering in the block — other transactions before and after
Execution — inside the tolerance, therefore “successful”
Difference from step 1 — the cost

Where value leaves without appearing as a loss

Formulas

Execution shortfall

Shortfall = (expected rate − achieved rate) / expected rate

expected rate: rate at the moment of decision, before submission
achieved rate: rate actually executed

Limit: The shortfall mixes legitimate price impact with value extracted by others. Separating them requires comparison with the rate path without your own order — an estimate, not a measurement.

Worked example

Successfully executed, dearly paid for

Expected rate: 1.0000
Tolerance set: 1.0 %
Rate achieved: 0.9915
Order size: USD 500,000

Shortfall 0.85 %, inside the tolerance — the order counts as successful. In money: USD 4,250 on a single execution.

No protocol fault, no failed transaction, USD 4,250 of cost with no line of its own.

Reading: Twenty such executions a quarter produce an amount that overwhelms any discussion of basis points in the expected return — and that goes unreported as long as nobody measures the shortfall.

Retrieval

Execution was cheap.Nothing — the tolerance is the upper bound, not the outcome; the actual shortfall has to be measured.The cost equals the pool's fee.

From a bug in the contracts.From someone determining transaction order in a block while pending orders are visible.From fees being too low.

Exercise on real data

Record where in the dimension transaction ordering shows up as a property of the chain — and that this platform supplies no data on it.

Dimension 3: technology →

Application

Which measurement do you introduce so that execution quality becomes reportable at all?