Solana liquidity flow analysis: reading the balances, not the price

The short answer

Liquidity flow analysis on Solana means reading a market from the balances that back it. A pool account holds two token amounts. A program decides how those amounts may change. The quoted price is a function of the amounts, and depth is a function of the amounts plus the range they are spread over. Every honest question about a pair reduces to one of those quantities.

The practical payoff is that reserve data is unambiguous where price data is not. A candle tells you a trade happened at a price and hides how much size that price could absorb. Reserves tell you exactly what the pool would have given for any size you care to name, which is the number that decides whether a position can be exited at all.

The cost is that reserves answer a narrower set of questions than people want answered. They describe capacity, not appetite. They record movement, not motive. Most bad liquidity analysis comes from pushing a reserve reading past that boundary, and the boundary is worth learning before the arithmetic.

The six balances worth recording

A useful reading is built from six quantities. None of them is the price, and none of them is the twenty-four hour volume figure that most dashboards lead with.

Reserve A and reserve B. The two token amounts held by the pool account. On a constant-product pool these two numbers determine the quoted price entirely: the price of A in terms of B is the ratio of the reserves, adjusted for decimals. The decimal precision used in that adjustment belongs to each mint and is declared through the SPL Token program rather than by the pool, so it has to be read separately. Record both raw amounts rather than the ratio, because the ratio hides whether the pool grew or shrank.

LP token supply. The total supply of the token that represents a claim on the pool. This is the field that separates the two kinds of event a pool can experience. A swap changes the reserves and leaves supply alone. Adding or removing liquidity changes supply. Recording supply alongside reserves makes that distinction free.

The fee parameter. A protocol constant rather than an observation, but it belongs in the record because it explains a slow upward drift in the reserve product that would otherwise look like unattributed liquidity provision. Fees taken into the reserves accumulate there and quietly deepen the pool.

Range configuration, where the venue has one. On a concentrated liquidity venue a position is defined by an interval as well as an amount. Two pools holding identical capital behave completely differently if one covers the full price range and the other covers a narrow band around the current price. The interval is part of the balance, not a footnote to it.

The venue set. Which pools quote this pair at all. A single-pool reading of a pair that trades across three venues is not a reading of the pair, it is a reading of one third of it, and the third that happens to be measured is usually the one that indexes most easily.

Instruction timing. When liquidity instructions land relative to swaps, at slot resolution. A pool that receives a large deposit immediately before a burst of trading is telling a different story from one that receives the same deposit an hour afterwards, even though the end state is identical.

The order that stops self-deception

The order these fields are read in matters more than the fields themselves, because reading them in the wrong order lets a conclusion arrive before the evidence. The rule is cheap and structural first, expensive and behavioural last.

Start with LP supply, because it is one comparison and it partitions everything that follows. If supply changed across the window, the window contains liquidity events and any reserve change has to be decomposed before it means anything. If supply is unchanged, every reserve change came from trading and the arithmetic is much simpler.

Then read the reserve ratio against the reserve product. The ratio is the price; the product is a rough proxy for size. A window where the ratio moved and the product barely changed is ordinary directional trading. A window where the product fell sharply is a withdrawal, whatever the ratio did. Reading both at once catches the case where a price move and a withdrawal happen together and each one disguises the other.

Only then look at the venue set and at timing. These are the fields that invite storytelling, so they go last, after the mechanical questions have already been settled and there is less room to bend the evidence around a narrative that has already formed.

A worked reading, illustrative

Nothing in that example required a chart, a data provider or an opinion. It required two balances and a supply figure at two instants, which is the smallest record that makes liquidity analysis possible at all.

Why Solana splits the picture

Solana pairs rarely live in one pool. A token can be quoted on a bonding curve at launch, on an automated market maker after migration, and on several concentrated liquidity venues at once, with an aggregator routing between all of them in the manner set out in the Jupiter developer documentation. Depth is the sum across venues, and no single venue's reserves describe the market.

This has an awkward consequence for measurement. A pair whose depth is split across four pools looks thin on every one of them individually, and the reader who checks the pool with the most familiar interface will systematically underestimate the market. The opposite mistake also happens: adding depth across venues without checking whether a router can actually reach all of them overstates what a trader can use.

