Imagine a vending machine that never runs out of stock and never needs a clerk. You drop coins in, it spits tokens out, and the price quietly adjusts based on how much of each thing is left inside. That vending machine is, roughly, an automated market maker. No order book. No counterparty waiting on the other side of your trade. Just a pool of two assets and a formula that refuses to be broken.
The formula is x · y = k. Three letters, one multiplication sign, and almost every decentralized exchange you have ever heard of runs on a version of it.
The problem AMMs were built to solve
On a traditional exchange, you trade against other people. Someone wants to sell ETH at $2,000, you want to buy ETH at $2,000, a matching engine pairs you up. This works beautifully when thousands of traders are watching the same market. It works poorly when only a handful of people care about a particular token, because there is nobody on the other side of your order.
Early decentralized exchanges tried to port the order book model on-chain. Every bid, every ask, every cancellation became a transaction. On a network where users pay gas for each action, this quickly became unworkable. Market makers were paying more in fees than they were earning in spread.
The automated market maker flipped the design. Instead of matching buyers to sellers, it matches traders to a pool. The pool always quotes a price. The pool never sleeps. And the price is determined not by human negotiation but by math.
The invariant: x · y = k
A constant product AMM holds two assets in a shared pool. Call them x and y. The rule is that the product of the two quantities must stay the same before and after every trade. That product is k, and k is called the invariant.
Let us make this concrete. A pool contains:
x= 10 ETHy= 20,000 USDC
Multiply them: k = 10 × 20,000 = 200,000.
That number, 200,000, is the pool's north star. Any trade that would change k gets rejected. The pool does not care what ETH is "worth" on Coinbase. It only cares that after your trade, x · y still equals 200,000.
Notice what the starting ratio implies about price. Ten ETH balance twenty thousand USDC, which means the pool is quietly saying one ETH is worth 2,000 USDC. The price is not posted on a sign; it is baked into the ratio of the reserves.
A $100 trade, step by step
Alice walks up to this pool with 100 USDC and wants ETH. Let us watch the math.
Before her trade:
x (ETH) = 10
y (USDC) = 20,000
k = 200,000
Alice adds 100 USDC to the pool. The new USDC balance is 20,000 + 100 = 20,100. For k to stay at 200,000, the new ETH balance must be:
new_x = k / new_y
new_x = 200,000 / 20,100
new_x ≈ 9.95025
The pool had 10 ETH. It now holds 9.95025 ETH. The missing 0.04975 ETH is what Alice receives.
Let us double-check. Alice paid 100 USDC for roughly 0.0498 ETH. Her effective price was 100 / 0.04975 ≈ 2,010 USDC per ETH. Slightly worse than the 2,000 USDC/ETH the pool was quoting before she arrived. That difference is called slippage, and it is not a bug. It is the pool's way of saying that her trade moved the reserves, so the price moved with them.
Where the fee fits in
The invariant alone does not pay anyone. Liquidity providers, the people who deposited the 10 ETH and 20,000 USDC in the first place, need to earn something, or they will not show up. The fix is a small tax on every trade, usually 0.3 percent on Uniswap v2 style pools.
Rerunning Alice's trade with a 0.3 percent fee:
- Alice sends 100 USDC.
- The pool skims 0.3 USDC as the fee and keeps it as pool growth.
- Only 99.7 USDC counts toward the swap.
new_y (for invariant) = 20,000 + 99.7 = 20,099.7
new_x = 200,000 / 20,099.7 ≈ 9.95040
ETH out ≈ 10 − 9.95040 ≈ 0.04960
Alice receives about 0.0496 ETH instead of 0.0498 ETH. The 0.3 USDC fee stays in the pool, so the reserves actually become 9.95040 ETH and 20,100 USDC, and the new k is fractionally larger than 200,000. That growth has historically been the liquidity providers' income, compounding trade by trade, though since the December 2025 Uniswap "UNIfication" governance vote, a small slice of the 0.3 percent is now routed to the protocol itself, with the bulk still flowing to LPs.
One subtle point: the fee is charged on the input side, not deducted from the output. This matters when you start chaining swaps or comparing quotes across protocols.
Why big trades hurt
Alice's 100 USDC barely nudged the pool. What if Bob shows up with 10,000 USDC?
new_y = 20,000 + 10,000 = 30,000 (ignoring fees)
new_x = 200,000 / 30,000 ≈ 6.6667
ETH out ≈ 10 − 6.6667 ≈ 3.333
Bob paid 10,000 USDC for 3.333 ETH, an effective price of about 3,000 USDC per ETH. The pool was quoting 2,000 when he walked in. He paid a fifty percent premium, because his trade alone drained a third of the ETH out of the pool.
That ugly curve is the constant product function in action. Small trades barely move the price. Large trades move it violently. Pools with more liquidity, say 1,000 ETH and 2,000,000 USDC, absorb the same trade with far less damage, because the trader's input is a much smaller fraction of the reserves.
What this means in practice
If you use an AMM, a handful of consequences fall out of the math you just saw. None of them are hypothetical; they all happen to real users, every day.
Thin pools are expensive. A pool with $50,000 of liquidity will price a $5,000 trade terribly. Before swapping, glance at the pool's total value locked. Your trade as a percentage of that number is a rough proxy for how much slippage you will eat.
Slippage tolerance is a safety rail. Wallets let you set a maximum slippage, often 0.5 or 1 percent. If the price moves beyond that between when you sign and when the block is mined, the trade reverts. Setting it to 50 percent to "make the trade go through" is how people wake up having paid double.
Sandwich attacks exploit predictability. A bot watching the mempool can see your pending swap, jump in front of it with its own buy, let your trade push the price up, and sell into the new price. The wider your slippage tolerance, the more room the sandwich has to work. Private transaction relays and tight tolerances are the main defenses.
Impermanent loss is real for liquidity providers. When you deposit into a pool, you are effectively taking the other side of every trade. If ETH moons, the pool sells your ETH on the way up. If ETH crashes, the pool buys more ETH on the way down. The fees are meant to compensate for this, but they do not always.
Approvals still apply. Before swapping on an AMM, you approve the router contract to spend your token. This is the same approval pattern used across DeFi, and the same risks apply. Unlimited approvals on unaudited contracts have drained more wallets than AMM math ever will.
Beyond constant product
The x · y = k formula is the original, not the only. Stablecoin-focused AMMs like Curve use a flatter curve that quotes near-1:1 prices across a wider range, because two dollars should trade for two dollars regardless of depth. Uniswap v3 lets liquidity providers concentrate their capital in a narrow price band, earning more fees but bearing more impermanent loss. Balancer generalizes to pools of up to eight tokens with custom weights.
All of them are variations on the same theme: pick an invariant, defend it on every trade, charge a fee, and let math do the market making.
Key takeaways
- An AMM replaces an order book with a pool and a formula. The formula
x · y = kholds the product of the two reserves constant across every trade. - Price is just the ratio of reserves. A pool with 10 ETH and 20,000 USDC is quoting 2,000 USDC per ETH. Trades change the ratio, and therefore the price.
- A 100 USDC swap against the sample pool yields about 0.0498 ETH fee-free, or 0.0496 ETH with a 0.3 percent fee. The fee stays in the pool and rewards liquidity providers.
- Slippage is a feature of the curve, not a malfunction. Thin pools and large trades amplify it, and sandwich bots actively hunt for loose slippage tolerances.
- Constant product is the baseline; stablecoin pools, concentrated liquidity, and weighted pools are refinements on the same core idea.
