T20 · DEX Architecture

A Real-World Problem

The T19 pool works, so you connect it to a front end.

The interface reads both reserves, applies the quote formula, and displays “1 ETH is about 3,000 USDC.” The user confirms, and it calls swap with the calculated output amount.

Local tests are perfect. On the second day after launch, users report two problems:

• Some transactions fail. They confirm in the wallet, sign, and then get a revert while still paying gas.
• Worse, some succeed but receive a different amount from what the page displayed. The page said 3,000; the user received 2,890.

You inspect a transaction. The pool was not attacked, the contract has no bug, and the quote formula was correct. Where did those 110 USDC go?

The answer lies in a question you never considered carefully: how long passes between seeing a quote and the transaction actually executing onchain?

Usually tens of seconds or minutes. During that interval the reserves can change through ordinary trading, or because someone sees your transaction and acts first.

Your front end bundled quoting, routing, and execution together and put the most fragile one, the quote, offchain. This chapter separates the three.

Thought Experiment

Step away from blockchains. Picture an airport currency-exchange counter.

One exchange passes through three steps performed by different parties:

1. The rate board at the entrance gives an approximate current rate. It refreshes periodically and clearly says “for reference only.”
2. The clerk accepts your money and chooses a path: exchange directly, go through dollars first, or split the order across allowances.
3. The vault counts out and hands over the actual money.

At the airport, all three happen in the same minute, so they barely feel separate.

Onchain, they happen at three distinct times:

t0   Your browser reads reserves, calculates a quote, and displays it (offchain, read-only)
t1   You sign; the transaction enters the mempool                  (offchain, publicly visible)
t2   A block producer includes and executes it                     (onchain, perhaps with very different state)

Anyone can change the pool between t0 and t2. More significantly, between t1 and t2 your transaction is public in the mempool. Anyone can see what you intend to buy and for how much, and can trade ahead of you.

Return to the airport. If the clerk promises only “the rate on the board” and someone changes the board on your way to the counter, what rate will you receive?

Your only reliable move is to say as you hand over the money: “If I receive less than this amount, do not exchange.”

That sentence is this chapter's most important parameter.

Your Decision

How do you change the swap function so users do not receive an amount different from the page's display?

What Happens

Three parameters prevent three different failures:

The rightmost column points to one rule: all three parameters must be signed by the sender.

That is more important than any individual parameter. A signature is the user's last enforceable boundary. Once signed, the front end, backend, RPC node, Router, and block producer are outside the user's control at inclusion time.

Another counterintuitive point deserves its own statement:

Your slippage tolerance is the bounty you voluntarily post.

Allow 5% slippage and someone can extract profit from you up to that boundary; your trade still succeeds. You receive no error, the chain looks normal, and execution lands near the edge of your own tolerance.

Some wallets choose a wide default to make trades succeed. Users see success and assume all is well. Slippage tolerance is a risk budget, not a usability switch.

Build a Model

Separate a swap into three layers, each with a different job, location, and cost:

Remember: calculate the path offchain; verify the result onchain.

Do not enumerate every pool inside a contract to find the best path. Gas would be exorbitant. More importantly, the onchain reserves being read can themselves be manipulated. An attacker can first change a pool within the same transaction, enticing your onchain algorithm toward a path that favors the attacker.

Keep routing offchain and sign the path as part of the user's intent. Then there is only one indisputable onchain question: after following this path, how much did I actually receive?

A Router skeleton looks like this:

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

function swapExactTokensForTokens(
    uint256 amountIn,
    uint256 amountOutMin,     // Minimum, signed by the sender
    address[] calldata path,  // Path calculated offchain
    address to,               // Recipient chosen by the sender
    uint256 deadline          // Expiry chosen by the sender
) external returns (uint256 amountOut) {
    require(block.timestamp <= deadline, "EXPIRED");
    require(path.length >= 2, "BAD_PATH");

    _transferFrom(path[0], msg.sender, _pairFor(path[0], path[1]), amountIn);

    uint256 amount = amountIn;
    for (uint256 i = 0; i + 1 < path.length; i++) {
        amount = _swapOneHop(path[i], path[i + 1], amount, i + 2 == path.length ? to : _pairFor(path[i + 1], path[i + 2]));
    }

    amountOut = amount;
    require(amountOut >= amountOutMin, "INSUFFICIENT_OUTPUT");
}

Four details matter:

1. Check deadline first. Do nothing further when the trade has expired.
2. Send an intermediate hop to the next pool, not to the Router. This saves a transfer and avoids funds lingering in the Router.
3. Check amountOutMin at the end. It constrains the final receipt, not any intermediate hop. A poor intermediate price is acceptable if the final output meets the bound.
4. The Router holds no funds of its own. A well-designed Router should have a zero balance between transactions.

Why can two hops beat one? Spell out the tradeoff:

Direct swap: A -> C
  One pool with depth D1 bears the whole trade

Two hops:    A -> B -> C
  First hop depth D2, second hop depth D3; each has slippage, but both may be lower
  Cost: one more fee (about 0.6% total instead of 0.3%) and more gas

When two hops win:
  When A/C is shallow but A/B and B/C are deep
  Crossover: extra slippage on the direct route > additional 0.3% fee + gas

That is the routing algorithm's entire question. It weighs slippage against fees rather than finding the shortest path.

What It Is Called

Hands-on

A/C  100,000 on each side       (shallow)
A/B  5,000,000 on each side     (deep)
B/C  5,000,000 on each side     (deep)

Known: your trade size V, slippage tolerance s, pool depth D on one side

1. The attacker first moves the price until your execution lands at the tolerance boundary
2. Required capital: invert the T19 formula, on the order of D * (sqrt(1+s) - 1)
3. Gross profit: about V * s
4. Costs: fees on two trades (about 0.6% of capital) + two gas payments + frontrun bid
5. Net profit = gross profit - costs; if positive, the attacker may act

AI Lab

Step one:
Design a DEX routing algorithm. Given reserves and fee rates for several
constant-product pools, plus input asset, output asset, and amount, find the
path with maximum final output. State your weight function and explain why
a shortest-path algorithm is insufficient.

Step two:
Give three situations where your algorithm chooses a suboptimal path.
For each, explain the pool layout that triggers it, the mistake, and its cost.
If an order may be split across routes, how must the algorithm change?
Below what trade size does the extra gas for splitting outweigh the benefit?

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check