Quant Memo
Core

Automated Market Makers

An automated market maker replaces a human quoting bid and ask prices with a formula and a pool of tokens — trade against the formula, and the price moves mechanically as the pool's balance shifts.

Prerequisites: Blockchains and Consensus

On a traditional exchange, a human or a firm sits between buyers and sellers, posting a bid and an ask and adjusting them as orders arrive. An automated market maker (AMM) replaces that person with a pool of two tokens and a formula. Anyone can trade against the pool at any time, and the price is whatever the formula says it should be given the pool's current balance — no order book, no human quoting anything.

Think of a see-saw with a fixed amount of sand on each side. Push down on one side (add tokens of type A to the pool) and the other side rises (fewer tokens of type B remain, so each remaining unit of B is now scarcer and worth more). The most common AMM design, the constant product formula, is exactly this see-saw made mathematical:

x×y=kx \times y = k

In words: the pool holds xx units of token A and yy units of token B, and their product must always equal a constant kk. Any trade must move xx and yy in opposite directions while keeping the product fixed. That single constraint determines the price at every moment: the price of A in terms of B is the ratio y/xy/x, so as a trader buys A (removing it from the pool, shrinking xx), y/xy/x rises and A gets more expensive with every unit bought — the AMM's built-in slippage.

An AMM sets prices mechanically from the ratio of tokens in a pool, using a formula like x×y=kx \times y = k. Liquidity providers deposit both tokens to earn trading fees, but they are exposed to impermanent loss — the pool automatically sells the asset that's rising and buys the one that's falling, so a provider ends up with less of the winner than if they'd simply held both tokens outside the pool.

Worked example: a swap and its slippage

A pool holds 100 ETH and 200,000 USDC, so k=100×200,000=20,000,000k = 100 \times 200{,}000 = 20{,}000{,}000 and the starting price is 200,000/100=2,000200{,}000/100 = 2{,}000 USDC per ETH. A trader wants to buy ETH with 10,000 USDC.

New USDC balance: y=200,000+10,000=210,000y' = 200{,}000 + 10{,}000 = 210{,}000. To keep kk fixed, the new ETH balance must be x=k/y=20,000,000/210,000=95.24x' = k / y' = 20{,}000{,}000 / 210{,}000 = 95.24. The trader receives 10095.24=4.76100 - 95.24 = 4.76 ETH for their 10,000 USDC, an average price of 10,000/4.76=2,10110{,}000 / 4.76 = 2{,}101 USDC per ETH — about 5 percent above the starting 2,000 USDC price. That gap between the quoted starting price and the average execution price is slippage, and it grows sharply for trade sizes that are large relative to the pool.

Worked example: impermanent loss

A liquidity provider deposits 1 ETH and 2,000 USDC into that same pool when ETH is worth 2,000 USDC, a 4,000 USDC stake. Suppose ETH's market price doubles to 4,000 USDC elsewhere. Arbitrageurs will trade against the pool until its internal price matches the outside market, which means removing ETH and adding USDC until the ratio implies 4,000 USDC per ETH. Solving x×y=kx \times y = k with y/x=4,000y/x = 4{,}000 gives x=k/4,000x = \sqrt{k/4{,}000}; with the pool's own kk, the provider's post-arbitrage share works out to about 0.707 ETH and 2,828 USDC, worth 0.707×4,000+2,828=5,6570.707 \times 4{,}000 + 2{,}828 = 5{,}657 USDC. Simply holding the original 1 ETH and 2,000 USDC outside the pool would be worth 4,000+2,000=6,0004{,}000 + 2{,}000 = 6{,}000 USDC. The provider is down 343 USDC relative to holding — that gap is impermanent loss, and it is "impermanent" only in the sense that it shrinks back to zero if the price ratio returns to where it started; trading fees earned along the way are meant to offset it, but for a sharp enough price move they usually don't fully.

ETH in pool (x) USDC in pool (y) start: 100 ETH / 200k USDC after buy: 95.24 ETH / 210k USDC
Every trade slides along the same $x \times y = k$ curve. Buying ETH shrinks x and grows y, and the curve's steepening slope near either axis is why large trades against a thin pool suffer outsized slippage.

What this means in practice

AMMs are the backbone of decentralized exchanges (Uniswap, Curve, Balancer, and their many variants), each tweaking the core formula for different purposes — Curve's formula flattens near the middle to minimize slippage for assets meant to trade near parity, like two stablecoins. Traders watch pool depth (kk, or more precisely the token balances) to estimate slippage before routing a large order, and arbitrageurs continuously trade AMM prices back in line with prices on centralized exchanges, which is in fact the main source of AMM trading volume and the main source of impermanent loss for liquidity providers, since arbitrage only happens when the AMM price has drifted from the "true" market price.

A quick sanity check for slippage: with a constant-product pool, a trade that is pp percent of the pool's depth moves the price by roughly 2p2p percent — so a trade sized at 5 percent of the pool moves price about 10 percent, which is why professional AMM traders split large orders across several pools or route through aggregators rather than hitting one pool directly.

Key terms

  • Automated market maker (AMM) — a smart contract that prices trades algorithmically from a pool's token balances, with no order book.
  • Constant product formulax×y=kx \times y = k, the most common AMM pricing rule.
  • Liquidity provider (LP) — a depositor who supplies both tokens to a pool in exchange for a share of trading fees.
  • Slippage — the gap between a trade's quoted starting price and its average execution price, driven by trade size relative to pool depth.
  • Impermanent loss — the value a liquidity provider gives up versus simply holding the deposited tokens, caused by the pool automatically rebalancing as prices move.

Related concepts

Practice in interviews

Further reading

  • Angeris & Chitra, Improved Price Oracles: Constant Function Market Makers (2020)
  • Uniswap v2 Core Whitepaper
ShareTwitterLinkedIn