Coinatio Research
Liquidity8 min read

How to Measure DEX Liquidity Depth

DEX liquidity depth is the amount that can be traded before execution moves materially away from a reference price. Total value locked is a useful first observation, but it does not reveal quote side inventory, active ranges, order direction, or liquidity available across nearby ticks. Measuring depth requires an executable question such as how much can be bought within 2 percent. This article is educational and not financial advice.

Editorial research by Coinatio, checked against the primary documentation cited below. Educational content only.

Editorial illustration for How to Measure DEX Liquidity Depth
Key takeaways
  • Define depth by direction, order size, price band, venue set, and timestamp.
  • Simulated output is more informative than total value locked for a specific trade.
  • Concentrated pools require tick level analysis because inactive value does not support current swaps.
  • Cross pool aggregation must account for fees, routes, stale prices, and duplicate or unreliable markets.

Choose an executable definition

Depth has no complete meaning without parameters. One useful definition is the maximum exact input order that executes within a selected percentage of the pre trade mid price. State the token direction, maximum impact, pools included, fee treatment, and block height. Buy depth and sell depth differ because the available quote asset and project token inventories differ, especially after a strong move or in concentrated pools.

For example, ask how much USDC can buy MINT before the average execution price is 2 percent above the initial pool price. This is different from asking how much MINT can be sold before the average result is 2 percent below it. It is also different from measuring the final marginal price. A consistent study should declare whether its threshold applies to average execution or ending spot price.

Calculate a constant product baseline

For reserves x and y with a fee free constant product invariant x * y = k, adding quote amount dy produces a new quote reserve y + dy and token reserve xNew = k / (y + dy). Output is x - xNew. Average execution price is dy / output. A real calculation reduces dy by the protocol fee before applying the invariant and should use exact integer and decimal behavior from the contract.

Assume 500,000 MINT and 250,000 USDC, so the initial price is 0.50 USDC. A 5,000 USDC input gives xNew = 125,000,000,000 / 255,000, or about 490,196.08 MINT. Output is about 9,803.92 MINT, and average price is 0.51 USDC, approximately 2 percent above the starting quote before fees. This gives a rough buy depth near 5,000 USDC for that chosen definition.

Measure concentrated liquidity correctly

A concentrated pool cannot be summarized by applying one reserve ratio to its total value. Liquidity changes at initialized ticks. A simulator must start at the current square root price, consume available liquidity until the next tick, apply the tick's net liquidity change, and continue until the input is exhausted or a price limit is reached. The output is therefore assembled across multiple local curve segments.

A pool might report 2,000,000 USDC of marked value while only 150,000 is positioned around the current price. Another pool with 500,000 total value could have most of it active nearby and offer better depth for a small trade. Uniswap and Raydium concentrated liquidity documentation explains range behavior, but current onchain positions are needed for an actual measurement.

Aggregate venues without double counting

A token may trade against USDC, USDT, SOL, ETH, and wrapped variants across several DEXs. To estimate aggregate depth, normalize quote values, verify token and pool addresses, and simulate feasible routes. An optimizer can split an order where marginal execution improves, but route hops add fees and gas. Stablecoins should not automatically be treated as exactly equal when their market prices differ.

Exclude or clearly flag pools with stale activity, anomalous token behavior, inaccessible liquidity, or unreliable quote assets. Do not add each pool's standalone 2 percent depth as if all reference prices were identical. Executing against one pool changes arbitrage incentives and may alter the others before a multi transaction order completes. Atomic routing and sequential manual trades have different outcomes.

Validation, limitations, and reporting

Validate model outputs against a protocol quoter or a read only transaction simulation at the same block. Test several order sizes in both directions and report average price, ending price, fees, route, minimum output, and block timestamp. CoinGecko and CoinMarketCap liquidity or volume displays can support discovery, but provider data may be aggregated, delayed, or based on methodologies different from a direct onchain simulation.

Depth changes whenever swaps, deposits, withdrawals, price ranges, or quote asset values change. A simulation cannot guarantee future execution, and visible liquidity does not by itself establish token safety. Contract restrictions and transfer fees can invalidate standard formulas, so token details may need checks through source code and services such as GoPlus. A transparent depth report is reproducible, directional, time stamped, and explicit about every excluded venue.

Sources

  1. Uniswap Docs: Swaps in Uniswap v3
  2. Raydium Docs: Concentrated Liquidity Pools
  3. CoinGecko: Methodology
  4. CoinMarketCap Support: Market Data

This article explains technical and market-data concepts. It is not financial, legal, tax, or investment advice. Verify current chain state and primary documentation independently.

Continue researching