Liquidity Pool Crypto: Why Constant Product Formulas Work

That equation is simple. Its consequences are not. It determines the pool's price, limits the size of every trade, creates slippage, enables permissionless swaps, and transfers inventory risk to liquidity providers. The same mechanism that makes decentralized trading continuously available also creates impermanent loss and exposes pools to predictable attack vectors.

The relevant question is not whether the formula works. It does. The relevant question is what the formula assumes, who absorbs its costs, and whether trading fees and incentives compensate liquidity providers for taking those risks.

The mathematical foundation of automated market makers

A constant product automated market maker holds two reserves:

• x units of Token X;
• y units of Token Y.

The invariant is:

x * y = k

Here, k represents the product of the reserves. During a swap, the pool must preserve this product, excluding the effect of fees. If a trader deposits Δx units of Token X and receives Δy units of Token Y, the transaction follows:

(x + Δx) * (y - Δy) = k

Solving for the output gives:

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

Since k = x * y, this can also be written as:

Δy = y - (x * y) / (x + Δx)

The pool does not calculate a fair value from an external order book. It calculates the amount available under its internal curve. The larger the trade relative to the reserves, the further the price moves along that curve.

The immediate spot price of Token X in terms of Token Y is determined by the reserve ratio:

Price of X = y / x

If a pool contains 100 ETH and 200,000 USDC, the implied spot price is 2,000 USDC per ETH. A trader buying ETH removes ETH from the pool and adds USDC. The ETH reserve falls, the USDC reserve rises, and the ratio changes. The next buyer receives a worse price.

This is not a defect in implementation. It is the basic price-discovery mechanism.

Why the curve is hyperbolic

The equation x * y = k produces a hyperbola. As one reserve approaches zero, the other must grow sharply to preserve the product. The curve approaches both axes but does not reach them through a normal finite trade.

That creates what is often described as infinite theoretical liquidity. A pool can continue quoting a price regardless of its reserve composition. It cannot be completely drained of one asset through an ordinary swap because the marginal price rises asymptotically.

The qualification matters. Infinite theoretical liquidity is not infinite usable liquidity.

A trader can technically buy almost all of one token in the pool. The execution price will become increasingly poor. Slippage becomes the practical limit long before the mathematical limit is reached. A pool with thin reserves can remain operational while being economically unusable for meaningful trades.

The formula therefore solves one problem—continuous availability—but not another—efficient execution at scale.

x * y = k guarantees a quote. It does not guarantee a good quote.

How crypto liquidity pools enable continuous trading

In a traditional exchange, liquidity is organized around bids and offers. A buyer matches with a seller at a selected price. In a constant product pool, the reserves themselves are the counterparty.

The pool accepts a swap as long as the resulting reserves satisfy the invariant. There is no requirement that another trader be waiting with the opposite order. This is why AMM mechanics can support permissionless trading across assets that would not justify a conventional order book.

The mechanism has four moving parts.

1. Deposits establish the initial price

When liquidity is added, the provider contributes both assets. The initial reserve ratio defines the pool's starting price.

If the first deposit contains 1 ETH and 2,000 USDC, the pool begins with an implied price of 2,000 USDC per ETH. If the deposit is made at a price that differs materially from the broader market, arbitrage traders can trade against the pool until the reserve ratio moves toward the external price.

The pool does not know that its starting price is wrong. It has no native concept of "wrong." It only enforces the invariant.

2. Swaps move the reserve ratio

Suppose a trader adds Token X to the pool. The reserve of X rises. To preserve k, the pool releases some amount of Token Y. Since there is now more X and less Y, the internal price of X in terms of Y decreases.

The trade changes both:

• the amount of each asset held by the pool;
• the price available to the next trader.

This is the core distinction between an AMM and a fixed-rate exchange. The execution price is path-dependent. Every unit traded changes the conditions for the next unit.

3. Fees compensate liquidity providers

A swap fee is charged to the trader. In a common Uniswap v2 configuration, the standard fee is 0.3%. The fee may be distributed to liquidity providers or handled according to the protocol's design.

Fees are not free yield. They are revenue generated by order flow. The pool must receive enough volume, and the fee revenue must be sufficient to offset the risks and opportunity costs of holding the pair.

Fees also affect the invariant in practice. The product k can increase over time because fees remain in the pool. It is therefore inaccurate to treat k as permanently fixed across the entire lifetime of a pool. The invariant applies to the swap calculation, while accumulated fees increase the reserves and can increase the product.

4. Liquidity providers receive a claim on the pool

When a provider deposits assets, the protocol typically issues a liquidity provider token, or LP token. The token represents a proportional claim on the pool's reserves and accrued fees.

The LP token is not a stable receipt for the original deposit. Its value changes with:

• the total assets in the pool;
• the provider's share of total liquidity;
• trading fees;
• emissions or rewards;
• changes in the relative market prices of the paired assets;
• withdrawals and new deposits by other participants.

If a provider owns 1% of the pool, that does not mean the provider can later withdraw the same number of ETH and USDC originally deposited. It means the provider can claim 1% of the pool's current inventory, subject to the protocol's accounting rules.

