The Liquidity To Market Cap Ratio, Computed Properly

The liquidity to market cap ratio divides the value sitting in pools by the valuation the market is assigning to the token. It exists because a market cap is a multiplication that assumes every unit could be sold at the last price, and liquidity is the only figure on the page that tests that assumption. Computing it well means fixing three conventions the dashboard applies silently.

Why this ratio exists

Market cap takes a price set by the most recent trade and applies it to the entire circulating supply. On a deep, liquid pair that is a reasonable approximation. On a thin pair it is a statement about a price that only existed for one small transaction, extended to a quantity of tokens that could never be sold at anything like it.

Liquidity is the counterweight. It is the value actually deposited in pools, available to absorb trades right now. Dividing one by the other produces a percentage that answers a blunt question: if the market wanted to realise this valuation, how much of it could the pools absorb before the price stopped resembling the quoted one?

What reported liquidity actually contains

On a constant-product automated market maker, a pool holds two reserves and prices trades so that their product stays constant across a swap, before fees. That relationship is the whole pricing mechanism, and it means the depth available on either side is finite and knowable.

When a dashboard reports liquidity, it almost always reports the combined value of both reserves, across every pool it indexes for that token. So a pool holding 500 SOL and the token equivalent at the current price is reported at roughly double the SOL-side value. That is a legitimate convention: it describes the total value deposited. It is a poor guide to what you could extract, because selling tokens into the pool draws only on the SOL side.

Concentrated liquidity venues complicate this further. In a concentrated design, providers place liquidity within chosen price ranges, so the total value deposited can be large while the depth immediately around the current price is small. Reported liquidity counts the deposit; your fill only touches the range you trade through.

Three decisions that change the answer

Before computing anything, decide these three things and state them. Any ratio quoted without them is not comparable with any other ratio.

1. One side or both. Both sides is the reported convention. One side, specifically the quote asset, is the conservative reading and roughly halves the ratio.
2. One pool or all pools. Summing every pool treats separate venues as a single book. They are not: your order routes through them at separate prices with separate impact. The largest single pool is the honest denominator for a single trade.
3. Which market cap. The dashboard's, based on its circulating supply policy, or your own recomputed figure. Using FDV instead produces a much lower ratio and answers a different question about long-term absorbability.

None of the six combinations these produce is wrong. What is wrong is comparing a both-sides, all-pools, dashboard-market-cap ratio for one token against a one-side, largest-pool, own-market-cap ratio for another and concluding something about their relative fragility.

Worked example: the same token, three ratios

Depth is what you trade against, not the total

The reason convention C matters is that pools do not aggregate into a single book. If you sell into the deepest pool, you move its price; a router may then take the next slice into the second pool, at its own price and its own impact. Splitting reduces total impact compared with dumping everything into one pool, but it never gives you the summed depth as though it were one reserve.

This is why traders regularly report that slippage was far worse than a healthy-looking liquidity figure suggested. Nothing malfunctioned. They read a both-sides, all-pools total and executed against a one-side, one-pool depth. The practical mechanics of sizing an order against real reserve depth are worked through in this guide to trade sizing and pool depth.

Turning the ratio into an expected cost

The ratio becomes far more useful when you convert it into an expected price impact for an order you might actually place. On a constant-product pool, ignoring fees, the fractional price impact of selling an amount into a reserve has a compact closed form.

Reading the ratio in bands

Bands are more honest than thresholds, because the ratio is a rough instrument. The table below describes what each band implies mechanically, not whether a token is good or bad, which is not a question this figure can answer.

Locked liquidity answers a different question

Liquidity locks are quoted alongside the ratio so often that the two get conflated, and they are not the same kind of fact at all. The ratio describes how much depth exists. A lock describes whether the person who deposited it can take it away. Confusing the two produces the common and expensive error of reading a lock as though it made a shallow pool safe to trade in size.

Mechanically, depositing into a pool returns a position representing your share of the reserves. Whoever holds that position can withdraw the underlying at any time. A lock removes that ability, either by sending the position to a program that will not release it until a date, or by destroying it outright so that nobody can ever withdraw.

What a lock genuinely rules out is one specific event: the deposited depth disappearing in a single transaction. That is worth confirming, and it is checkable. What a lock does not do is change the shape of the curve. If the pool is thin, your order still moves the price by exactly the same amount whether the position is locked, burned or freely withdrawable. Impact is a function of reserves, and a lock does not add reserves.

There are three states worth distinguishing when you record this, and lumping them together loses most of the information. A burned position is permanent and requires no trust. A time-locked position is temporary and its expiry date is the number that matters, since a lock expiring next week is nearly the same as no lock at all. An unlocked position held by an unclassified wallet is simply an open question about who that wallet is.

Record the lock state as its own line with its own evidence, never folded into the ratio. On a scorecard these are two separate checks that fail for separate reasons: depth can be adequate while removal risk is open, and depth can be inadequate while the position is permanently burned. Treating them as one line guarantees that at least one of those situations gets misread.

Where the ratio stops working

Being clear about the limits protects you from over-using a convenient number. There are four situations where the ratio is actively misleading rather than merely rough.

• Concentrated liquidity positions. Value deposited outside the active range contributes to reported liquidity and nothing to your fill. The ratio can look comfortable while the depth at spot is negligible.
• Bonding-curve tokens before migration. A curve is not a pool with reserves in the usual sense. Applying a pool-based ratio to it compares two different mechanisms.
• Tokens with most supply excluded from circulating. A small circulating supply produces a small market cap and therefore a flattering ratio, while the excluded supply still exists and can arrive later.
• Very recent liquidity changes. Liquidity is a snapshot. A large deposit or withdrawal minutes ago makes the ratio describe a state that no longer holds.

There is also a behavioural limit. A thin ratio combined with heavy reported volume is a common pattern, and it is the pattern most consistent with continuous automated flow, since a volume bot for Solana can cycle the same shallow reserves indefinitely without the depth ever growing. It is equally consistent with an active speculative market on a small pair. The ratio narrows the explanations; it does not choose between them.

Computing it yourself

1. Find the pools. List every pool holding the token, with its venue and its two reserve balances. An explorer's markets or pools view for the mint is usually enough.
2. Identify the quote asset. Usually SOL or a stablecoin. Record only that side's balance for the conservative reading.
3. Value the quote side. Multiply by the quote asset price. For a stablecoin pair this step is trivial.
4. Pick your denominator. Either the dashboard market cap or one you recomputed from mint state. Note which you used.
5. Divide and record all three conventions. Both-sides all-pools, quote-side all-pools, quote-side largest pool. Reporting all three costs nothing and prevents the comparison error entirely.
6. Convert to an impact figure. Apply the impact formula for an order size you would realistically place. This is the number that changes behaviour.
7. Check whether liquidity is locked, and note that separately. A lock addresses removal risk, not depth. Recording it in the same field as the ratio conflates two different things.

Recording all three conventions has a second benefit: the spread between them tells you how much of the reported figure is convention rather than depth. A token where all three land close together has liquidity concentrated in one honest pool. A token where they diverge widely has its depth scattered, and scattered depth behaves worse under pressure than the total suggests. Both readings feed straight into the scorecard, where the ratio is one of the few lines with a defensible numeric pass condition.

Questions the desk gets asked