A bonding curve and a constant-product pool both quote a price without an order book, but they derive it differently. The curve reads a fixed schedule indexed to how much of the token has been issued. The pool reads the ratio of two reserve balances that anyone may add to or withdraw from. That single difference drives everything else: depth shape, ownership, failure modes and what a chart means.
The comparison matters because a token frequently passes through both structures within days. It is priced by a launchpad curve first, then by the automated market maker pool it migrates to. Readers who carry pool intuitions onto a curve, or curve intuitions onto a pool, reach confident conclusions that the mechanism does not support. This note sets both structures out plainly and then puts the same buy through each.
What a constant-product pool holds
A constant-product pool holds exactly two things that matter: a balance of the base token and a balance of the quote asset, each sitting in a token account controlled by the program. On Solana those balances live in associated token accounts owned by a program-derived address, which is why a pool's entire pricing state can be read from two account balances and a mint decimal count. Native SOL carries nine decimals; every SPL mint declares its own.
Price is the ratio of the two reserves, and trades are constrained by the invariant x × y = k. A buyer adds quote asset to x, and the program pays out whatever amount of y keeps the product at k after the fee is taken. Nothing external is consulted. The pool does not know what the token trades for elsewhere, and it will keep quoting from its own reserves regardless of any other venue's price.
The consequence people underestimate is that reserves are a free variable. Depositors can double both balances, which leaves the price unchanged and halves the price impact of any given trade size. They can also withdraw, which leaves the price unchanged and doubles the impact. The quoted price is silent about all of it, which is why reading a pool means reading balances rather than charts — the approach set out in the note on reading a Solana liquidity pool.
Fees accrue inside the reserves themselves. A trading fee retained from the input is not paid out to anyone at the time of the trade; it stays in the pool, so k drifts upward and every share of the pool becomes marginally larger. Provider positions are represented by a share token, and holding it is a claim on a proportion of whatever the reserves happen to be at the moment of exit.
How a bonding curve prices
A bonding curve replaces the reserve ratio with a schedule. The program defines price as a deterministic function of how many tokens have been issued so far. Buy, and the issued quantity rises, so the next unit costs more. Sell, and the issued quantity falls, so the next unit is bought back for less. The function is fixed at deployment; nothing that happens afterwards changes its shape.
There is no counterparty pool of the base token in the sense a market maker would recognise. The tokens a buyer receives come from a program-held allocation that is released along the schedule rather than from an inventory someone chose to deposit. What the program accumulates is quote asset, and the amount it holds at any point is not a free variable either: it is the integral of the schedule up to the current position, less whatever has been paid out on sells.
That determinism is the curve's defining property. Two buyers arriving at the same schedule position pay the same price for the same size, whatever the wider market thinks the token is worth, because there is no arbitrage channel into the pricing function itself. A pool's price can be pushed by anyone with capital; a curve's price can only be moved by moving along it, which means actually buying or selling the token.
The trade-off is that the curve cannot be deepened. If a pool is too thin for the size people want to trade, someone can deposit more and the problem improves. If a curve is too steep, the only remedy is to change the schedule, which means deploying a different curve. Depth on a curve is a design decision taken once, before anyone has traded.
Two depth profiles, compared
Both structures make large trades more expensive than small ones, but the cost functions have different shapes and different boundary behaviour. On a constant-product pool the marginal price traces a hyperbola: cost per unit rises without limit as the trade consumes more of one reserve, and the reserve is never fully exhausted because the invariant forbids it. Output approaches an asymptote instead of running out.
A curve's marginal price follows whatever function was written. A linear schedule produces cost that rises in proportion to issuance, so the average price of a purchase sits at the midpoint of the starting and ending prices. Steeper schedules concentrate the cost increase in later purchases. And unlike a pool, a curve has an end: the allocation released along the schedule is finite, so the structure terminates rather than approaching a limit.
Scaling behaves differently too. A pool's depth is proportional to its reserves, so the impact of a fixed trade size falls as the pool grows and rises as it shrinks. A curve's depth at a given position is fixed by the schedule and does not respond to anything except movement along it. Two tokens on identical curves have identical depth at identical positions; two tokens in pools of the same nominal price can differ in depth by orders of magnitude. The practical consequences of thin depth are worked through in the note on price impact on thin pairs.
What a single buy does to each
Illustrative arithmetic
Every quantity below — the reserve balances, the curve's price schedule, the issuance position and the trade size — is invented to demonstrate how the two cost functions diverge from the same starting price. They measure nothing real, correspond to no launchpad or venue, and fees are excluded so the structural difference is visible on its own.
Set both structures to quote 0.001 SOL per token before the trade. The pool holds 1,000 SOL and 1,000,000 tokens, so its ratio gives that price and its invariant constant is one billion. The curve uses a linear schedule under which price rises by 0.000000002 SOL for each additional token issued, and 500,000 tokens have been issued, which also gives 0.001 SOL. A buyer now commits 110 SOL to each.
In the pool, the quote reserve rises to 1,110 SOL. The invariant forces the token reserve down to 900,900.90, so the buyer receives 99,099.10 tokens. The average price paid is 110 divided by 99,099.10, or 0.001110 SOL. The new quoted price is 1,110 divided by 900,900.90, which is 0.0012321 SOL.
On the curve, 110 SOL is exactly the integral of the schedule from 500,000 to 600,000 issued tokens, so the buyer receives 100,000 tokens. The average price paid is 0.001100 SOL, which for a linear schedule is the midpoint of the starting and ending prices. The new quoted price is 0.001200 SOL.
| Outcome of the same 110 SOL buy | Bonding curve | Constant-product pool |
|---|---|---|
| Quoted price before | 0.001000 SOL | 0.001000 SOL |
| Tokens received | 100,000.00 | 99,099.10 |
| Average price paid | 0.001100 SOL | 0.001110 SOL |
| Average price above pre-trade quote | 10.0% | 11.0% |
| Quoted price after | 0.001200 SOL | 0.0012321 SOL |
| Quoted price move | +20.0% | +23.2% |
Two observations survive the fact that the inputs were chosen. The curve's average price sits exactly halfway between its starting and ending quotes, because a linear schedule integrates that way. The pool's average sits below the midpoint of its own start and end, because the constant-product cost function is convex and the price move it produces is larger for the same capital. Reversing the parameters reverses the ranking; the shapes do not change.
Who owns the liquidity
In a pool, the reserves belong to whoever holds the share tokens. Those holders can be the original depositor, a set of independent providers, a locked account, or nobody at all if the share tokens were burned. The distinction is material because it determines whether the depth a reader observes today can be removed tomorrow, and that question is answered by inspecting share-token supply and ownership rather than by looking at the price. A block explorer such as Solscan exposes both the reserve accounts and the share mint.
On a curve there is no such position. Nobody deposited the base token, so nobody holds a claim on it, and the accumulated quote balance is held by the program under rules fixed at deployment. It normally exists to fund sells back down the schedule and, at the end of the schedule, to seed the pool the token migrates into. There is no provider to exit, which eliminates the withdrawal risk entirely.
That elimination is often overstated into a safety claim, and it should not be. Removing one failure mode is not the same as removing risk. A curve concentrates exposure in the program's own logic and in whatever authorities it retains: who can upgrade it, who can trigger migration, and what the schedule permits at its boundaries. The relevant question shifts from "can the liquidity be pulled" to "what is this program allowed to do", and both questions are answered by reading accounts, not by reading a chart. Account structures and the token program that underlies both designs are documented in the Solana developer documentation.
Side by side
The following table collects the structural dimensions that most often get conflated. Each row is a property of the mechanism rather than a judgement about it.
| Dimension | Bonding curve | Constant-product pool |
|---|---|---|
| Price source | A fixed schedule indexed to tokens issued | The ratio of two reserve balances |
| Reserve ownership | Held by the program under deployment rules; no provider positions exist | Held on behalf of share-token holders, who may be many, one, or nobody |
| Depth shape | Determined by the schedule; cannot be deepened by contributing capital | Proportional to reserves; deepens when anyone deposits, thins when anyone withdraws |
| Effect of a buy | Advances the issuance position, so the next unit costs more along the schedule | Raises the quote reserve and lowers the token reserve, moving the ratio |
| Effect of a sell | Retreats along the same schedule and is repaid from the accumulated quote balance | Adds tokens and removes quote asset, moving the ratio the other way |
| Who can withdraw | Nobody outside the program logic; there is no position to close | Any share-token holder, unless the shares are locked or burned |
| Fee accrual | Defined by the program; does not alter the schedule itself | Retained inside the reserves, so every share grows slightly with turnover |
| Boundary behaviour | Finite: the schedule terminates when its allocation is exhausted | Asymptotic: reserves are never fully drained by trading |
| Primary failure mode | Program authority and migration mechanics; a schedule too steep to trade against | Reserve withdrawal and thin depth; large orders filling far from the quote |
| What a chart shows | A direct restatement of cumulative net buying, since price is a function of issuance | The net result of two-sided flow plus arbitrage against every other venue |
When a token has both at once
During and after migration a token can be quoted by two independent surfaces simultaneously. Nothing in either mechanism forces them to agree. The curve quotes from its schedule position, the pool quotes from its reserve ratio, and the two are connected only by traders willing to buy on the cheaper surface and sell on the dearer one.
Arbitrage closes part of that gap, but not all of it. The trade has to cover trading fees on both legs, the price impact it causes on both legs, and the network cost of landing the transaction, so a spread narrower than the round-trip cost is stable and can persist indefinitely. On a thin token the round trip is expensive, so the tolerated spread is wide.
This has a direct consequence for anyone reading data during the overlap. A price is now venue-specific, and a total that sums both surfaces describes activity across two markets rather than depth in one. Sitting a curve figure and a pool figure next to each other without labelling them produces a comparison that looks like a time series and is not. It also sets the hardest requirement for any execution software used during an overlap: a volume bot for Solana that quotes only one of the two surfaces will keep sizing orders against a depth profile the token has partly left behind.
What changes at migration
Migration is not a rebranding of the same liquidity. It is a change in the kind of object that sets the price. Before it, price is a function of issuance and is therefore fully determined by the token's own trading history. After it, price is a function of a reserve ratio that anyone with capital can influence and that any provider can thin by withdrawing.
Several properties appear at that moment which did not exist before. Provider positions come into existence, and with them the question of whether the initial share tokens are held, locked or burned. Depth becomes a balance rather than a parameter, so it can grow through the day and shrink overnight. Two-sided flow starts to matter, because sells now leave tokens in the reserve where before they retreated along a schedule. And the token becomes routable, so aggregators can split orders into it alongside every other pair on the same venue.
The consistent misreading is to treat the seeded reserves as a floor. They are an opening balance, and from the first block afterwards they are subject to the same forces as any other pool: withdrawal, accumulation, arbitrage and impact. What happens to depth in the period immediately following the transition is the specific subject of the note on liquidity after graduation.
Read structurally, the two designs are not competitors. A curve solves the problem of pricing a token that has no market yet, using determinism to substitute for the absence of counterparties. A pool solves the problem of pricing a token that has one, using reserves to absorb two-sided flow. Judging either by the standard of the other produces a conclusion about the wrong mechanism.
Points readers raise
Is a bonding curve just an AMM with one asset?
It is closer to say it is an AMM whose pricing input is issuance rather than a reserve ratio. The practical difference is that a reserve ratio can be changed by anyone with capital, while an issuance position can only be changed by trading the token itself.
Does a curve give better execution than a pool?
Not inherently. The comparison depends on schedule steepness against reserve size, and either can be far more expensive than the other. What is structural is the shape of the cost function, not its level.
Can I provide liquidity to a bonding curve and earn on it?
No, because there is no provider position to open. The only way to move capital into a curve is to buy along it, which advances the price and leaves you holding the token rather than a claim on reserves.
Why is a curve chart so smooth compared with a pool chart?
Because the curve's price is a direct function of cumulative net buying and nothing else. A pool's price reflects two-sided flow, deposits, withdrawals and arbitrage against every other venue quoting the same token.
Does migration make a token safer?
It changes the risk rather than reducing it. Withdrawal risk did not exist on the curve and does exist in the pool; program authority risk was concentrated on the curve and is diluted afterwards. Which trade is preferable depends on what the reserves and the share tokens actually look like.
Which structure should a depth reading be taken from?
Whichever one the order would actually execute against, and only that one. Adding a curve position to pool reserves produces a number that describes no market a trade can be filled in.
Filed under Liquidity and depth. Corrections and method questions go to the desk; our sourcing rules are on the editorial policy page.