T19 · AMM from Mathematics to Code

A Real-World Problem

The product needs a swap feature: users can exchange two tokens without an order book or a designated market maker.

You find the famous five-character formula. In ten lines, you have an implementation:

// The pool holds reserveIn and reserveOut; the user supplies amountIn
uint256 k = reserveIn * reserveOut;
uint256 newReserveIn = reserveIn + amountIn;
uint256 amountOut = reserveOut - k / newReserveIn;

It runs. A swap of 1,000 returns 996; that looks reasonable.

Then a colleague asks during code review: Where is the fee applied?

After three seconds, you can suggest three answers that all look right: deduct 0.3% from the input before the formula; calculate the output and deduct 0.3% there; or leave the formula alone and check at the end that the product did not shrink.

The same trade differs by a few basis points across the three versions. Worse, one version lets an attacker drain the pool gradually while all your unit tests pass, because you tested “how much comes back for 1,000,” not “how much remains in the pool afterward.”

The formula has five characters. It has four plausible implementations, and only one is correct. This chapter unpacks every place those five characters appear in code.

Thought Experiment

Forget code for a moment. Imagine a locked cabinet with two drawers.

The left holds 100 apples and the right holds 100 oranges. The cabinet has one rule:

Anyone may put something into one drawer and take something from the other. Afterward, the product of the quantities in the two drawers may not decrease.

Put ten oranges into the right drawer, giving it 110. How few apples may remain on the left? 100 times 100 is 10,000, and 10,000 divided by 110 is about 90.9. At least 90.9 apples must remain, so you may take at most 9.09.

Notice what happened: you put in ten and took only 9.09. Nobody charged a fee. The 0.91 difference comes entirely from the multiplication rule: the more you buy, the more expensive each later apple becomes.

Now an administrator wants to take a 0.3% fee. There are three places to do it:

1. Deduct it from the deposit. You put in ten oranges, but only 9.97 count in the calculation; 0.03 remain in the drawer separately.
2. Deduct it from the withdrawal. Calculate 9.09 apples for ten oranges, then deduct 0.027 apples from that output.
3. Do not deduct anything; only check afterward. Require the product of the drawers to be a little larger than before, treating the extra as the fee.

They sound equivalent, but produce different outcomes. The important distinction is not the 0.3% itself. It is where the deducted assets go: do they remain in the drawer, or leave it?

That determines whether LPs receive their share automatically and whether the cabinet's rule still holds.

Your Decision

Add a 0.3% fee to the swap function. Which of four implementations do you choose?

What Happens

Compare the numbers from one trade under all four approaches.

Assume one million of each asset is in the pool and the user supplies 10,000.

The first two rows differ by only 0.29 and the last two appear identical. Yet the fourth pool becomes smaller after every trade. Repeat ten thousand times and a substantial piece wears away.

Where the fee is applied determines asset ownership, not merely precision. If it stays in the pool, it belongs to LPs. If it leaves, it belongs to an address while the pool loses assets each time.

Now look at how the curve behaves without a fee. Move the slider below:

Two statements hold together: a shallower pool suffers more price movement for the same amount, and the more you buy from a given pool, the worse your average execution price becomes.

That is the curve's definition, not a bug. It also reveals a point used in later chapters: you can calculate a price for moving the pool's quoted price to any target. The final Lab asks you to calculate it.

Build a Model

A minimal working pool has four central functions. The code below imports nothing and can be read as is.

First, quoting. This is the most important snippet in the chapter:

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

/// Charge 0.3% on input and leave it in the pool
function getAmountOut(
    uint256 amountIn,
    uint256 reserveIn,
    uint256 reserveOut
) pure returns (uint256 amountOut) {
    require(amountIn > 0, "ZERO_INPUT");
    require(reserveIn > 0 && reserveOut > 0, "NO_LIQUIDITY");

    uint256 amountInWithFee = amountIn * 997;
    uint256 numerator = amountInWithFee * reserveOut;
    uint256 denominator = reserveIn * 1000 + amountInWithFee;

    amountOut = numerator / denominator;   // Round down; the remainder stays in the pool
}

