T24 · MEV

A Real-World Problem

Two months after your swap interface launches, users repeat one complaint: “The execution price is always a little worse than your quote.”

You check every item from T20. Quotes use current reserves, routing chooses the best path, minimum output is in the user's signature, and there is a deadline. Crucially, trades do not revert. Slippage protection works; users receive at least their signed minimum.

Then you open one trade in a block explorer.

It is transaction 47 in its block. Transactions 46 and 48 have the same sender and touch the same pool: one buys, one sells, and your user is between them.

Replay the three locally and calculate the user's shortfall. The number is familiar: almost exactly the front end's default slippage tolerance.

The user was not tricked. The contract has no bug. Every check passed. Their transaction was simply placed in the middle.

The real question is: who chose the order of those three transactions, and why?

Thought Experiment

Shrink a blockchain to a village.

At its entrance stands a public notice board. Anyone wanting a task done posts a note. Every twelve seconds a packer takes a batch of notes and completes them in whatever order they choose.

Those two rules imply three things.

First, the board is public before the work is done. Your note says what you want to buy, how much, and the worst price you accept. The whole village can read it before execution. This is not a leak; publicity lets others verify the packer followed the rules.

Second, the packer chooses the order and may add their own note. They can put yours at position 47 and their own just ahead.

Third, they do not have to act personally. They can announce: “Whoever pays most gets the first position in the next batch.”

The third rule changes everything. “Who goes first” becomes something with a price, an auction, and willing buyers, not a mere technical detail.

Three businesses appear. For now, leave them unnamed:

A sees the same item sold at different prices on two stalls. They buy at the cheap stall and sell at the expensive one. Prices converge, seemingly without harm, but the price difference came from the people stocking the stalls.

B sees your note announcing a large buy. They buy first, let your order push the price higher, then sell to you. Your visible intention creates their profit.

C sees collateral just cross the seizure threshold from T22 and races everyone else to take the reward.

All three share one important property: none requires an exploit. Every action is permitted and every check passes.

They exploit the structure of the system, not a mistake in its code.

Your Decision

The user has signed. Your code must now send the transaction.

Where do you send it?

What Happens

Each option asks how long and to how many parties the intent is visible, and who may profit from that visibility.

The trust column carries the lesson:

MEV cannot simply be eliminated; it can be shifted. Each defense changes who may profit from your transaction's order instead of making that value zero.

Any claim that a particular service makes you “safe” leaves out the new party whose behavior you now depend on.

A second lesson is a calculable threshold for whether an attacker targets a trade:

Attacker gross gain ≈ trade amount × slippage room they can use
Attacker cost ≈ fees on two swaps + gas on two transactions + bid for position

Positive net gain: act. Zero or negative: ignore the trade.

Read this in reverse: your slippage tolerance is the bounty you post. Multiplying tolerance by trade size gives the prize. Once it exceeds attack costs, the trade becomes a target.

Thus, transaction ordering is itself a saleable resource.

No software version can patch that away. Somebody must decide the order. You can only measure its value and identify who receives it.

Build a Model

1. Who has seen your transaction?

The first row is often ignored. People assume skipping the public mempool is enough, but an RPC provider sees the transaction first. It is directly configured in your code and rarely examined.

2. Four forms with two different properties

The third column divides them:

The first two are work someone needs to do. Without arbitrage, market prices diverge. Without liquidation, lenders accumulate bad debt. They extract value that already exists, though someone captures it.

The last two exist only because your transaction is visible. If nobody acts, the loss does not exist. It is a newly created cost borne entirely by the sender.

Use this distinction when judging an MEV remedy. Moving arbitrage proceeds from A to B does not help the user; reducing frontrunning and sandwiches does.

3. Sandwich arithmetic: your tolerance sets the attack size