This distinction is central to understanding liquidity provider tokens. They track a share of a changing balance sheet, not a fixed principal amount.

Liquidity provision is inventory management

A pool continuously rebalances its holdings through trades. When traders buy ETH, the pool accumulates USDC and loses ETH. When traders sell ETH, the reverse occurs.

The liquidity provider is therefore not simply earning fees on idle capital. The provider is delegating inventory management to a pricing curve. The curve sells an asset as its price rises and buys it as its price falls.

That automatic rebalancing can be useful for market efficiency. It can also underperform a passive holding strategy when the two assets diverge sharply in price.

The role of arbitrage in maintaining price equilibrium

Constant product pools do not directly query centralized exchanges, external order books, or price oracles to set their spot price. The price is corrected by traders who identify discrepancies between the pool and external markets.

Assume the global market price of ETH rises from 2,000 USDC to 2,400 USDC, while the pool still implies 2,000 USDC. An arbitrageur can buy ETH from the pool at the outdated price. Each purchase removes ETH and adds USDC. The pool's ratio shifts until the internal price approaches the external market price.

The arbitrageur captures the difference, less:

• the AMM's swap fee;
• network transaction costs;
• execution costs on the external venue;
• the price impact caused by the arbitrage trade;
• any competition from other arbitrageurs.

The pool reaches a more accurate price, but the liquidity providers bear the inventory change. They end up with less ETH and more USDC after ETH has appreciated. That is the mechanical source of impermanent loss.

Arbitrage is not an optional feature

Without arbitrage, AMM prices could remain detached from broader markets. The protocol would still execute swaps, but the quotes could become economically irrational.

Arbitrageurs perform a form of external price synchronization:

1. They observe a difference between the pool price and the external market.

2. They trade in the cheaper venue.

3. Their transaction changes the pool reserves.

4. The reserve ratio moves toward the external price.

5. Competition compresses the remaining discrepancy.

This process is decentralized, but it is not costless. The costs are paid through fees, price impact, and changes in LP inventory.

The design also creates several attack vectors. An attacker may attempt to manipulate a pool's price temporarily, especially when another protocol uses that price as an oracle. A low-liquidity pool is easier to move because a smaller trade can create a larger reserve-ratio change. A protocol that treats an AMM spot price as a trustworthy external valuation is importing the pool's liquidity risk into its own accounting.

The AMM itself may be functioning correctly while the integration fails.

Why the external price source matters

An AMM can correct its own price through arbitrage, but it cannot determine whether the external reference market is reliable. If the reference market is thin, manipulated, or delayed, the arbitrage process may transmit the wrong price into the pool.

This is a general systems problem. A page containing athlete biographies and career facts is not automatically a price oracle, just as a token pair is not automatically a reliable valuation source. Data must be selected, weighted, and validated for the specific function it serves.

For DeFi integrations, the relevant controls include:

• time-weighted average prices rather than a single instantaneous quote;
• sufficient liquidity across the reference venues;
• deviation limits;
• circuit breakers;
• stale-data checks;
• resistance to flash-loan-funded manipulation.

The existence of x * y = k does not provide these controls. It provides a trading curve.

Quantifying impermanent loss in constant product pools

Impermanent loss measures the difference between the value of assets held in a liquidity pool and the value of simply holding the original assets outside the pool.

It is a relative measure. It is not automatically a nominal loss in fiat terms. Both strategies may gain value in a rising market, but the liquidity-pool position can underperform the holding strategy because the pool rebalances inventory against price movement.

For a standard 50/50 constant product pool, the impermanent-loss formula is:

IL = (2 * sqrt(d)) / (1 + d) - 1

Here, d is the relative change in the price ratio between the paired assets.

If the price ratio doubles, d = 2. The resulting impermanent loss is approximately 5.7% relative to holding the original token quantities outside the pool.

The direction of the price move does not change the result. A doubling and a halving produce the same relative divergence when measured symmetrically through the ratio.

What the formula captures

The formula captures the pool's forced rebalancing. As one asset appreciates relative to the other, arbitrage traders remove part of the appreciating asset and deposit more of the depreciating asset. The LP position becomes more concentrated in the asset that performed worse.

The provider has effectively sold some of the outperforming asset as it rose. If the price later returns to its original ratio, the relative disadvantage can disappear. That is why the loss is called impermanent.

If the divergence persists, the opportunity cost persists. If the provider withdraws while the ratio remains displaced, the result becomes realized for that position.

The calculation does not include:

• swap-fee income;
• liquidity-mining rewards;
• protocol emissions;
• gas costs;
• tax effects;
• borrowing costs;
• smart-contract losses;
• changes in the dollar value of the assets themselves.

A pool can have positive fee revenue and still underperform a passive holding strategy. Conversely, a pool with moderate impermanent loss may remain profitable if organic volume is strong and the fee stream is durable.

Fee revenue versus yield compression

Liquidity providers often evaluate pools through APY. This can conceal the actual source of returns.

A pool's gross return may include three distinct components:

Trading fees are the most defensible source because they are connected to actual usage. Incentive yield is more fragile. If a protocol distributes large quantities of its own token to attract liquidity, the headline APY can remain high while the reward token undergoes rapid sell pressure.

That is yield compression in its ordinary form: more capital competes for the same fees, incentives are diluted, and nominal returns fall without a corresponding improvement in risk.

The correct comparison is not the displayed APY against zero. It is the net pool return against a relevant alternative:

• holding both assets;
• staking one asset;
• lending the assets;
• providing liquidity in a lower-risk venue;
• holding a cash-equivalent asset;
• doing nothing.

If the displayed yield depends primarily on emissions, the pool is not necessarily generating income. It may be distributing subsidized tokens in exchange for temporary liquidity.

Correlated pairs reduce one risk, not all risks

Pairs such as stablecoin-stablecoin or closely correlated assets can reduce impermanent loss because their relative price ratio moves less. That does not make them risk-free.

The remaining risks may include:

• stablecoin depegging;
• bridge failure;
• faulty token accounting;
• oracle manipulation;
• admin-key abuse;
• contract vulnerabilities;
• systemic insolvency elsewhere in the protocol stack.

A pair of assets that normally tracks one another can experience severe divergence during a stress event. Correlation is a historical property, not a contractual guarantee.

Why infinite liquidity remains a theoretical ideal

The constant product curve provides continuous execution, but execution quality depends on depth. The pool's reserves determine how much capital can trade before slippage becomes excessive.

For a small trade relative to pool size, the curve may produce an acceptable result. For a large trade, the average execution price can diverge sharply from the initial spot price.

The distinction between spot price and execution price is operationally important:

• Spot price is the current reserve ratio, y / x.
• Execution price is the output received divided by the input paid.
• Price impact is the change caused by the trade itself.
• Slippage tolerance is the maximum adverse movement the trader permits before the transaction reverts.

A user may see a reasonable spot price and still receive a poor execution price because the requested trade is large relative to the reserves.

The cost of thin liquidity

Thin liquidity creates a feedback loop:

1. A trade causes significant price impact.

2. Arbitrageurs extract value from the displaced reserve ratio.

3. Liquidity providers receive fees but hold a less favorable asset mix.

4. Some providers withdraw, reducing reserves further.

5. The next trade causes even larger price impact.

The loop is self-reinforcing unless new capital enters the pool. A pool that once attracted volume can lose it to deeper venues or to liquidity-mining programs elsewhere, accelerating the decline.

Depth is not a fixed property of a token pair. It reflects the aggregate decisions of capital allocators responding to incentives, risk perceptions, and competing opportunities across chains.

Routing, aggregation, and the user experience

Most retail traders do not interact with a single pool directly. They use routers and aggregators that split orders across multiple pools to minimize total slippage.

From the user's perspective, the experience resembles a centralized exchange: a quoted price, an execution price, and a single transaction. Behind that interface, the router is solving a path-finding problem across a fragmented landscape of pools, each with its own depth, fee tier, and reserve composition.

This aggregation layer does not change the underlying mechanics. Each pool still executes its swap along its own curve. The router simply chooses how to distribute the trade so that the marginal cost of the next unit of output is as close as possible to the displayed price.

The benefit to liquidity providers is that they face fewer full-size swaps and more fragmented flow. The cost is that they compete for that flow with every other pool along the candidate route. Fee tiers, incentive programs, and token emissions all become tools in that competition.

Where the formula stops being enough

The constant product invariant works well within its assumptions:

• continuous trading;
• rational arbitrageurs;
• assets that can be rebalanced without external constraints;
• prices that converge to a single external reference.

It works less well when those assumptions break:

• concentrated ranges in modern AMMs replace the full curve with a focused band;
• pegged assets benefit from curves designed around a fixed ratio;
• assets with transfer taxes or rebasing mechanics interfere with the invariant;
• chains with high latency or mempool manipulation expose traders to sandwich attacks.

The formula is a foundation, not a ceiling. Subsequent AMM designs—Uniswap v3, Curve's StableSwap, Balancer's weighted pools—modify the curve to fit specific asset profiles. The constant product model remains the baseline reference against which those designs are usually explained.

What providers actually take home

The net return to a liquidity provider depends on:

1. The size of fee revenue captured relative to the provider's share.

2. The magnitude and direction of impermanent loss over the holding period.

3. The dollar value of any incentive tokens received and the timing of their sale.

4. Gas and operational costs of entering, rebalancing, and exiting positions.

5. Losses from smart-contract incidents, which are not diversifiable through pool selection alone.

When this arithmetic is done honestly, the conclusion is rarely "yield." It is "compensation for inventory risk, paid in fees, with a residual claim on whatever shape the inventory ends up in."

That is the working contract of a constant product pool. The formula provides the trading surface. The provider absorbs the inventory mismatch. Arbitrageurs keep the pool aligned with the rest of the market. The protocol collects a small fee on each unit of flow. Each participant is paid for a specific function, and each function has a cost attached.

Understanding which function you are performing—and which cost you are absorbing—is the difference between providing liquidity and subsidizing it.