Concentrated venues make this sharper again. On a dynamic liquidity venue, providers place capital into discrete bins rather than across the whole curve, a structure described in Meteora's protocol documentation, and the depth available at the current price can change dramatically as the price walks out of a crowded region. A pair can be genuinely deep at mid and genuinely thin two per cent away, and a venue-level total conceals both facts. Venue-specific tooling exists on this side of the market too, and readers comparing execution across dynamic pools sometimes look at how a Meteora volume bot distributes flow through those bins, since routing behaviour and bin occupancy are two views of the same structure.

The practical rule is to define the venue set before recording anything, keep it fixed for the length of a series, and state it in the reading. A depth series whose venue set silently expands halfway through will show a jump in liquidity that never happened.

What each field can settle

A five-step reading routine

1. Fix the boundary before looking Write down the venue set, the window start and end, and the sampling interval. Doing this after seeing the data is how a reading ends up describing the selection rather than the market.
2. Partition by LP supply Compare supply at both ends of the window. Unchanged means every reserve movement is trading. Changed means the reserve movement has to be decomposed before any of it is attributed to trading.
3. Decompose the reserve change Remove the liquidity component at the ratio prevailing when it happened, then read what is left as net flow. State plainly that interleaving makes this an approximation rather than an exact split.
4. Rebuild the ladder at both ends Compute what a trade of a fixed size would have cost at the start and at the end. This converts an abstract reserve change into the number a trader can act on, which is execution cost.
5. Write the reading with its limits attached Record what the balances showed, what remains ambiguous, and the observation that would change the conclusion. A reading without its limits is an opinion wearing a data costume.

The routine is short on purpose. Most of the value in liquidity analysis comes from doing four cheap things consistently rather than one expensive thing occasionally, and a routine that takes twenty minutes gets run while a routine that takes a day does not.

Three questions reserves cannot answer

Being explicit about this is the difference between a method and a horoscope. Three questions come up constantly and reserve data cannot address any of them.

Who is behind a position. A pool records a signer, and a signer is an address. Addresses are not people, one person can hold many, and funding paths are suggestive rather than dispositive. This desk does not publish attribution, and treats any reading that depends on attribution as unfinished rather than complete.

Why liquidity moved. Withdrawal is recorded; the reason is not. A provider closing a position may be rotating to a better venue, harvesting fees, rebalancing a range, responding to something entirely off chain, or leaving the ecosystem. The transaction looks the same in every case, and the honest output is a list of live explanations rather than the most quotable one.

What happens next. Depth describes what a trade would cost, not whether the trade will occur. There is no path from a reserve reading to a price expectation, and every attempt to build one smuggles in an assumption about behaviour that the data does not contain.

What this means if you supply liquidity

Reading balances well does not make providing liquidity safe. An LP position is a position with real downside: as the price moves, the pool rebalances the holding towards whichever asset is falling, and the resulting basket can be worth less than the two assets would have been if held untouched. Fee income offsets some of that gap and is not guaranteed to cover it.

What the reserve side does give a provider is an accurate picture of what they are joining. The depth already present decides how much of the fee flow a new position captures. The range configuration decides whether the position quotes at all after a modest move. The venue set decides whether the pool is where the routing actually goes.

Those are all questions about capacity and structure, and they can be answered before committing anything. They are also the questions most likely to be skipped, because the visible numbers on a dashboard are value locked and a headline yield, neither of which describes the position being entered.

Nothing in this entry is advice about whether to supply liquidity to anything. It is a description of what the machinery does and what the record can and cannot show, and a reader who takes it as a recommendation has taken it as something it was never written to be. Analysts working the activity side of the same market use a Solana volume bot to study how routed flow lands across venues, which is a mirror of the reserve reading described here rather than a substitute for it.

The rest of the ledger follows the same shape. The pools section works through the invariant, the ladder, the transaction and the comparison against holding. The flows section works through where liquidity goes, why reserves fall and how to keep a series that is still readable a month after it was recorded.

Questions this entry gets asked