Uniswap math, V1 to V4

Uniswap V1 had one contract per token, and every pool paired that token with ETH. There was a DAI/ETH pool, an MKR/ETH pool, and so on. The whole pricing rule fits in one line.

The constant product rule

Take a pool with 10 ETH and 20,000 USDC. Then k = 10 × 20,000 = 200,000. A trader who adds ETH must take out enough USDC that the product is still 200,000. Nobody sets the price. The price falls out of the ratio of the reserves.

What a swap computes

You sell Δx ETH into the pool. The pool now holds x + Δx ETH. To keep the product at k, the pool's USDC must drop to k ÷ (x + Δx). Whatever it drops by is what you receive. Rearranged, that gives the output formula every AMM course shows:

Now the fee. V1 charged 0.3%. The contract does not take the fee out of your output. It shrinks your input: only 99.7% of your ETH counts in the formula, but 100% of it stays in the pool. The extra 0.3% sits in the reserves and makes k grow a little with every trade. That growth is how LPs earn.

Play with the slider and watch two things. Small trades barely move the dot, so their average price stays near 2,000. Large trades slide far down the curve and get worse prices on every extra unit. The curve never touches the axes, so the pool can never be fully drained: buying the last USDC would need infinite ETH.

Two words that people mix up. Price impact is how much worse your average price is than the spot price, because your own trade moves the price, and you can compute it before you trade. Slippage is the difference between the quote you saw and what you got, which also includes other trades landing before yours. A swap's "max slippage" setting caps the second one.

Being an LP in V1

When you deposit, you must add both tokens at the current ratio. In the 10 ETH / 20,000 USDC pool, adding 1 ETH means adding 2,000 USDC too. You receive LP tokens, which are receipts for your share of the pool. If you own 10% of all LP tokens, you can withdraw 10% of both reserves at any time, including 10% of all fees collected since.

V1 had one weak spot for traders. Since every pool was token/ETH, a DAI to MKR swap went DAI → ETH → MKR. That is two swaps, two fees (about 0.6% in total) and price impact in two pools.

Impermanent loss, the cost of being an LP

Here is the part LPs often learn the hard way. Say ETH goes from 2,000 to 4,000 on other exchanges. Arbitrageurs (traders who buy where it is cheap and sell where it is expensive) buy ETH from your pool until the pool price is 4,000 too. To do that, they take ETH out and put USDC in. So your pool now holds less of the thing that went up.

The result: whenever the price has moved since the deposit, an LP holds less value than someone who held the same tokens in a wallet, before counting fees. That gap is called impermanent loss (also called divergence loss). It depends only on how far the price moved from where you deposited:

"Impermanent" because if the price returns to where you deposited, the loss goes back to zero. If you withdraw while the price is elsewhere, it is permanent. Fees are what is supposed to pay for it.

V2 keeps x·y = k and the 0.3% fee exactly. The swap math from the V1 chapter still applies. What changed is around the curve: which tokens can pair, how other protocols can read the price, and how tokens move during a swap.

1. Any token with any token

A pool can now hold DAI/MKR directly, so the DAI to MKR route no longer has to pay two fees. ETH itself is not an ERC-20, so V2 pools use WETH (wrapped ETH, an ERC-20 that is 1:1 backed by ETH). The router contract wraps and unwraps for you and chains pools together for multi-hop routes.

2. A price oracle that is hard to fake

An oracle is a source of prices for other contracts, such as a lending protocol that needs to know what your collateral is worth. The spot price from the previous chapter is a bad oracle. Anyone with a flash loan can push it far for one transaction, let a lending protocol read the fake price, and then push it back. Many 2020 hacks did exactly this.

V2's answer is a TWAP, a time-weighted average price. The pool keeps a running total, the price accumulator. At the first interaction in each block, before any trade, it adds "price × seconds since the last update":

A contract that wants the average price over the last hour reads the accumulator now and one hour ago, then divides:

The spike is 1,000 USDC (50%), yet the 30-block TWAP moves by only about 33 (1,000 ÷ 30). To move the TWAP by 50% the attacker must hold the fake price for the whole window. Every block they hold it, arbitrageurs trade against them and take their money. That makes the attack expensive instead of free.

3. Flash swaps

In V2 the pair sends you the output tokens first, optionally calls your contract, and only then checks that it got paid. The check is the curve itself, run on the pool's real token balances after your callback:

