Automated market maker (AMM)

A formula standing in for a counterparty

On an order book, a price exists because somebody chose to post it. On an AMM, a price exists because a contract holds reserves and a function of those reserves has to stay constant when they change. The academic framing generalises every design of this kind as a constant function market maker, one that satisfies a trading function equal to a constant for its reserve vector, with the familiar constant-product rule appearing as the special case where that function is the product of the reserves.²

That generalisation is worth carrying, because it separates what is inherent to the model from what is a Uniswap implementation detail. Every AMM shares the same three properties: pricing is deterministic, it depends only on internal state, and larger trades receive worse terms. Everything else, including which curve, which fee, and whether liquidity is spread across all prices or concentrated, is a choice.

A survey of the field catalogues those choices across the protocols that implement them, and the useful takeaway for a founder is that the design space is real and the defaults are not neutral.³

Constant product, and the fee sitting on top of it

In the constant-product form, the product of the two reserves is preserved across a trade before fees.¹ Put tokens in and that reserve rises, so the other has to fall, and the amount it falls by is what you receive. The move is not proportional to trade size. Consume a larger fraction of the reserve and the terms deteriorate faster than the size increased, which is why a pool that works for $5,000 trades can be hostile to $50,000 trades in the same pair.

The fee is a separate layer bolted to the same equation. Uniswap v2 charges 0.30% on every trade, of which 0.25% stays with liquidity providers and 0.05% routes to a protocol fee address when that switch is enabled.¹ The fee is taken from the input before the formula runs, which is what makes the reserve product creep upward over time rather than staying strictly constant.

The same design also accumulates the relative price of the two assets at the start of each block so other contracts can compute a time-weighted average over arbitrary intervals.¹ That matters if anything downstream of your token reads its price onchain, because a spot read from a shallow pool is trivially manipulable within a single block and a time-weighted read is not.

The pool cannot see the market, so arbitrage imports it

An AMM has no oracle, no feed and no opinion. If the asset moves on every other venue, the pool keeps quoting its old ratio until somebody trades against it. That somebody is an arbitrageur, and their profit is the difference between the pool price and the outside price, less the fee and gas.

This is the part founders tend to underweight. Price correction on an AMM is not a service the protocol performs, it is a trade that extracts value from the reserves. The liquidity providers fund it. Every time the reference price moves and an arbitrageur closes the gap, the pool has sold whichever asset was rising and bought whichever was falling, at prices set by a curve rather than by judgement.

The fee is the only thing standing between providers and continuous extraction, which is why fee tier and expected volatility have to be chosen together. A low fee tier on a volatile pair maximises how often arbitrage is worth executing.

What a trader actually pays

Paradigm's breakdown of a decentralised exchange trade separates the cost into four line items: price impact, broker or trading fees, slippage, and the transaction fee of the underlying blockchain.⁴ Those are four different things with four different causes, and collapsing them into one number is where most trading-cost analysis goes wrong.

Price impact comes from the curve and your own size. The trading fee is the protocol's take. Slippage is what changed between the quote and the fill. Gas is the chain. Only the first is a property of your pool design, and it is the only one a launch team can fix by seeding differently.

What the formula constrains at design time

Three decisions fall out of the model rather than out of preference. The curve, chosen against how the two assets are supposed to relate: constant product for a project token against a stable or gas asset, a stable-optimised curve only where a parity genuinely exists. The fee tier, chosen against expected volatility, since it sets how frequently arbitrage pays. And the seed reserves, solved from the largest trade the design has to absorb and the price move you will accept for it.

Run those three before the deployment script exists. Every one of them is cheap to change on a spreadsheet and expensive to change after a pool is live and holding other people's money.

Where teams get the AMM wrong

The most common error is treating the AMM as plumbing rather than as an input to the token model. The formula is public, deterministic and computable in a spreadsheet, so there is no excuse for a launch plan that cannot answer what a $100,000 sell does to the price on day one.

The second is assuming pooled liquidity substitutes for demand. It does not. Deeper reserves change how gracefully the market absorbs the flow that already exists; they do not create flow. If the underlying business is not generating reasons to hold or use the token, a better curve makes the decline smoother rather than shallower, and that distinction is worth being honest about internally.