Reading a Solana Liquidity Pool

A Solana liquidity pool's depth is set by its reserve balances, not by the headline liquidity figure printed above them. Read the two vault balances, convert them with the correct mint decimals, multiply them to get the constant product, and you can compute exactly how much value has to trade before the quoted price moves one, two or five percent.

That computation is the whole point of opening a pool page. Volume totals cannot answer the question a trader actually has, which is what a specific order will cost. Price charts cannot answer it either. The pool is the only object in the system that holds the answer, and the arithmetic that extracts it is short enough to do by hand.

What a pool account actually stores

A constant-product pool on Solana is not a single account. It is a small cluster of accounts owned by an automated market maker program. One account holds the pool state. Two token accounts hold the reserves. A separate mint account issues the liquidity provider tokens. Authority over the reserve accounts belongs to a program-derived address, so no human key signs a withdrawal from them.

The reserves themselves live in ordinary SPL token accounts, the same account type that holds a balance in any wallet. Each token account records a mint, an owner and a raw integer amount. The amount is stored without a decimal point; the mint declares how many decimal places to apply. Wrapped SOL uses nine, which is why one SOL equals one billion lamports, and USDC on Solana uses six.

The state account holds addresses and parameters rather than prices. It records which mints the pool trades, where the two vaults are, which mint issues LP tokens, and the fee configuration the program applies to each swap. It does not store a price anywhere. Price is a derived quantity, recomputed from the vault balances every time the program is asked for a quote.

This matters when you read an explorer or a token page. Every number those surfaces display above the reserves is a derivation, and each derivation carries its own assumptions about how to price the non-quote side. The two vault balances are the primary data. If a displayed figure disagrees with what the balances imply, trust the balances and work out what the display was doing.

Reserves and what the ratio means

Once both balances are converted out of raw integers, the pool answers two different questions with two different pieces of arithmetic. The ratio of the reserves gives the price. The product of the reserves gives the depth. Readers conflate these constantly, and almost every misreading of a pool page traces back to using one where the other was needed.

The spot price is the quote reserve divided by the base reserve. It is the price the program would apply to a trade so small that it does not move the balances, which means no real trade ever executes at it. Every actual fill executes at an average price worse than spot, because the invariant x × y = k forces the ratio to move as the trade consumes one side of the pool.

The product is where depth lives. Two pools holding an identical ratio can differ by several orders of magnitude in absolute size, and they will quote the same price while filling the same order at completely different costs. A pool page that shows only price tells you nothing about execution. This is also the structural difference between a launch curve and a deployed pool, which is treated separately in the note on curve liquidity versus pool liquidity.

One caution on the word constant. The product is held constant within a single swap, before fees are applied. Fees retained inside the pool raise it slightly with every trade, and deposits or withdrawals move it in either direction without any trading at all. Treat k as a snapshot quantity that expires the moment you look away, not as a fixed characteristic of the pool.

LP token supply and what a share represents

When someone deposits both assets into a constant-product pool, the program mints LP tokens to them and records the new supply on the LP mint account. Those tokens are a claim on a fraction of whatever the reserves contain at the moment they are burned. The fraction is simply the holder's LP balance divided by the total LP supply, and it does not change when the pool trades.

Take a pool holding 1,200 SOL and 48,000,000 units of a token. The constant product is 57,600,000,000. The spot price is 1,200 divided by 48,000,000, or 0.000025 SOL per token. Suppose the LP mint reports a supply of 240,000 tokens. A holder with 6,000 of them owns 2.5 percent of the pool, which is a claim on 30 SOL and 1,200,000 tokens if the position is closed at this instant.

Note what the share does and does not track. The percentage stays at 2.5 until someone deposits or withdraws. The composition behind it moves continuously, because every swap changes the ratio of the reserves. A depositor who arrived when the pool was balanced will be returned more of whichever asset the market has been selling into the pool, which is the mechanism behind divergence loss.

The supply figure is also a useful integrity check. LP supply should change only on deposits and withdrawals, never on trades. If it is moving while the reserves stay flat, or if a mint authority is still set on the LP mint, then the number of claims on those reserves is not fixed and any share you compute is provisional.

Depth at one, two and five percent

