Decentralised exchanges: liquidity pools, slippage and provider returns

A decentralised exchange is a mechanism, not a single design

Decentralised exchanges use on-chain arrangements to facilitate asset exchange, but they do not all use the same market structure. Some rely on order books or other mechanisms; this guide focuses on automated market makers that trade against liquidity pools. In a pool, liquidity providers supply assets and traders exchange against reserves according to contract rules. The economic roles differ: a trader seeks execution, while a provider accepts an evolving asset position in exchange for potential fee income. Calling the arrangement decentralised does not remove market risk, software risk or dependencies on interfaces and infrastructure. A useful analysis begins with the exact protocol version, pool design and assets involved. It should distinguish the trading mechanism from any governance token associated with a project. A functioning exchange contract does not by itself establish the investment value of a separate token.

Constant product links reserves and marginal price

A simplified full-range constant-product pool holds quantities x and y of two assets and follows x × y = k. Ignoring fees and changes in supplied liquidity, a swap changes the reserve quantities while preserving their product. The marginal price of asset x in units of asset y is y/x under this model. That is a local price for a very small trade, not a promise that an arbitrarily large order will execute entirely at the same rate. As one reserve is removed and the other added, the price changes along the curve. This mechanism provides a transparent relationship between trade size and execution, but it does not determine an asset's fundamental value. External markets and arbitrage help connect the pool's relative price with wider trading conditions. The formula describes inventory-based exchange, not an independent guarantee of fair valuation.

A larger trade changes its own execution price

Consider a hypothetical fee-free pool containing 10 units of A and 1,000 units of B, with k = 10,000 and an initial marginal price of 100 B per A. A trader supplies 100 B to buy A. The new B reserve is 1,100, so the A reserve becomes 10,000/1,100, approximately 9.0909. The trader receives about 0.9091 A, giving an average execution price of 110 B per A. The ending marginal price is 1,100/9.0909, approximately 121 B per A. These are three different prices: the initial marginal price, average execution price and ending marginal price. The example excludes fees, network costs and other trades. It demonstrates why dividing an order by the starting quotation overstates the amount received when the order is large relative to pool depth, even if nobody else trades before it.

Price impact and execution slippage need separate treatment

Price impact is the movement caused by a trade relative to available liquidity. Execution can also differ from a prior quote because the pool changes before the transaction is processed. Interfaces use the word slippage in different ways, so a report should define whether it means total deviation from an earlier expectation or only changes after quoting. A minimum-output condition can cause a transaction to fail rather than execute outside its specified bound, but failure can still involve network costs and opportunity costs. Transaction ordering matters because earlier swaps change the reserves faced by later swaps. Some forms of maximal extractable value exploit inclusion or ordering opportunities, including arrangements that worsen another trader's execution. This is a market-structure risk, not a claim that every price difference is manipulation. Analysis should separate predictable curve impact, ordinary market movement, fees and adversarial ordering.

A liquidity provider holds changing quantities

Providing liquidity is not equivalent to placing two assets in passive storage. Traders alter the pool's composition, and a provider's claim follows that evolving inventory. When the external relative price changes, arbitrage can remove the asset that has become more valuable relative to the pool's old price and add the other asset. The provider consequently holds a different combination from the one originally deposited. Fee income compensates for supplying this service, but it should be assessed alongside the inventory change rather than presented as a separate guaranteed return. The relevant comparison depends on the question. A provider can make a nominal gain while underperforming a strategy of simply holding the original quantities. It can also lose nominal value because both underlying assets fall. Those are distinct outcomes, and a complete performance explanation should identify the benchmark used before reporting whether the position gained or lost.

Impermanent loss is a comparison with holding

For a full-range 50/50 constant-product pool, after external arbitrage aligns prices, the fee-free relative value versus holding the original assets is 2√r/(1+r) − 1, where r is the change factor in their relative price. Assume no fees, costs, deposits or withdrawals. If A doubles in B terms, r = 2 and the relative difference is approximately −5.72%. Using the earlier hypothetical starting reserves of 10 A and 1,000 B, the final pool holds about 7.0711 A and 1,414.21 B. At 200 B per A, its total value is about 2,828.43 B, compared with 3,000 B from holding the original quantities. The pool has gained from its initial 2,000 B value while still underperforming holding. The term 'impermanent' does not promise recovery; the price may never return, and the comparison can remain adverse when liquidity is withdrawn.

Concentrated liquidity changes the exposure

Some AMMs allow providers to allocate liquidity within a chosen price range instead of across the full curve. This can concentrate capital where trades occur, but it also changes the position's behaviour as prices move. When price leaves the active range, a position can stop earning swap fees and become concentrated in one asset until conditions change or the position is adjusted. The full-range impermanent-loss example should not be applied mechanically to such a position. Its lower and upper bounds, entry price and subsequent path matter. A high displayed fee rate over a short interval can coexist with inventory losses, inactivity or management costs. Narrower allocation is therefore not simply a free improvement in return. The appropriate analysis reconstructs the position's actual asset quantities, active periods, earned fees and expenses rather than assuming that all capital labelled as liquidity is available at every price.

Fee revenue is not net profitability

Fees depend on pool rules, trading volume, the provider's active share and any allocation to the protocol. Distribution and reinvestment mechanisms vary across versions, so fee figures need an explicit definition. Token incentives can add another component whose market value may change independently of underlying swap activity. Annualizing a brief burst of revenue can make a temporary episode look like a stable income stream. Performance measurement should distinguish gross fees from net results after inventory effects, network charges and any position-management costs. It should also compare equivalent periods and valuation units. High trading volume is not automatically beneficial if much of that flow arrives when the pool's price is stale relative to external markets. A provider is supplying a market-making service and accepting related exposures. The economic question is the total outcome of that service, not the isolated size of the fee counter.

Smart contracts and price inputs create additional dependencies

A pool can follow its mathematical rule correctly while users still face risks from token behaviour, contract vulnerabilities or the broader application using its price. A simple constant-product swap need not consult an external oracle to determine its reserve-based exchange rate. However, lending or other protocols may use pool prices as inputs, and that creates a separate question about manipulation resistance, freshness and market depth. A spot price from a thin pool is not automatically a reliable valuation for a large collateral position. Time averaging and multiple sources can change the risk profile, but they do not remove every trade-off. Software audits also provide bounded evidence rather than a guarantee against all future failures. Evaluation should identify contract permissions, upgrade paths, external dependencies and the consequences of incorrect data, keeping mathematical correctness separate from operational and economic robustness.

Read a pool through its complete economic mechanics

A reproducible liquidity-pool analysis records the assets, protocol version, pricing rule, fee treatment and valuation date. For a trade, it separates initial price, curve impact, expected output, execution changes and network costs. For a provider, it records deposited quantities, active ranges, inventory changes and all revenues and expenses, then states the comparison benchmark. Hypothetical calculations should list simplifying assumptions so that readers do not mistake a teaching model for a live quote. Market structure also matters: liquidity can be fragmented and sophisticated participants can respond faster to changing conditions. Open access does not imply equal outcomes or eliminate the value of information and infrastructure. The purpose of this framework is to explain where execution and provider returns come from, including the risks that formulas leave outside the model. It is an educational account of exchange mechanics, not a recommendation to trade or supply liquidity.

Explore the data and markets