Why a token's liquidity must be checked pool by pool

A token can trade in many pools, each with different counterpart assets, fees, ranges and depth. Its combined liquidity total does not describe the particular pool your quote uses.

Identify the venue precisely

Record the network, token contracts, protocol version and pool identifier. In systems that use one contract per pool, the pool address is the key identifier. Other architectures can identify multiple pools within a shared contract, so the contract address alone may be insufficient.

A label such as TOKEN/USDT does not identify a unique venue. Several pools can use that pair while holding different reserves or fee settings.

A token-wide total can overstate the route

Suppose a hypothetical token has $5 million reported across all pools, but the selected path uses a $50,000 connecting pool. The global total does not enter that pool's pricing calculation. Other capital helps only if the route can access it on usable terms.

Each Uniswap v2 pool is a trading venue for a pair. A token-level analytics page aggregates a different scope from that individual venue.

Check the identity at every observation

When a quote refresh changes pools, a comparison against the old pool's depth can become irrelevant. Preserve the route disclosed for each quote rather than assuming a token always uses its largest pair.

Also check whether a token-wide total includes other networks, inactive ranges or duplicate indexing entries. Do not add those values to local executable capacity without establishing access and independence.

For a report, provide the broad liquidity total as context and the actual route-level evidence as the basis for execution claims. If the interface does not disclose enough to identify the pool, state that limitation. A precise token contract does not by itself supply the missing pool identity or prove which liquidity produced the offered rate.