Depth is quoted as a percentage move, and the phrase is used loosely enough that you should always establish which definition is in play. Some surfaces mean the notional required to move the pool's spot price by that percentage. Others mean the size at which average execution price degrades by that percentage. Others mean resting size within a band, which is an order-book concept that does not translate cleanly to an AMM.

The first definition is the one that follows directly from the invariant, so it is the one to compute yourself. Adding an amount dx of the quote asset to a reserve x raises the spot price by a factor of (1 + dx / x) squared. Rearranged, the quote amount required for a target move m is dx = x × (sqrt(1 + m) − 1). The token reserve never enters the formula.

Applied to the pool above, with 1,200 SOL on the quote side, the depth profile looks like this. Buy-side depth is the SOL that must be added to raise the price by the target. Sell-side depth is the SOL that leaves the pool as the price falls by the same target. Values are rounded to two decimals.

Three readings come out of that table. First, depth is roughly half the target move applied to the quote reserve: a one percent move costs about 0.5 percent of the SOL side, a five percent move about 2.5 percent. That approximation is accurate for small moves and drifts as the target grows, which is worth remembering when you need a number quickly and have only the reserves.

Second, the two sides are not symmetric. Moving the price down five percent releases 30.38 SOL while moving it up five percent absorbs 29.63 SOL, and the gap widens as the target grows. The curve is convex, so equal percentage moves in opposite directions cover unequal amounts of value. Anyone quoting a single depth figure for a pool has silently chosen a side.

Third, everything above ignores fees, and fees make the real numbers slightly worse in both directions. They also mean that a round trip through the pool never returns the trader to their starting balance even when the price returns to its starting point. What this costs at sizes that matter relative to a small reserve is worked through in the note on price impact on thin pairs.

Reading a pool on an explorer, step by step

The procedure below assumes nothing beyond a browser and a pool address. It works on any account explorer that renders SPL token accounts and program-owned accounts, including Solscan and the explorer on solana.com. Nothing here requires an API key, an indexer subscription or privileged access to a data provider.

1. Start from the pair, not the tokenA token can trade in several pools at once, and they do not share reserves. Decide which pair and which specific pool address you are measuring before you open anything, because depth belongs to a pool and never to a token.
2. Open the pool state accountPaste the pool address into the explorer and open the account view. The owner field should be the AMM program rather than the system program, which confirms you are looking at pool state and not at a wallet or a stray token account.
3. Locate the two vault accountsThe state account references two token accounts that hold the reserves. Open both and confirm their mints match the pair you expect. These two balances are the primary data for every calculation that follows.
4. Convert the raw balances using mint decimalsBalances are stored as integers. Divide by ten raised to the mint decimals: nine for wrapped SOL, six for USDC on Solana, and whatever the project mint declares on the other side. Getting this wrong by one place multiplies your depth estimate by ten.
5. Compute the product and the spot priceMultiply the converted reserves to obtain the constant product. Divide the quote reserve by the base reserve to obtain the spot price. Compare that price to whatever the pool page displays; a disagreement means the page is pricing through some other route.
6. Read the LP mint and its supplyOpen the LP mint account and record the circulating supply, the decimals and whether a mint authority is still present. Then look at who holds the supply, because a single dominant holder is a different risk profile from a dispersed one.
7. Compute depth at the size you care aboutApply the depth formula to the quote reserve for one, two and five percent, then place your intended order size on that scale. If your order is larger than the five percent figure, you are the event rather than a participant in it.
8. Cross-check against the trade historyScan recent transactions against the pool. Confirm that reserve changes correspond to swaps rather than deposits and withdrawals, and note whether activity arrives continuously or in tight bursts with long gaps between them.

The whole sequence takes a few minutes once the layout of a given AMM program is familiar. The value is not in any single step but in the habit of deriving the numbers rather than reading them off a card. A derived figure comes with its own assumptions attached, which is exactly what a displayed figure lacks.

Eight red flags on a pool page

None of the items below is proof of anything on its own. Each is a signal that the picture presented by a summary figure is incomplete, and each can be checked from public account data in under a minute. Two or three appearing together on the same pool is worth more attention than any one of them appearing alone.

