There is no standard playbook for multi-chain liquidity modelling at digital asset research desks. The tools are fragmented, the data sources are inconsistent across chains, and the underlying pool mechanics differ enough that a model calibrated for Uniswap v3 on Ethereum requires significant rework before it is meaningful for a concentrated liquidity pool on Osmosis DEX or a Curve-style stableswap on Polygon. What exists in practice is a collection of approaches, each with specific failure modes that practitioners have learned to work around.
This piece is a survey of those approaches as we have encountered them in conversations with research teams doing cross-chain liquidity analysis today. It is not based on a formal survey methodology. It reflects patterns we have seen repeatedly in how teams construct their models and where the models break down.
The TVL-proxy approach and its limitations
The most common starting point is TVL as a liquidity proxy. It is available from aggregators for almost every DEX pool, it is updated frequently, and it has an intuitive interpretation: higher TVL implies more capital available for trading. Most research teams that are not specifically focused on execution quality use TVL as their primary liquidity metric.
The failure modes of TVL-proxy models are well-documented but frequently underweighted in practice. TVL captures total capital, not capital available at execution-relevant price ranges. For concentrated liquidity pools, particularly those with actively managed positions, the capital within a few percent of the current price (which is what determines actual execution depth) can be a small fraction of total TVL. A pool with $50M TVL might have less execution-relevant depth than a pool with $15M TVL if the $50M pool has LP positions spread widely across price ranges while the $15M pool has positions tightly concentrated near the current price.
TVL-proxy models also fail at range boundaries. When the price moves outside the active range of a concentrated liquidity pool's major LP positions, depth drops sharply. TVL stays the same (the tokens are still in the pool) but executable depth for standard trade sizes can decrease by 60-80% as the active liquidity band exits the price vicinity. Research models that track TVL as a smoothly varying signal will miss this cliff behavior.
Volume-adjusted TVL and its common misuse
A step up from pure TVL is volume-adjusted TVL, sometimes formulated as the ratio of 24-hour volume to TVL as a capital efficiency metric. Higher volume-to-TVL suggests a pool is more actively traded relative to its size, which is loosely correlated with deeper markets and tighter pricing. Some research models use this ratio to weight pools when computing cross-chain liquidity scores.
The misuse here is treating volume-adjusted TVL as a forward-looking depth indicator. It is not. The ratio tells you how efficiently the pool's capital has been utilized historically, which is useful for comparing pool economics or identifying protocols with efficient capital deployment. It does not tell you whether the pool can absorb a specific trade at an acceptable execution cost right now.
More subtle: a high volume-to-TVL ratio in a recent window can be caused by a large directional trade that moved through the pool with elevated slippage. The trade inflated the volume figure while reducing the pool depth. A research model that sees high volume-to-TVL and interprets it as deep liquidity will draw the wrong conclusion in exactly the cases where the pool is most stressed.
Direct depth computation: the more accurate approach
Research teams with the infrastructure to query pool state directly can compute depth at specific price impact thresholds rather than proxying with TVL. For a constant-product pool, this is a direct calculation from the reserve ratio. For a concentrated liquidity pool, it requires computing the aggregate active liquidity within the target price band, which means reading the active tick state, not just the TVL.
The challenge is that this computation requires access to pool-level state beyond what most aggregators expose. Standard API endpoints typically return TVL, volume, fee tier, and current price. Depth at impact thresholds requires either the full tick bitmap for concentrated liquidity pools (a significantly larger data payload) or a specialized depth endpoint that a small number of providers offer. The data engineering burden of maintaining this computation across multiple chains is the primary reason most teams default to TVL proxies even when they understand the limitations.
Teams that do direct depth computation typically focus on a specific set of pools for their most important trading pairs rather than maintaining depth data across the full long tail of pools. The workflow is: identify the pools most likely to be relevant for trading decisions, compute depth for those pools at regular intervals, use TVL proxies for the rest when needed as a rough signal rather than a precise estimate.
Multi-chain aggregation: where the models diverge most
Aggregating liquidity across chains introduces a set of comparability problems that no existing model handles cleanly. The most direct issue is that depth on chain A for a token that also has a pool on chain B is not simply additive. Accessing liquidity on chain B requires a cross-chain transfer (via IBC or a bridge), which has its own cost and latency. The "total available liquidity" for an asset is not the sum of depth across all chains but something more like a weighted sum where the weight reflects the cost and speed of accessing each source.
Different teams handle this differently. Some simply sum depth across chains and note that cross-chain access is an additional cost. Others apply a discount factor for each chain's depth based on an estimated cross-chain execution cost, which requires assumptions about bridge fees and destination pool slippage that are themselves uncertain. Both approaches produce a cross-chain liquidity score that is useful for comparative analysis but should not be interpreted as a precise execution cost estimate.
The models that perform best for research purposes tend to be explicit about the access cost structure rather than trying to roll everything into a single number. Presenting depth by chain with explicit cross-chain access cost assumptions is more useful for a research reader than a single aggregated figure whose composition is opaque.
Where automated depth feeds change the workflow
The most meaningful workflow change from having automated depth feeds rather than manual block explorer exports is not in the model itself but in the cadence of updates. Manual export workflows are typically done once per week or in preparation for a specific report. Automated depth feeds enable research teams to track depth continuously and to catch structural changes, such as significant LP withdrawals or protocol upgrades affecting pool mechanics, as they happen rather than discovering them retrospectively.
The secondary benefit is coverage breadth. A manual workflow covering 20 pools across 4 chains is a substantial ongoing effort. An automated feed covering the same scope is a backend infrastructure cost that does not scale linearly with pool count. Research teams that have made the switch from manual to automated depth data typically expand their coverage significantly within the first few months, which changes the research questions they can ask and answer.
The limitation of automated feeds is that they are only as reliable as the underlying data pipeline. Depth computations for concentrated liquidity pools require correct tick state, which can occasionally be stale or missing in indexed data if the indexer misses blocks or handles protocol upgrades incorrectly. Research teams using automated depth feeds need to maintain data quality checks, particularly around protocol upgrade events when pool mechanics change and the indexer's computation logic may need updating.