How bonding curve pricing works

A bonding curve prices a token with a formula instead of a counterparty: a program holds one reserve, and the quote at any instant is a fixed function of how many tokens the program has already issued. Buying issues more tokens and moves the quote up. Selling returns them and moves it back down. There is no order book, no market maker, and nobody on the other side deciding whether you are right.

Almost every confusing thing about curve markets follows from that one sentence: why the first buys look violent, why the price on screen is not the price you get, why slippage is predictable rather than hostile, and why nobody can deepen the market by depositing capital. The mechanism below is worth taking in order.

The curve as a pricing function

Call the number of tokens the program has released so far the issuance. The curve is a function that maps issuance to a price. Feed it the current issuance and it returns the current quote. That is the entire pricing system. There is no reference to an external market, no oracle, no weighted average of recent trades, and no discretionary adjustment.

The function is chosen at deployment and does not change afterwards. It is normally monotonic, so more issuance always means a higher quote, and it is normally linear or convex, so the quote rises faster in absolute terms as issuance grows. Those two properties are what make the early portion of a curve cheap in absolute terms and the later portion expensive.

Because the function is deterministic and its inputs are on-chain account state, anyone can compute the next quote before submitting a transaction. That is unusual. On most venues you are estimating what a market will do; here you are evaluating a function whose arguments you can read. The companion note on what curve volume actually counts leans on the same property to sanity-check activity figures.

Reserve mechanics and what the reserve is

The reserve is the pot of quote asset the program holds, usually SOL. It grows by exactly what buyers pay into it and shrinks by exactly what sellers take out of it, less whatever the fee schedule diverts elsewhere. It is not a treasury, it is not spendable by the team in a well-behaved deployment, and it is not a claim on anything outside the program.

What the reserve represents is the accumulated cost of every token issued so far. Integrate the curve from zero issuance up to the current issuance and you get the reserve balance. That identity is worth internalising, because it means the reserve is a historical record of purchases rather than a valuation. It states what was paid, not what anything is worth now.

It is also the only exit liquidity that exists. When you sell into a curve, the SOL you receive comes out of that reserve and from nowhere else. The size of the reserve therefore caps what the market can pay holders in aggregate, whatever the quote implies about the value of the supply. A quote is a marginal number; the reserve is the whole balance sheet.

Launchpads in this family typically mint a fixed total supply at deployment and hand it to the curve program, holding a portion back so that liquidity can be seeded on an external venue once the curve completes. Treat that as a common design pattern rather than a precise claim about any particular program, and read the deployed parameters before you rely on it.

Why every buy moves the price

Every filled buy changes the issuance, and the quote is a function of issuance, so the quote changes. There is no state in which a trade executes and the price stays still. This is the structural break from an order book, where resting size can absorb an order at one price, and it is why curve charts have no flat sections during active periods.

The magnitude of the move depends on where you are along the curve. Early on, when issuance is small, a modest purchase is a large proportional change in issuance and therefore a large proportional change in the quote. Later, the same purchase is a small fraction of a much bigger issuance and moves the quote far less. Depth is not constant along a curve.

Selling runs the same function backwards. Tokens return to the program, issuance falls, and the quote drops to exactly the value it held when issuance was last at that level. Curves are path-independent in this narrow sense: two different sequences of trades that end at the same issuance produce the same quote.

Marginal quote versus average fill

This is the part most readers get wrong, and it is worth slowing down for. The quote is the price of an infinitely small trade at the current issuance. It is a marginal price. Your order is not infinitely small, so it does not execute at the quote. It executes across a range of prices, and what you pay is the average over that range.

Concretely, a buy starts at the pre-trade quote and finishes at the post-trade quote, and every token along the way costs slightly more than the one before it. The average fill therefore sits between the two quotes: above the price you saw before you confirmed, and below the price displayed afterwards. On a linear curve it lands exactly at the midpoint of the two.

Two errors follow from missing this. The first is treating the pre-trade quote as your entry and then concluding you were cheated when the fill comes back worse. The second is treating the post-trade quote as your entry, which flatters the position, because you appear to be in profit against a price nobody actually paid. Neither number is your cost basis. The average fill is.

The same asymmetry runs in reverse when you sell. The first token leaves at the current quote and each subsequent one leaves a little lower, so your average sale price is below the quote you were looking at. On a curve that is not a fee and not a malfunction. It is what integrating a rising function across your order size does.

Walking successive buys along the quote

The table below walks five successive one-million-token buys along the illustrative curve defined in the formula box above. The curve starts with two million tokens already issued and a reserve of 2 SOL. Every figure comes from the two formulas, so the arithmetic can be checked line by line rather than taken on trust.

Read the last two columns together. On the first buy, the average fill of 0.0000025 is twenty-five per cent above the pre-trade quote of 0.000002. By the fifth buy, an identical one-million-token order pays an average fill only about eight per cent above its own pre-trade quote. The order size never changed. The curve simply got deeper underneath it.

