How Decentralized Exchanges Actually Work — The Mechanism

Direct answer

Most decentralized exchanges price trades with an automated market maker rather than an order book. The common design is the constant product formula, x × y = k: a pool holds reserves of two tokens, and every trade must leave their product unchanged. Your price is computed from the pool's balances, so price impact is a direct arithmetic consequence of trade size relative to pool depth — not a fee and not a quote from a counterparty.

The formula

A pool holds x of token A and y of token B. The invariant is:

x × y = k

k must not decrease. When you put A in, you take B out such that the product still equals k.

If you deposit Δx of token A, the amount of B you receive is:

Δy = y − k / (x + Δx)

The spot price before you trade is simply the ratio of reserves:

price of A in terms of B = y / x

A worked trade

A pool holds 1,000 ETH and 2,000,000 USDC.

k = 1,000 × 2,000,000 = 2,000,000,000
spot price = 2,000,000 / 1,000 = 2,000 USDC per ETH

You buy with 10,000 USDC. New USDC reserve is 2,010,000, so:

new ETH reserve = k / 2,010,000 = 2,000,000,000 / 2,010,000 = 995.0249 ETH
ETH received    = 1,000 − 995.0249 = 4.9751 ETH
average price   = 10,000 / 4.9751 = 2,010.0 USDC per ETH
price impact    = (2,010.0 − 2,000) / 2,000 = 0.50%

Now the same trade at 100× the size — 1,000,000 USDC:

new ETH reserve = 2,000,000,000 / 3,000,000 = 666.667 ETH
ETH received    = 333.333 ETH
average price   = 1,000,000 / 333.333 = 3,000 USDC per ETH
price impact    = (3,000 − 2,000) / 2,000 = 50%

Look carefully at what scaled and what did not. 100x the spend produced exactly 100x the execution impact — 0.5% became 50%, not more. That is not a coincidence, and it is worth deriving.

These figures assume a zero-fee pool, so the arithmetic is clean and checkable. A real pool also charges a swap fee — commonly 0.30%, though tiers vary — which is taken from the input before the curve is applied. Your actual cost is therefore price impact plus that fee, and the numbers above will be slightly optimistic against a live pool.

Three different things scale three different ways

This is where most explanations, including an earlier version of this page, go wrong. "Price impact" names more than one quantity, and they do not behave alike.

Substituting the output formula into the average price gives a clean result:

received      = x . dx / (y + dx)
average price = (y + dx) / x
exec impact   = (average - spot) / spot = dx / y

So:

In the pool above, spending 10x more moves your execution impact from 0.5% to 5% — exactly ten times. But you receive only 9.57x as many tokens, and the pool's own spot price moves 10.25% rather than 1.0%.

The common claim that "price impact grows faster than trade size" is true of the pool's spot price move and false of your execution impact. Both are called price impact, and interfaces rarely say which they show. The one that determines what you pay is the linear one; the one that determines what the next trader sees is the quadratic one.

What is genuinely superlinear from your side is the shortfall: the tokens you did not receive compared with buying at the untouched spot price. At 10,000 USDC that shortfall is 0.025 ETH; at 100,000 it is 2.38 ETH — roughly 95x for 10x the spend.

And note what never happens at any size: the trade being refused. There is no depth to exhaust — the price simply keeps rising along a hyperbola. You can always execute; you may just execute terribly.

You can work any pool through this yourself with the price impact calculator.

Why this differs from an order book

An order book holds discrete resting orders at specific prices, placed by people who chose those prices. A market order walks those levels — see understanding slippage.

An AMM has no orders and no levels. Price is a continuous function of the reserves.

The AMM's real innovation is that it needs no active quoting. Anyone can deposit into the pool and the formula does the market making. That is why a token nobody would quote professionally can still have a market.

Slippage tolerance is not the same as price impact

Two distinct things that interfaces display side by side:

• Price impact — the movement your own trade causes along the curve. Deterministic; computable before you trade, as above.
• Slippage tolerance — how much additional adverse movement you will accept between submitting and confirming, caused by other transactions landing first.

Setting tolerance high does not reduce price impact. It only widens the band in which someone else's transaction can move the price against you before your trade reverts — which is exactly the opening the next section describes.

MEV: why your tolerance setting matters

Your pending transaction is publicly visible before it confirms. Its price effect is computable by anyone. That enables the sandwich attack:

1. You submit a buy with, say, 5% slippage tolerance.
2. An observer sees it, and buys immediately before you — pushing the price up along the curve.
3. Your trade executes at that worse price, still inside your 5% tolerance, pushing the price higher again.
4. The observer sells immediately after you, into the price your trade created.

They capture roughly the difference between the price you would have paid and the price you accepted. Your tolerance setting is the budget you handed them.

This is a mechanical consequence of a public mempool and a deterministic pricing formula — not a bug in any particular DEX. Practical mitigations: set tolerance to the smallest value that reliably executes, split large trades, prefer deeper pools, and use a private transaction relay where one is available.

Impermanent loss, briefly

The counterpart for whoever supplied the pool. Because the formula rebalances reserves as prices move, a depositor ends up holding more of whichever asset fell and less of whichever rose, relative to simply holding both.

The gap between the pool position and just holding is impermanent loss — a misleading name, since it is only "impermanent" if prices return to where they started. Fees earned may or may not exceed it.

This is why an AMM liquidity provider is not a market maker: they make no quoting decisions and carry a different exposure. See what is liquidity.

Other curve designs

Constant product is the general-purpose case. Others trade generality for efficiency:

• Stableswap curves flatten near a 1:1 ratio, so trading assets expected to hold parity produces far less impact — until the peg breaks, when the curve's behaviour changes sharply.
• Concentrated liquidity lets providers allocate capital to a price range, greatly improving depth within that band and providing none outside it.

The common thread: efficiency is bought by assuming something about where the price will be. When the assumption fails, so does the depth.

Common mistakes

• Reading price impact as a fee. It is arithmetic, and it is entirely predictable from pool reserves before you trade.
• Raising slippage tolerance until the trade goes through. That is paying an unknown amount to an unknown party rather than fixing a size problem.
• Assuming a large pool means low impact for any size. Impact depends on your size relative to the pool's reserves, not on its absolute size.
• Conflating the two impact figures. Execution impact is linear in your trade size; the pool's spot price move is quadratic. Check which one an interface is showing you.
• Confusing a liquidity provider with a market maker. Different roles, different risk.

Related

• What Is a Decentralized Exchange
• Understanding Slippage — the order-book equivalent.
• How to Use a DEX Safely