Three details here have each caused real incidents:

• Multiply before dividing. Compute the full numerator before division. Every premature integer division loses precision.
• The 997 in the denominator is intentional. Numerator and denominator are both scaled by 1,000 so that a 0.3% fee needs no floating point.
• Round the final output down. The user receives an integer no greater than the theoretical value, and the remainder stays in the pool.

Second, swapping. A quote is a pure function; a swap touches real balances:

function swap(uint256 amount0Out, uint256 amount1Out, address to) external {
    require(amount0Out > 0 || amount1Out > 0, "ZERO_OUTPUT");
    require(amount0Out < reserve0 && amount1Out < reserve1, "NOT_ENOUGH");

    if (amount0Out > 0) _safeTransfer(token0, to, amount0Out);
    if (amount1Out > 0) _safeTransfer(token1, to, amount1Out);

    uint256 balance0 = IERC20(token0).balanceOf(address(this));
    uint256 balance1 = IERC20(token1).balanceOf(address(this));

    // Infer the actual input from balances, not from a caller-supplied parameter
    uint256 amount0In = balance0 > reserve0 - amount0Out ? balance0 - (reserve0 - amount0Out) : 0;
    uint256 amount1In = balance1 > reserve1 - amount1Out ? balance1 - (reserve1 - amount1Out) : 0;
    require(amount0In > 0 || amount1In > 0, "NO_INPUT");

    // After deducting 0.3%, the product must not decrease
    uint256 adjusted0 = balance0 * 1000 - amount0In * 3;
    uint256 adjusted1 = balance1 * 1000 - amount1In * 3;
    require(adjusted0 * adjusted1 >= reserve0 * reserve1 * 1000 * 1000, "K");

    reserve0 = balance0;
    reserve1 = balance1;
}

Notice that amount0In is inferred from balances, not supplied as a parameter. This is the contract's trust boundary: the caller's claim about how much it sent does not count until the contract measures it.

Third, shares. How many LP shares should a deposit mint?

function _sharesFor(uint256 amount0, uint256 amount1) internal view returns (uint256) {
    if (totalShares == 0) {
        // First deposit: shares are the square root of the amounts' product
        return _sqrt(amount0 * amount1) - MINIMUM_LIQUIDITY;
    }
    uint256 s0 = (amount0 * totalShares) / reserve0;
    uint256 s1 = (amount1 * totalShares) / reserve1;
    return s0 < s1 ? s0 : s1;   // Take the smaller share count; excess is a donation to the pool
}

MINIMUM_LIQUIDITY is a small part of the initial deposit locked forever and owned by nobody. The Real-World Case section explains the actual attack it prevents.

Fourth, and easiest to get wrong: rounding direction.

Remember: every rounding decision must favor the pool.

This is not a style preference. Reverse the rounding direction and you create a repeatable exploit that earns a little each time. It causes no revert and may not fail ordinary tests; tens of thousands of trades later, the pool is missing a chunk of assets.

What It Is Called

Hands-on

Let the reserves be x and y, with price p = y / x
To move the price to m times its original value:
new reserve x' = x / sqrt(m), y' = y * sqrt(m)
Required y input = y' - y = y * (sqrt(m) - 1)

m = 2   →  about 41.4% of the y-side reserve
m = 4   →  100%
m = 100 →  900%

AI Lab

Step one:
Starting from constant product x*y=k, derive the quote formula with a 0.3% fee.
Deduct the fee on the input side and leave it in the pool. Show every algebraic step
and provide a Solidity implementation using integer arithmetic only.

Step two:
Give the inverse function: for an exact amountOut that I want to receive,
how much amountIn must I supply? Explain why rounding goes in the opposite direction.

Step three:
List every place these functions can lose precision. For each, say which way
the error goes and who benefits.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check