• Reserves that do not support the headline figureIf the displayed liquidity value is far larger than what the two vault balances imply at a sane price, the display is aggregating pools, pricing the non-quote side off a thin market, or both.
• A live mint authority on the LP mintAn unrevoked authority means the supply of claims on the reserves can be increased, which makes every share percentage you compute provisional rather than settled.
• LP supply concentrated in one holderA single address holding most of the LP supply can withdraw most of the reserves in one transaction. Depth that one party can remove at will is depth with a condition attached.
• A freeze authority still set on the token mintThis is a property of the token rather than the pool, but it determines whether a holder can be prevented from transferring, which makes the exit side of any position conditional.
• Strongly asymmetric depth between the two sidesWhen the buy side and the sell side diverge far beyond the mild convexity the curve produces, the reserves have already been pushed a long way from where they started.
• Several pools splitting the same pairDepth that is spread across three pools is not the same as depth in one, because a single unrouted order only ever touches one of them. Aggregate figures hide this completely.
• Reserves moving without corresponding swapsIf balances shift while the trade history stays quiet, someone is depositing or withdrawing. Depth measured before such a move describes a pool that no longer exists.
• Trade history that arrives in regular burstsEvenly spaced clusters of similar-sized fills describe a scheduled process rather than a market. This says nothing about legitimacy, but it does say the depth is not being tested by independent flow.

The checks are cheap because Solana account state is public and small. What they buy you is the difference between believing a pool page and having read it. A reader who has done the eight checks can state which parts of the display are load-bearing and which are decoration, and that is usually enough to avoid the worst outcomes.

What a pool page cannot tell you

A pool page is a snapshot of account state. It is complete about what it covers and silent about everything else, and the silences are where readers overreach. The first silence is ownership intent. You can see which addresses hold LP tokens and you can see when they arrived, but nothing on chain reveals whether they intend to stay through the next hour or the next month.

The second silence is off-chain arrangement. A liquidity lock is only as real as the program holding the position, and a balance sitting in a contract you have not read is not evidence of a commitment. Announcements about locked liquidity are claims, not account state. If the lock matters to your decision, the program itself has to be inspected.

The third silence is aggregate depth. A pool page describes one pool, while a router considers all of them and splits an order across whichever combination costs least. Your effective depth as a trader can therefore be better than any single pool page suggests, provided you are routing. It is exactly the pool page figure if you are not. This is also why the pool page is the wrong place to judge automated execution: a Raydium volume bot pointed at one pool inherits that pool's depth curve exactly, while anything routing across several is working against a combined profile no single page displays.

The fourth silence is the future, and it is the one that bites hardest after a token changes venue. Reserves that migrated from a launch mechanism into a deployed pool reset the depth profile entirely, and the first hour on the new venue looks nothing like the last hour on the old one. That transition is covered in detail in the note on liquidity after graduation.

Read within those limits, a pool page is the most reliable object on the whole surface. It is raw state rather than a derived statistic, it updates within a slot, and the arithmetic that turns it into a cost estimate is elementary. Read as a verdict on a token, it will mislead as reliably as any headline figure.

Common questions about pool depth

Which reserve do I use for the depth formula?

The one you are spending. Depth for a buy uses the quote reserve, because that is the side your input is added to. Depth for a sell uses the base reserve in the same way. The other reserve does not appear in the formula at all, which surprises people who expect the product to be involved.

Why does my depth estimate differ from the router's quote?

Because the router is not necessarily using that pool. Aggregators split orders across venues and choose paths by total cost, so the quote you receive reflects a combination of pools. Your single-pool estimate is the right answer to the question of what that pool alone can absorb.

Do fees change the depth numbers much?

At small percentages they are a modest adjustment; at larger ones they compound with price impact. The useful habit is to compute depth without fees first, because that isolates the geometry of the curve, then add the fee as a separate line rather than folding it invisibly into one figure.

Is a bigger constant product always better for a trader?

For execution cost, larger reserves at the same ratio are strictly better, and the product is a reasonable proxy for that. It says nothing about whether the reserves will still be there tomorrow, so it should be read next to LP concentration rather than on its own.

How often do I need to re-read the reserves?

Every time the answer matters. Solana targets roughly 400 millisecond slots, so a pool that is being actively traded can change materially between opening the page and sending a transaction. For a thin pool, a reading from ten minutes ago is history rather than data.

What is the shortest honest way to describe a pool?

Both reserves with their decimals resolved, the constant product, the spot price, the LP supply with the largest holder's share, and depth at one size you actually care about. Six values, all derived from public account state, and no adjectives.