Two further properties fall out of the table. Total SOL paid across the five buys is 22.5, taking the reserve from 2 to 24.5, which is exactly what the reserve formula returns for seven million issued. And at that point the issued tokens carry a notional value of 49 SOL at the marginal quote, while the reserve holds 24.5 SOL.

That ratio of one half is a property of this illustrative linear curve rather than a universal constant, but the shape of the observation generalises. Marginal quote multiplied by supply is always larger than the reserve that produced it on any rising curve. A valuation derived that way describes the price of the next token, not the money available to pay existing holders.

Why curve slippage is deterministic

Slippage on a curve has two distinct components, and conflating them causes most of the confusion around it. The first is curve impact: the gap between the pre-trade quote and your average fill, which is a pure consequence of your own order size. That is not slippage in the adversarial sense at all. It is the computable cost of moving along a function.

The second component is state drift. The curve may have moved between the moment your wallet built the transaction and the moment a validator executed it, because other transactions landed first. This one is a race, and it is the reason a slippage tolerance setting exists. Tolerance does nothing about curve impact; it only decides when to abort because the state changed underneath you.

Setting tolerance wide enough to fill reliably and narrow enough to avoid a bad fill is the whole trade-off. A one per cent tolerance on a fresh curve will fail constantly, because the state genuinely does move that much between blocks. A fifty per cent tolerance will fill, and it will also fill at prices you would have declined if anyone had asked you first.

The same trade-off is what an automated Solana volume bot is resolving on every transaction it sends, since it is submitting into the same shifting state without a person to judge each fill. Reading the tolerance and sizing settings such a console exposes is a practical way to see how much of the two-component split the design actually accounts for.

Fees sit on top of both components and are charged separately from the pricing function. Curve impact, protocol fee, network fee and priority fee are four different costs with four different behaviours, and small orders are where they diverge most sharply, because three of the four barely scale with size. The note on what one swap actually costs separates them properly.

Curve pricing against constant-product pools

Constant-product pools, the x * y = k design behind most automated market makers, also price trades with a formula and also move on every fill. The similarity ends about there, and the differences change what you are entitled to conclude from two token pages that display identical-looking numbers. The table sets the two designs against each other row by row.

The row that matters most in practice is the third one. On a pool, a token can look thin today and deep tomorrow because somebody added capital, with no trades in between. On a curve, depth is a strict function of net purchase history. Nobody can rescue a thin curve with a deposit, and nobody can drain it except by selling into it.

The two designs therefore fail differently. A pool can be abandoned by its providers; a curve cannot be, because its reserve is locked in the program, but neither can it be reinforced. What happens to depth at the handover between them is covered in the note on what changes after the curve.

Frontrunning and sandwich exposure

A sandwich needs three things: a pending trade the attacker can observe, a price function the attacker can compute, and influence over transaction ordering. Curves satisfy the second condition perfectly, because the pricing function is public and exact. An attacker can calculate to the token what a front-run of any given size extracts from your order.

The mechanism itself is plain. A buy placed immediately before yours raises the issuance, so your order starts further up the curve and your average fill is worse. A sell placed immediately after yours captures that difference. Nothing about the curve is broken by this. The attacker is choosing a position in the ordering and paying two lots of curve impact to extract from yours.

What limits the attack is that curve impact applies to the attacker as well. The round trip costs two lots of impact plus two lots of fees, so it only pays when your order is large enough that the extraction exceeds their own cost. Small orders on a deep section of curve are rarely worth the effort. Large orders on a fresh curve are the opposite.

The defences are unglamorous. Split large orders, keep slippage tolerance no wider than a fill you would genuinely accept, and treat a wide tolerance as an explicit statement of how much extraction you are willing to fund. There is no configuration that makes a curve unpredictable to an observer, because predictability is the entire point of the design.

Parameters to look up rather than assume

Everything above is structural and holds for any rising curve. The specific numbers do not, and a great deal of published commentary quotes parameter values as though they were permanent. Launchpads revise fee schedules, thresholds and migration destinations. The checklist below is what to read out of the deployed program before relying on any figure.

Two of those deserve emphasis. Virtual reserve offsets are common in production implementations and make the curve behave as though it already held some quote asset at zero issuance, which changes the early section substantially against a naive integral. And fee placement changes your effective average fill without changing the displayed quote by a single digit.

Structure is stable and parameters are not, so take the mechanism from an explanation and take the values from the program itself. If a figure in any article, including this one, contradicts the deployed contract, the contract is the thing that will be executing your trade, and the contract is therefore the one that is right.

Questions readers ask

Verify parameters at source before acting on any of this: the Pump.fun protocol for current curve and fee values, the Solana documentation for account, transaction and token semantics, and the published program source on GitHub where a launchpad makes it available. Structure is stable across implementations; the coefficients are not.