Before AMMs existed, trading crypto assets on-chain was genuinely difficult. You needed a counterparty — someone willing to take the other side of your trade at a price you both agreed on. Order book matching works fine on centralised exchanges where you can run fast servers and aggregate lots of market participants. On a blockchain, where every operation is slow and expensive, maintaining an order book is a near-impossible coordination problem.
Automated market makers solved this by removing the counterparty entirely. Instead of matching buyers with sellers, an AMM lets you trade against a pool of funds governed by a formula. No one has to be on the other side. The math handles it.
That's the idea. The mechanism is worth understanding carefully, because it's not quite as clean as it sounds.
The foundational AMM design — introduced by Uniswap v1 in 2018 and popularised by v2 — is built on one equation:
x · y = k
Where x is the quantity of token A in the pool, y is the quantity of token B, and k is a constant. When you trade, k cannot change (ignoring fees). When you add token A to the pool, the protocol removes token B in proportion — moving along the curve to preserve the product.
Walk through a concrete example. Suppose a pool holds 100 ETH and 200,000 USDC. The constant k is 20,000,000. You want to buy 1 ETH. You're asking the pool to reduce its ETH balance from 100 to 99. For k to stay constant, the USDC balance must rise: 20,000,000 ÷ 99 = 202,020 USDC. So you'd pay approximately 2,020 USDC — not exactly 2,000, because the pool's composition shifts as you trade.
That gap — the difference between the quoted price and the mid-market price — is called price impact. It's not a fee or a rounding error. It's structural. Every trade moves the curve, and large trades move it more. A 0.1% swap barely registers; a 10% swap can be expensive.
The funds in a liquidity pool don't appear from nowhere. They're deposited by liquidity providers (LPs) who receive pool tokens in return — a proportional claim on the pool's assets and any fees it earns.
When you deposit into a pool, you're not making a bet on either asset's price. You're becoming the market. The pool owns your tokens, and you own a share of the pool. If the pool earns fees, your share appreciates. If the pool's composition shifts dramatically because one asset's price moved, your redemption value may differ from what you deposited — even if fee income is positive.
That phenomenon is impermanent loss. The name is a bit misleading — it sounds temporary, but it crystallises whenever you withdraw. The mechanism: if ETH rises sharply relative to USDC, arbitrageurs will buy ETH from the pool until the pool's implied price matches the market. This rebalances the pool away from ETH (which appreciated) and toward USDC. An LP who simply held ETH would have benefited from the price move. An LP who provided liquidity captured fees but ends up holding less of the appreciating asset.
Whether impermanent loss exceeds fee income depends on trading volume, asset volatility, and how long you stay in the pool. There's no universal answer. High-volume, low-volatility pairs (two stablecoins, for example) tend to have favourable dynamics for LPs. High-volatility pairs with lower volume can result in net loss even after fees.
The constant product formula works, but it's capital-inefficient by design. In an x·y=k pool, liquidity exists across the entire price curve from zero to infinity — most of it deployed at price ranges that will never realistically trade. That means a significant fraction of LP capital is sitting idle at any given time, earning nothing.
This is a hard economic constraint, not a design flaw that can be patched. The curve shape creates depth at the current price only if the asset trades near where it was priced when liquidity was deposited.
Different protocols have addressed this in different ways:
Each design is an attempt to improve capital efficiency while preserving the core property — permissionless, trustless trading via a formula.
Concentrated liquidity has become the dominant model for high-activity asset pairs. Uniswap v3's share of DEX volume reflects this shift — active LP management (often via automated range managers) has partially addressed the capital efficiency problem. The trade-off is complexity: passive LPs are more exposed to impermanent loss without careful range management.
A meaningful development is the emergence of singleton pool architectures (like Uniswap v4's hooks system), which allow custom logic to be attached to individual pools — dynamic fees, on-chain limit orders, oracle integration. This is less a paradigm shift than an extensibility upgrade, but it blurs the line between AMMs and more complex execution venues.
There's also growing work on intent-based systems (CoW Protocol, UniswapX) that route trades across AMMs and other sources, sometimes allowing batched settlement that eliminates the price impact users would face in a single pool. These systems sit on top of AMMs rather than replacing them — the AMMs still provide underlying liquidity.
Now: AMMs are live, functional infrastructure. If you're interacting with DeFi, you're almost certainly routing through them. The mechanisms described here govern your actual swap costs.
Next: Concentrated liquidity management tooling is maturing — automated range managers are reducing the operational burden of active LP positions. Intent-based routing is increasingly abstracting pool selection from the end user.
Later: What the optimal AMM design looks like for low-correlation, cross-chain asset pairs remains an open research problem. Nothing to act on at this stage.
This post explains the mechanism. It doesn't constitute advice on providing liquidity, and it doesn't address the tax implications of LP positions in any jurisdiction (which vary significantly and are actively debated).
Understanding how an AMM works is a prerequisite for making informed decisions about using one. The decision itself is outside the scope of this explanation.