Because only the end state is checked, you can borrow tokens from the pool with nothing up front, use them for an arbitrage, and repay in the same transaction. That is a flash swap. If you cannot repay, everything reverts as if it never happened.

4. Small details that matter

The first LP in a pool receives √(x·y) LP tokens, minus 1,000 units that are locked forever (MINIMUM_LIQUIDITY). The square root makes the value of one LP share independent of the price at which the first LP deposited. The locked 1,000 units make it about 1,000 times more expensive for an attacker to inflate the value of one LP share until later depositors lose their deposit to rounding.

There is also a protocol fee switch. Governance turned it on for Ethereum mainnet in December 2025: 1/6 of the 0.3% (so 0.05% of volume) goes to the protocol and 0.25% to LPs.

Look again at the V1 curve. It runs from a price near zero to a price near infinity, and a V2 LP's money is spread across all of it. If ETH trades between 1,500 and 3,000 for a year, the part of your deposit reserved for ETH at 50 USDC or 500,000 USDC does nothing. It earns no fees.

V3 lets each LP pick a price range, written [p_a, p_b] (lower price, upper price). Your money only works while the price is inside your range, and in exchange it works much harder. This is concentrated liquidity.

A new main character: liquidity L

In V2 the natural measure of a pool was k. V3 uses its square root instead:

Why the square roots? Because with them, swap math turns into multiplication. When the price moves within a range where L is constant:

Real reserves for a range

An LP in range [p_a, p_b] only needs enough tokens to cover price moves inside that range. Starting from the current price P, the price can fall to p_a (the pool would hand out USDC and collect ETH) or rise to p_b (it would hand out ETH). So the position holds exactly that much of each:

These are the real reserves: the tokens you deposit. The pool behaves as if it held much more, the virtual reserves L/√P and L·√P that a V2 pool with the same L would need. The gap between the two is the efficiency gain.

The 50/50 split above is not a coincidence. 2,000 is the geometric middle of 1,600 and 2,500 (1,600 × 2,500 = 2,000²). A range centered that way always starts half in each token. Move the current price toward the top of the range and the position holds more USDC; toward the bottom and it holds more ETH.

Drag the market price above the upper price of your range. The position is 100% USDC: as ETH rose through your range, buyers took all your ETH. Drag it below the lower price and you hold 100% ETH. Out of range you earn nothing, and the position is the "losing" side of the move. That is impermanent loss with the multiplier turned up. A tight range earns more fees and loses more to price moves.

The same mechanism gives you range orders. A thin range just above the current price, funded only with ETH, sells your ETH as the price crosses it, like a limit order that also earns the fee.

Ticks: how ranges are stored

An LP cannot pick just any price as the lower or upper price of a range. The contract only allows prices on a fixed grid of steps called ticks. Tick number i stands for the price:

The power ("to the i") means "multiply 1.0001 by itself i times". To go from a price back to a tick you use a logarithm, which is the undo button for powers:

Why do higher fees come with wider tick spacing? Every initialized tick a swap crosses costs extra gas, because the pool has to update its active liquidity there. Low-fee pools (0.01%, 0.05%) are meant for pairs whose price barely moves, such as two stablecoins. LPs there need fine steps to place tight ranges, and swaps rarely cross many ticks. High-fee pools (0.3%, 1%) are for volatile pairs. Their price moves through many ticks, so wider spacing keeps swaps cheap, and LPs there use wide ranges anyway. On Ethereum, V3 offers these four pairs of fee and spacing, and only governance can add a new one. It launched with three; governance added 0.01% in November 2021. V4 lets each pool choose any fee and spacing.

The last box is how the contract stores √P: as sqrtPriceX96, which is √P × 2⁹⁶ as an integer. Solidity has no decimals, so the contract multiplies by a huge fixed number to keep precision. This format is called Q64.96: 64 bits for the whole part, 96 bits for the fraction.

A swap that crosses ticks

The pool keeps one number for the active liquidity L right now. Each tick where some LP's range starts or ends stores liquidityNet: how much L to add or remove when the price crosses it. A swap runs in a loop:

1. Find the next initialized tick in the direction of the swap.
2. With the current L, compute how much input moves √P to that tick (Δy = L · Δ√P).
3. If the trade has that much input left, move there, add or subtract that tick's liquidityNet from L, and repeat.
4. If not, move √P only part of the way and stop.

Each tick can be referenced by only so much liquidity, maxLiquidityPerTick. It is set from the tick spacing so that L summed over every usable tick still fits in a uint128. A mint that would push a tick past it reverts.