You can calculate this section completely. For a constant-product pool from T19, these functions need no external library and can go straight into a test:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/// Constant-product quote, with feeBps charged on input; a typical value is 30
function getAmountOut(
    uint256 amountIn,
    uint256 reserveIn,
    uint256 reserveOut,
    uint256 feeBps
) pure returns (uint256) {
    uint256 inAfterFee = amountIn * (10_000 - feeBps);
    return reserveOut * inAfterFee / (reserveIn * 10_000 + inAfterFee);
}

/// Difference in user receipts without and with a sandwich
/// This subtraction is the number you will measure yourself
function sandwichLoss(
    uint256 userIn,
    uint256 attackerIn,        // Amount supplied by attacker's first trade
    uint256 reserveIn,
    uint256 reserveOut,
    uint256 feeBps
) pure returns (uint256) {
    uint256 clean = getAmountOut(userIn, reserveIn, reserveOut, feeBps);

    // Attacker buys first, moving reserves
    uint256 got = getAmountOut(attackerIn, reserveIn, reserveOut, feeBps);
    uint256 newIn = reserveIn + attackerIn;
    uint256 newOut = reserveOut - got;

    // User executes farther along the moved curve
    uint256 sandwiched = getAmountOut(userIn, newIn, newOut, feeBps);
    return clean - sandwiched;
}

How does the attacker choose attackerIn? They face one hard constraint: the minimum output in the user's signature. Push too far and the user's trade reverts; the attacker's trades then cost fees without the intended gain.

The optimal target is clear:

Optimal attackerIn = the amount making sandwiched exactly equal amountOutMin

Therefore:
    Maximum user loss = trade amount × slippage tolerance
    The attacker aims to take precisely that maximum, no more or less

Pause on that point. The attacker need not guess. Your tolerance tells them how much to trade. Moving from 0.5% to 5% multiplies the target gain by ten.

Whether they act depends on costs:

Gross gain ≈ user loss - pool fees on the attacker's own two swaps
Cost ≈ gas for two trades + bids to surround the user

Act only when net profit is positive.
So there is a minimum attackable size; below it, nobody bothers.

The Lab calculates that minimum. It is more useful than a generic defense tip because it identifies which trade sizes are at risk.

4. Three defenses and the authority each grants

The second column distinguishes reducing the value available to extract from reducing the number of people who see it. The first requires no new trust; the second inevitably adds a counterparty.

In practice, combine the three. A reasonable default dynamically sets tolerance from trade size and pool depth, sends large trades through a private channel or competitive execution, and shows estimated price impact clearly to users. The last costs nothing yet many products omit it.

What It Is Called

Hands-on

Trade 1  Attacker buys amount a       ← lifts the price
Trade 2  User swaps                   ← executes on the moved curve
Trade 3  Attacker sells everything bought in Trade 1

                0.1%      0.5%       1%        5%
   1,000        ...       ...       ...       ...
  10,000        ...       ...       ...       ...
 100,000        ...       ...       ...       ...

Known: depth D on one side, pool fee f, user tolerance s, gas price g

Step 1: Use optimal a from the scan to calculate gross attacker gain
        Gross gain ≈ user loss - fees on the attacker's two swaps
        (They pay f twice; many estimates omit this.)

Step 2: Calculate costs
        Gas for two swaps = 2 × gas per swap × g
        Ordering bid = gross gain given up to get before and after the user
                       (conservatively estimate half the gross gain)

Step 3: Net profit = Step 1 - Step 2

Step 4: Set profit to zero and solve for user trade size V
        V is the minimum attackable size in this pool at this tolerance

AI Lab

Step one:
List user-facing MEV defenses for an onchain swap product. For each, say
whether it reduces extractable value or exposure, its implementation cost,
user experience impact, and the party to whom it transfers trust.
List fully before recommending anything.

Step two:
My product has (fill in): user scale, trade-size distribution, chain,
default slippage tolerance, and RPC source. Assess each option's feasibility
and give measurable expected effects and measurable costs.

Step three:
For your top two recommendations, state when each fails, what signal I can
observe on failure, and the fallback if its provider stops operating.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check