Volume Against Liquidity: Turnover And What It Bounds
Turnover is volume divided by the depth those trades passed through. It is one division, it uses two numbers already printed on any token page, and it converts an unreadable headline into a statement about how hard the pool was worked. It also has four failure modes, and they are worth knowing before you quote it.
Turnover
- The figure
- Window volume divided by the value of the reserves available when the reading is taken, expressed as a plain multiple.
- Context it needs
- Liquidity is a snapshot and volume is a window, so the ratio is an order of magnitude rather than a precise quantity. It also assumes the depth did not change materially during the window.
- Mistake it prevents
- Reading a large volume figure as a sign of a large market, when the same figure against shallow reserves means the same small market was traded through many times.
Turnover is window volume divided by the depth those trades passed through. One division, two numbers already on the page, and the headline stops being ambiguous. A turnover near one says the pools traded roughly their own depth. A turnover in the tens says the same reserves were cycled repeatedly, which means the market is small and busy rather than large.
Turnover, defined and computed
turnover = volume over window W / liquidity at the time of readingvolume covers a period, liquidity is a snapshot; treat the result as an order of magnitude rather than a precise figureBoth inputs sit next to each other on a standard token page and nobody divides them. The result is a plain multiple with no units, which makes it directly comparable across tokens in a way that raw volume never is. That comparability is the entire value of the ratio.
The reason it works is that volume alone has no scale. Eighty thousand of volume is large or small depending on what it passed through, and there is no way to know which from the number itself. Dividing by depth supplies the missing scale, and the resulting multiple answers a question a reader actually has: how hard was this market worked?
Why depth is the right denominator
Several denominators are available. Market capitalisation is a popular one, and it is the wrong choice for this purpose, because market capitalisation is a valuation derived from a price that the pool itself sets. Dividing flow by a figure that is downstream of the same pool mixes two effects and produces a ratio that moves for reasons unconnected to activity.
Depth is the right denominator because it is the quantity that flow actually consumed. When a trade executes, it moves against reserves; the reserves are the resource being used. Turnover therefore has a physical interpretation: it is a utilisation ratio, and utilisation ratios are stable and comparable in a way that valuation ratios are not.
Transaction count is the other useful denominator, and it answers a different question. Volume divided by count gives average trade size, which describes the shape of individual trades. Volume divided by depth describes the intensity of use. Neither replaces the other, and using both is standard practice at this desk.
The arithmetic underneath: price impact
Turnover is informative because of what depth does to a trade. In a constant-product pool the two reserves multiply to a constant, so buying moves the price by an amount that depends on the size of your order relative to the reserve you are draining. The relationship is simple enough to compute by hand.
price movement fraction, approximately = order size / (reserve on the side being paid in + order size)constant-product approximation with fees excluded, so the effect of depth alone is visibleIllustrative: the same order into three depths
Figures invented by the desk to show the shape of the relationship. Fees are excluded so the depth effect stands alone. No real pool is described.
An order of 500 into a quote reserve of 25,000. 500 divided by 25,500 is about 1.96 percent. A single retail-sized trade moves this pool by roughly two percent.
The same 500 into a quote reserve of 120,000. 500 divided by 120,500 is about 0.41 percent. Noticeable, tolerable, and roughly a quarter of the previous case.
The same 500 into a quote reserve of 900,000. 500 divided by 900,500 is about 0.06 percent. Effectively invisible.
Same order, thirty-fold difference in cost, and all three trades add exactly 500 to a volume figure. This is the reason a volume figure alone cannot tell you what a market is like to trade in.
The mechanics of the pool types this arithmetic applies to, including how fees are taken and where reserves are held, are documented in Raydium's own documentation. The reserve balances themselves are ordinary token accounts, so you can confirm a pool's depth directly rather than trusting the dashboard field, using an explorer view of the pool accounts.
Turnover bands and what each one supports
Bands are a reading aid, not a classification system. The boundaries are the desk's own and are chosen to be memorable rather than precise, and the point of each band is what it rules out rather than what it proves.
| Turnover | What it describes | What it rules out |
|---|---|---|
| under 0.5 | Flow well below available depth; trades absorbed with little movement | Any reading in which the market is being cycled |
| 0.5 to 2 | Flow of roughly the same order as depth over the window | Both extremes; this is the least informative band |
| 2 to 10 | Reserves worked several times over; each trade visibly moves price | The reading that the market is deep because volume is large |
| over 10 | Sustained cycling of shallow reserves, with a fee bill to match | Any inference that headline volume represents net entering value |
The top band is where most misreading happens, and it is worth being precise about what it does and does not support. It supports the statement that a small amount of depth handled a large amount of flow. It does not support a statement about who produced the flow or why. Both a busy market with real two-way interest and a continuously running automation produce high turnover, and turnover alone cannot separate them.
What the liquidity field actually contains
Before dividing by liquidity it is worth knowing what the field holds, because the conventions vary and the differences are large enough to matter.
- Both sides summed. The most common convention. A balanced pool holding 50,000 of quote asset and 50,000 worth of token reports 100,000. Your own order only interacts with one side, so the relevant depth for execution is roughly half the reported figure.
- All pools for the pair. Correct as a total of available reserves, misleading as a statement about a single execution, because those pools are not one book and you cannot trade against their combined depth at one price.
- Concentrated or dynamic liquidity. In pool types where liquidity is placed in ranges, the total deposited value overstates what is available at the current price. Depth near the price is what matters and it is not what the summary field reports.
- Stale or cached values. Reserve values are read at some point and displayed until refreshed. In fast-moving situations, particularly around liquidity being added or removed, the displayed figure can lag reality noticeably.
None of these makes the turnover ratio useless. They make it approximate, and they mean the ratio is best used to distinguish 0.2 from 20 rather than 2.0 from 2.4. Used at that resolution it is robust to every convention listed above.
The curve case, where no denominator exists
Launchpad curve tokens report volume without a comparable liquidity figure, because a curve does not hold a withdrawable two-sided reserve in the way a pool does. Depth on a curve is fixed at deployment by the curve parameters, and nobody can add to it or take it away.
The tempting move is to substitute something: the SOL held by the curve, or the notional value of the remaining curve supply. Both produce a number. Neither produces a number comparable to a pool turnover figure, because the underlying quantity has different behaviour, and a ratio built from incomparable inputs is worse than no ratio because it looks authoritative.
For a curve-stage token, record that turnover does not apply and use average trade size and curve progress instead. Both survive the structural difference, and both are computable from figures already displayed.
The full structural comparison between the two venue types is set out in curve volume versus pool volume, which is worth reading before applying any ratio to a launch-stage token.
Worked example: one volume, three depths
Illustrative pairs invented by the desk
Three tokens with an identical reported figure of 120,000 over twenty-four hours. No real token is described and none of these numbers is observed.
Token F. Liquidity 900,000. Turnover 0.13. Trade count 300, average trade size 400. A modest amount of flow relative to depth, absorbed at low impact. A 500 order here costs about 0.06 percent in movement.
Token G. Liquidity 120,000. Turnover 1.0. Trade count 1,200, average trade size 100. The pool traded roughly its own depth. A 500 order costs about 0.41 percent.
Token H. Liquidity 25,000. Turnover 4.8. Trade count 6,000, average trade size 20. The same shallow reserves were cycled nearly five times at very small sizes. A 500 order costs about 1.96 percent, which is more than most of the trades that produced the volume were worth in the first place.
The volume column ties all three. Turnover separates them into three distinct markets, and the average trade size column adds a second dimension: Token H's flow is composed of trades far smaller than a single ordinary retail order, which is a fact about the composition of the volume rather than about its size.
Notice what happened in the last case. The average trade producing Token H's volume was 20, while a 500 order into the same pool would move the price by about two percent. The activity generating the headline is operating well below the size at which the pool starts to resist, which is the specific structural reason very high turnover at very small trade sizes is achievable at all.
Four ways the ratio breaks
The desk uses turnover constantly and states its limits every time. There are four that matter.
- Timing mismatch. Volume covers a window; liquidity is read now. If depth was added or withdrawn during the window, the denominator does not describe what the flow actually traded against.
- Convention mismatch. If the liquidity field sums both sides and you reason about one-sided execution, you are off by roughly a factor of two. Consistency matters more than which convention you pick.
- Multi-pool dilution. Summing depth across pools while volume also sums across them is internally consistent, but the resulting ratio describes an aggregate that no single trade can access.
- Range-based liquidity. Where liquidity is concentrated into price ranges, total deposited value overstates depth at the current price, which makes turnover look lower than the execution experience justifies.
All four push the ratio around by factors of roughly two to five. None of them touches the distinction between a turnover of 0.13 and a turnover of 4.8, which is the distinction the ratio exists to make.
The fee floor under a high-turnover figure
High turnover at small trade sizes implies a large number of transactions, and every transaction on Solana costs something to submit. The base fee is a fixed lamport amount per signature, charged whether the transaction succeeds or fails, with a priority fee added on top when the transaction competes for inclusion. That gives a second, independent reading of a busy token page.
Illustrative: what a transaction count implies about spend
Arithmetic chosen by the desk. Assume an all-in cost of 0.0002 SOL per swap, which allows for the base signature fee plus a modest priority fee, and value SOL at 150 for the conversion. Both assumptions are the desk's own and neither is a market observation.
300 transactions in a day. 0.06 SOL, about 9. A rounding error.
6,000 transactions in a day. 1.2 SOL, about 180. A real but modest daily cost.
6,000 transactions a day for thirty days. 36 SOL, about 5,400. Nobody spends that without deciding to.
The calculation is a floor rather than an estimate, because it ignores failed attempts, which also pay, and it ignores the swap fee taken by the pool, which scales with volume rather than with count. Its value is that it converts an abstract event count into a budget, and budgets have reasons behind them.
This is where reading the production side clarifies things quickly. A Pump.fun volume bot platform exposes exactly the variables this section has been reconstructing from outside: how many wallets participate, how often each transacts, and what size each swap is. The fee arithmetic above is the same arithmetic such a console has to do internally, which is why the two views agree so closely. What neither view supplies is any evidence that the resulting flow reflects demand, because turnover and fees describe production cost, not interest.
Putting turnover to work
The practical routine is short. Take volume and liquidity for the same token, confirm they cover compatible periods, divide, and write the multiple down next to the average trade size. Two numbers, both derived, and together they place the token in a two-dimensional space that a single headline cannot.
When comparing two tokens, compare the pairs rather than the headlines. A token at turnover 0.3 with average trade size 400 and a token at turnover 12 with average trade size 20 are describing different phenomena, and no amount of staring at their volume figures will surface that. When one of the two is a curve token, record the missing denominator and compare on average trade size and progress instead.
The last discipline is the hardest and the most important: state the limit when you quote the ratio. Turnover is approximate, it assumes stable depth, and it is sensitive to the liquidity convention. Saying so costs one sentence and prevents the ratio from being treated as a measurement it is not. The full comparison procedure that this ratio feeds into is set out in comparing two tokens honestly, and the definitions used throughout are collected in the glossary.
Questions this page gets asked
What is turnover for a token?
Volume in a window divided by the liquidity available when you take the reading. A turnover of one means the pools traded roughly their own depth during the window. A turnover of thirty means the same reserves were cycled about thirty times.
Is high turnover bad?
It is not a verdict. High turnover means the depth was worked hard, which happens in genuinely active markets and also in continuously automated ones. What it rules out is the reading that a large volume figure implies a large market, because the market in that case is small and busy.
What is a normal turnover figure?
There is no universal normal, because turnover scales with how a venue is used. What is useful is the comparison: two tokens with the same volume and turnover figures of 0.2 and 20 are not similar markets, and the ratio is what makes that visible.
Why is liquidity usually reported as both sides added together?
Because a two-sided pool holds a quote asset and the token, and adding both gives one figure for the value sitting in the pool. If you want to reason about what your own order costs, the relevant number is the side you are draining, which is roughly half of the reported total in a balanced pool.
Can turnover be computed for a bonding curve token?
Not in a way that is comparable to a pool figure. A curve has no withdrawable two-sided reserve, so there is no denominator with the same meaning. The honest treatment is to record that the ratio does not apply rather than substituting curve reserves and pretending the result is comparable.
Does liquidity change during the window I am measuring?
It can, and that is one of the main limits of the ratio. Liquidity providers deposit and withdraw independently of trading, so a pool that held substantial depth for most of the window may show very little now, which distorts the ratio without any change in the volume figure.
What does turnover tell me about my own trade?
Indirectly, quite a lot. High turnover implies shallow depth relative to flow, and shallow depth is what determines the price impact of your own order. If turnover is high, expect your trade to move the price more than the headline volume would suggest.
Written by The Volume in Context Desk. Paired figures on this page are invented by the desk to make one mechanism visible and describe no real token. The terms used are defined in the glossary, and the scope of the desk is set out in about this desk.