How a pool holds a price, and what it costs to move it
A constant-product pool has no order book, no opinion and no memory. It has two balances and one rule that says their product may not fall when someone trades. Everything a trader experiences as price, slippage and cost falls out of that rule. This entry works through the mechanics from the reserves outward, with an illustrative trade to make the arithmetic concrete.
- Question
- How does a pool holding two token balances arrive at a price, and what determines how far that price moves when someone trades against it?
- Balances used
- Both reserve amounts, the pool fee parameter, the trade size, and where applicable the price interval a concentrated position covers.
- Out of reach
- Whether the quoted price is fair, what any asset is worth, and whether a trade should be made at all.
- What would overturn it
- A swap that changes the quoted price of a constant-product pool without changing either reserve balance, which the program does not allow.
- Confidence
- Firm. Everything in this entry follows from published automated market maker design and can be checked against the program.
The short answer
A constant-product pool holds two token balances and enforces one rule: after a swap, the product of the two balances must not be lower than it was before, once the fee is accounted for. The quoted price is simply the ratio of the balances. Trading changes the balances, which changes the ratio, which is what everyone calls the price moving.
Nothing else is involved. There is no matching engine, no queue of orders, no participant deciding what is reasonable. The pool will trade with anyone at whatever price the curve implies for the size they bring, and it will keep doing so until its balances are exhausted or somebody withdraws them.
Two consequences follow immediately and matter more than the rest of this entry. The price is a function of size, so there is no single price for a pool. And the cost of moving the price a given distance depends only on how much capital is sitting in the relevant part of the curve, which is what depth measures.
The invariant in one line
Write the two reserves as x and y. The invariant is that x multiplied by y stays at or above a constant, usually written k. A trader who deposits an amount of token X takes out just enough of token Y to keep the product where it was, minus the fee, which stays behind.
The constant is not fixed forever. It rises when providers add liquidity, falls when they withdraw, and drifts slowly upward as fees accumulate inside the reserves. Between liquidity events it is stable, which is exactly why comparing the product at two instants is such a useful test: a change in the product that is not explained by fees implies a liquidity event happened.
Venues state this rule directly rather than leaving it to be inferred, and Raydium's protocol documentation describes its standard pools in exactly these terms. It is a design choice rather than a law of markets, and it has a specific virtue. Because the curve approaches but never reaches either axis, no finite trade can empty the pool. The price becomes arbitrarily bad instead, which converts the risk of total depletion into the certainty of terrible execution.
Where the quoted price comes from
The quoted price, sometimes called the mid or the spot price, is the ratio y divided by x, adjusted for the decimal precision of each token. It is the price at which an infinitesimally small trade would execute. Nobody trades an infinitesimal amount, so the quoted price is a reference point rather than a transactable number.
Because it is only a ratio, the quoted price is indifferent to the size of the pool. A pool holding a thousand units of each token and a pool holding a million units of each quote precisely the same price. They are wildly different markets, and the price does not distinguish them at all. This is the single most important thing to understand about reading a pool from its quote.
Decimals are a practical trap here. Each Solana token mint declares its own decimal precision as part of the SPL Token program account it is created with, and a raw ratio of on-chain amounts is meaningless until both sides are normalised. A price that looks absurd by several orders of magnitude is almost always a decimals mistake rather than a market anomaly, and checking that first saves a great deal of wasted analysis.
Why size is the whole story
Since the pool quotes along a curve, the price a trader receives is the average price across the section of curve their trade traverses. Small trades traverse almost none of it and fill near the quote. Large trades traverse a lot of it and fill materially worse.
The relationship is not linear. Doubling the trade size more than doubles the price impact, because the reserve being drawn down is falling while the reserve being added to is rising, and both movements work against the trader. This convexity is what makes large trades on thin pools so punishing and why splitting a large order across venues is standard practice rather than a refinement.
It also means the phrase "the market moved against me" is often a description of one's own trade. On a thin pool a trader is frequently the entire reason the price is where it ends up, and blaming the market for a self-inflicted move is a misreading that better reserve arithmetic prevents.
The two sources of slippage
Price impact and drift are different problems with different fixes, and conflating them leads to the wrong remedy. Price impact is deterministic: given the reserves and your size, the fill is calculable exactly before you send anything. It cannot be avoided by acting faster, only by trading smaller, splitting across venues, or accepting the cost knowingly.
Drift is what other traders do between the moment you compute a quote and the moment your transaction is included. On Solana the interval is short but not zero, and a busy pair can see several swaps land inside it. Drift is the part a slippage tolerance protects against, and setting that tolerance wide enough to cover ordinary drift while narrow enough to reject an unrecognisable market is the actual skill.
Separating the two makes post-trade analysis honest. If the fill matched the calculable impact, execution went exactly as the arithmetic said it would and there is nothing to investigate. If it was materially worse, the difference is drift, and the question becomes who traded ahead of you and why the interval was long enough to matter.
A worked trade, illustrative
The same trade against two pools
Illustrative figuresEvery number here is invented to make the curve visible, and describes no real pool or pair. Pool One holds 1,000 units of token A and 100,000 units of token B, so the quoted price of A is 100 B and the product is 100,000,000. Pool Two holds 10,000 A and 1,000,000 B, quoting the identical price of 100 B, with a product one hundred times larger.
A trader sells 100 units of A into Pool One, ignoring fees for a moment. The A reserve becomes 1,100. To hold the product, the B reserve must fall to about 90,909, so the trader receives roughly 9,091 B. Their average fill is about 90.9 B per unit of A, nine per cent below the quoted price, and the pool now quotes about 82.6 B.
The same 100 units of A sold into Pool Two takes the A reserve to 10,100. The B reserve must fall to about 990,099, so the trader receives roughly 9,901 B, an average fill of about 99.0 B, one per cent below the quote. The pool now quotes about 98.0 B.
Identical trade, identical starting price, and a difference of roughly nine per cent in proceeds. The only thing that differed was depth. This is why a reading that stops at the quoted price is not a reading of the market, and why depth at a stated distance is the number worth recording.
Add a fee of thirty basis points and every figure shifts slightly in the pool's favour, but the shape of the result is unchanged. The fee is a small constant charge; price impact is the variable that scales with size, and it dominates the outcome for anything other than dust trades.
What happens to the fee
A swap fee is a fraction of the input amount that does not participate in the invariant calculation. Depending on the venue it either stays in the pool reserves, raising the product and therefore every provider's claim, or it is accrued separately and claimed by providers as a distinct action.
The distinction matters for reading balances. Where fees stay in the reserves, a busy pool shows a rising product with an unchanged ratio, and that rise is fee residue rather than deposits. Where fees accrue separately, the reserves stay flat and the fee balance grows alongside, so a reader looking only at reserves will see a busy pool that appears to earn nothing.
Neither arrangement tells you what a provider earned. That depends on how much flow passed through their position, over what period, at what share of total liquidity, and against what change in the price ratio. This desk quotes no yields for exactly that reason: the fee rate is a protocol parameter and can be stated, while the return is a fact about somebody's specific position that reserve data does not contain.
What concentrated ranges change
On a concentrated liquidity venue a provider supplies capital to a price interval rather than to the whole curve, a design documented in detail by Orca's developer documentation. Inside that interval the position behaves like a much larger classic pool, which is the entire point: the same capital supports far more depth where it is actually used.
Outside the interval the position stops quoting. It has been fully converted into whichever of the two assets is on the far side of the range, and it earns nothing until the price returns. A pool made up of many such positions therefore has depth that varies sharply with price, and a ladder that looks solid at mid can fall away within a couple of per cent.
The reading consequence is that on these venues a single depth number is not enough. What matters is the distribution of liquidity across intervals, and whether the current price sits in a crowded region or a sparse one. Two pools with identical value locked can be an order of magnitude apart in what they will actually absorb.
The failure this prevents
A pair that trades comfortably all day and then gaps badly on one ordinary-sized order has usually not lost liquidity. The price has walked out of the region where the liquidity was placed. The reserves did not vanish; they were never in that part of the curve to begin with.
Quote, fill and mid compared
| Number | What it is | Correct use | Misuse |
|---|---|---|---|
| Mid or quote | Reserve ratio, the price for a zero-size trade | Comparing venues, computing impact from a baseline | Treating it as the price you will receive |
| Expected fill | Average price across the curve for your size, before fees | Sizing a trade, estimating cost of exit | Assuming it holds when others trade first |
| Realised fill | What the transaction actually returned once it landed | Measuring execution after the fact | Blaming the pool for drift caused by queue position |
| Last trade | The price of whatever swap most recently landed | Nothing in particular on its own | Reading it as current depth or current value |
Checks before trusting a quote
- Normalise both reserves for token decimals before computing any ratio, and sanity-check the result against a second venue.
- Compute expected fill for the size you actually intend, not for one unit, and compare it against the quote.
- Check whether the venue uses concentrated ranges, because a single depth figure means something different if it does.
- Identify how many pools quote the pair, since depth on one venue is not depth for the pair.
- Look at whether the reserve product has been drifting, which separates fee accumulation from liquidity events.
- Assume the price will move between quoting and landing, and decide in advance what deviation is acceptable.
None of these takes long, and together they remove most of the ways a pool reading goes wrong. They are also the checks most often skipped, because a quoted price looks like an answer and a ladder looks like work. Traders studying execution from the activity side reach the same checklist from the opposite direction, which is why an operator running a SOL volume bot ends up caring about the same reserve fields that a liquidity provider does.
What the invariant does not promise
The invariant guarantees that the pool remains solvent and that its price responds smoothly to trading. It does not guarantee that the price is right, that anyone will want to trade at it, or that a provider will end the day better off than they started.
It also says nothing about the tokens themselves. A pool will quote a price for anything paired against anything, and the curve treats a well-established asset and a token created an hour ago identically. A deep pool around a worthless asset is still a deep pool, and the arithmetic here is silent about which is which.
Finally, an LP position built on this machinery carries a specific structural exposure: the pool sells whichever asset is rising and buys whichever is falling, so the position can be worth less than the two assets would have been if simply held. That comparison has its own entry, because it is the part of pool mechanics most often described in reassuring language and least often described plainly.
Questions this entry gets asked
Does a pool have a spread like an order book?
Not in the same sense. A constant-product pool quotes a single continuous curve, so there is no gap between a best bid and a best ask; the effective spread you experience comes from the fee plus the price impact of your own size. Two trades in opposite directions at the same instant therefore fill at slightly different prices, which is the closest analogue to a spread.
What actually is slippage?
Slippage is the difference between the price you expected and the price you got. It has two separate sources that are often confused: price impact, which is the movement your own trade causes along the pool curve and is fully predictable from the reserves, and drift, which is other people trading between the moment you quoted and the moment your transaction lands.
Why does a bigger trade get a worse price on the same pool?
Because the pool must keep the product of its reserves at or above where it started. Taking more of one token forces the other reserve up faster than linearly, so each additional unit is more expensive than the last. The effect is a property of the curve, not a penalty applied by anyone, and it is the mechanism that stops a pool being drained by a single trade.
Do fees make the pool deeper over time?
In pools that retain the fee inside the reserves, yes, slightly. Each swap leaves a small amount behind, so the reserve product creeps upward even when the ratio returns to where it started. That is why a pool can show a slowly rising product across a busy window with no liquidity provision recorded at all, and reading that drift as a deposit is a common mistake.
Is the quoted price the price I will trade at?
No, and treating it as one is the most expensive small error in this subject. The quoted or mid price is the price for an infinitesimal trade. Your fill is the average price along the curve for the size you actually send, plus the fee, and for a large trade against a thin pool the two numbers can differ substantially.
How do concentrated ranges change this?
They change the depth, not the principle. A concentrated position behaves like a much larger constant-product pool while the price sits inside its range, and behaves like nothing at all once the price leaves it. That makes depth position-dependent, so the same pool can be deep at mid and abruptly thin a short distance away.
Filed in Pools by The Depth Ledger Desk. Every quantity inside a worked example on this page is invented for teaching and describes no real pool. Nothing here is advice about what to buy, sell or supply, and liquidity provision can end with a position worth less than holding the two assets. Terms used above are defined in the liquidity glossary.