How does the pool get paid? Like V2's flash swaps, a V3 pool sends a swap's output first and then calls a callback on the contract that started it (uniswapV3SwapCallback). For a mint there is no output; the pool calls uniswapV3MintCallback to collect the tokens. Inside the callback, your contract transfers what it owes. Afterwards the pool checks its balances and reverts if it was not paid.

function uniswapV3SwapCallback(
    int256 amount0Delta, int256 amount1Delta, bytes calldata data
) external {
    (address tokenIn, address payer) = abi.decode(data, (address, address));
    uint256 owed = uint256(amount0Delta > 0 ? amount0Delta : amount1Delta);
    IERC20(tokenIn).transferFrom(payer, msg.sender, owed);
}

Fees in V3

Pools come in fee tiers: 0.01%, 0.05%, 0.3% and 1%. Stable pairs pick low fees, volatile pairs high. The contract writes fees in hundredths of a basis point, called pips: fee = 3000 means 0.3%. Fees are no longer added to the reserves. Each pool tracks "fees earned per unit of L" globally and per tick, and a position's share is computed from the difference when you collect. That is why the V3 position manager issues each position as an NFT: every position has its own range, so the shares are not interchangeable like V2 LP tokens.

The V3 oracle also changed. It accumulates the tick instead of the price. Since a tick is a log of the price, averaging ticks gives a geometric mean price, so the average price of ETH in USDC is exactly the inverse of the average price of USDC in ETH. V2 needed two accumulators for that; V3 needs one. A geometric mean also damps a spike up, but a crash toward zero pulls it down hard.

V4 pools use the V3 curve unchanged. L, √P, ticks, ranges and the swap loop all carry over. What V4 changes is where pools live, how tokens move, and who can add logic.

1. The singleton

In V2 and V3 every pool is its own contract, deployed by a factory. In V4 all pools live inside one contract, the PoolManager. This design is called a singleton. Creating a pool is a storage write instead of a contract deployment, so it is much cheaper. A pool is identified by its PoolKey:

Fees and tick spacing are no longer limited to a fixed list, and native ETH works again (no WETH needed), as in V1.

2. Flash accounting

Since all pools share one contract, the PoolManager can wait until the end to move tokens. You call unlock(), the PoolManager calls back into your contract, and inside that callback you can swap, add liquidity and remove liquidity as many times as you like. Each action only updates a running tally per token, called a delta. When your callback returns, every delta must be zero, or the whole transaction reverts.

The USDC never moves. In V3 the same route sends USDC out of pool 1 and into pool 2, because they are separate contracts with separate balances. Fewer transfers means less gas, and it makes long routes nearly as cheap as single swaps.

Flash accounting needs a cheap scratchpad that is wiped after each transaction. V4 uses transient storage (EIP-1153, the TSTORE/TLOAD opcodes), which costs far less than normal storage and resets to zero when the transaction ends.

3. Hooks

A hook is an external contract that the PoolManager calls at fixed points in a pool's life. Each pool picks one hook address when it is created, and it cannot change later. The hook can run before or after initialize, add liquidity, remove liquidity, swap and donate. With that you can build dynamic fees, on-chain limit orders, TWAMMs (orders split over time), oracles, KYC gates, or LP rewards, without forking Uniswap.

The clever part is how the PoolManager knows which functions to call. It reads them from the hook's address. The lowest 14 bits of the address are on/off switches. If bit 7 is 1, call beforeSwap. If it is 0, skip it. Hook developers mine a CREATE2 salt until the deployed address has the right bits.

function afterSwap(
    address, PoolKey calldata, SwapParams calldata,
    BalanceDelta, bytes calldata hookData
) external returns (bytes4, int128) {
    address user = abi.decode(hookData, (address));
    rewards[user] += REWARD_PER_SWAP;
    return (this.afterSwap.selector, 0);
}

Four of the flags are "returns delta" flags. With them a hook can change the amounts in a swap or a liquidity action, by taking a cut or by doing the whole swap itself. A hook with beforeSwapReturnsDelta can skip the built-in V3 curve entirely and price the trade with its own formula. That is how custom curves (for example stable-swap math) can run inside V4.

Fees can be dynamic too. If the PoolKey's fee is the flag value 0x800000, the hook can set or override the fee per swap, for example raising it when the market is volatile so LPs lose less to arbitrage.

Launchpads that graduate a token from a bonding curve into a V4 pool bring their own risks. The Bonding Curves lesson covers them in its graduation chapter.