Liquidity depth

Depth is measured inside a band

The general markets definition is the volume of buy and sell interest at various price levels away from the current mid-price.¹ Order book venues show this directly as resting orders at each level. Pooled venues do not have levels, but the same question applies: how much can be traded before the price passes a threshold you named in advance.

That framing is why depth is the operative number and total value locked is not. A constant-product pool holds reserves priced for every outcome the pair could ever have, so only a slice of it is available near where the market currently is. A concentrated position holds capital only inside its band, so depth inside that band is high and depth outside it is zero. Two pools with identical headline capital can behave completely differently for the trade you are about to make.

The two percent convention

The convention institutional data providers settled on is depth within 2% of mid: the dollar value that could be traded before moving the price 2% in either direction. Practitioner documentation of the method describes it as the standard benchmark for comparing liquidity across exchanges and pairs, and the basis on which vendors including CoinGecko and Kaiko rank venue liquidity.³

Two percent is arbitrary and useful for the same reason: it is small enough to describe tradability and consistent enough to compare venues. Adopt it because everybody else has, then add the bands that matter for your own case. A treasury planning $500,000 sales cares about depth at 5% and 10%, not at 2%.

Be careful with any specific depth figure you find quoted for a named pair. Most circulating numbers carry no as-of date and no methodology, and depth for a volatile pair changes materially through a single day.

Total value locked describes a protocol, not a pair

DefiLlama's public API reported Uniswap's aggregate total value locked, across every version and every chain, at $3,059,619,528.30 on 3 August 2026.² That is a real figure and it is a point-in-time read that will be different when you check it.

It also cannot answer a single trading question. It says nothing about how far a $200,000 sale moves any one pair, because it aggregates thousands of pools, most of which have nothing to do with the asset in front of you. Protocol totals are useful for tracking where capital sits across the market. They are the wrong instrument for deciding whether your pool is deep enough.

Specify depth as a triple

Write the requirement as a sentence with three numbers in it. The largest single trade the pool must absorb, in dollars. The band or price move you will accept for it, as a percentage. And which price you mean, the average the trader receives or the marginal price the pool is left quoting, because those differ by roughly a factor of two in a constant-product pool.

That sentence is testable before launch and auditable after it. Depth becomes a target somebody has to fund rather than a percentage inherited from an allocation table, and the argument moves from what feels right to what the pool has to hold.

Where teams get depth wrong

The most common error is quoting total value locked in an investor update as though it described tradability. The second is measuring depth once, at launch, and never again, when the number moves every time a provider adds or removes a position and every time price leaves a concentrated band.

The third is designing depth for the wrong participants. Depth requirements come from the trade-size distribution of the people who actually hold your token, which you can read off your cap table and your holder distribution. A pool sized for retail flow will be hostile to the seed investor unwinding, and a pool sized for institutional flow is expensive to fund and mostly idle. Neither is a modelling problem. Both are a question nobody asked.