Pump.fun's bonding curve is a constant-product AMM (x·y=k) that runs on virtual reserves rather than a fixed price table. Large orders face slippage that grows faster than the order size itself, and once the real reserves cross a threshold, the token graduates and migrates to PumpSwap with its liquidity pool burned.
TL;DR:
- Price impact on pump.fun's bonding curve increases superlinearly as the trade size approaches the virtual reserve, making large trades more costly.
- The virtual reserves used for pricing differ from real reserves, which only grow with actual trades, requiring careful parsing of either for accurate valuation.
- A token migrates to PumpSwap after its real reserves cross a threshold, with liquidity tokens burned to prevent future manipulation or withdrawal.
- Trading fees of 1.25% split between protocol and creator apply to every trade while on the curve, but are eliminated after token migration.
- Building reliable pricing tools requires monitoring reserve fields directly, verifying event signals like migration, and accounting for reserve discrepancies and fee impacts.
Table of Contents
- How Pump.fun's Curve Quotes Buy and Sell Prices
- Virtual vs Real Reserves: The Fields You Actually Need to Parse
- The Math Behind Buy and Sell Pricing (With a Worked Example)
- Fees on Every Bonding-Curve Trade
- Graduation: When and How a Token Migrates to PumpSwap
- What Gets Locked, What Doesn't, and How to Verify Migration
- A Developer's Checklist for Parsing and Monitoring the Curve
- Where to Go Deeper on the Mechanics
- Ready to Put the Curve Math to Work?
- An Editorial Take on Reading the Curve Correctly
- Sources
How Pump.fun's Curve Quotes Buy and Sell Prices
The mechanism behind pump.fun's bonding curve is the same invariant that powers most constant-product exchanges: x · y = k, where x represents the SOL side of the pool and y represents the token side. Pump.fun applies this formula to virtual reserves rather than assets actually sitting in a wallet, which is what lets a brand-new token start trading with a price above zero the instant it launches.
Spot price at any moment is simply y divided by x, but that number only describes the price of the next infinitesimally small trade. A real purchase of any meaningful size crosses many marginal prices on its way through the curve, which is why the average price you pay is always worse than the spot price you saw a second before clicking buy.
A few mechanics follow directly from this:
- Price impact scales with trade size relative to the pool, not with a fixed percentage.
- Snipers and bots exist specifically because the first buys after launch face the smallest denominator and cheapest average price.
- Severe price impact should be expected whenever Δx (the SOL going in) approaches a meaningful fraction of x (the reserve already in the pool).
Virtual vs Real Reserves: The Fields You Actually Need to Parse
Every bonding curve account tracks two separate reserve pairs, and confusing them is the most common mistake developers make when building pricing tools. The Pump.fun bonding curve exposes four core fields: virtual_lamports_reserve, virtual_token_reserve, real_lamports_reserve, and real_token_reserve.
Virtual reserves are the numbers used in the pricing formula. Real reserves track what has actually been deposited and withdrawn on-chain. The gap between them is intentional: Pump.fun seeds each curve with a virtual offset so the starting price isn't zero or undefined, then lets real reserves accumulate as actual SOL and tokens change hands.
Unit conventions matter here. SOL is denominated in lamports, where 1 SOL equals 1,000,000,000 lamports, and token amounts use their own integer base units tied to each mint's decimals. Getting this wrong throws off every downstream calculation by nine orders of magnitude.
Practical parsing notes for anyone building against these fields:
- Spot price =
virtual_lamports_reserve / virtual_token_reserve, converted from lamports to SOL before display. - Approximate market cap = spot price multiplied by total circulating supply, adjusted for decimals.
- Real reserves grow monotonically until graduation; virtual reserves shift with every trade but never reset mid-curve.
The Math Behind Buy and Sell Pricing (With a Worked Example)
The closed-form expressions behind the pump.fun bonding curve derive directly from the constant-product invariant. For a buy of size Δx (SOL in), the tokens received are:
dy = y · dx / (x − dx)
For a sell of size Δx (tokens in), the SOL received is:
dy = y · dx / (x + dx)
Here x and y map directly to virtual_lamports_reserve and virtual_token_reserve at the moment of the trade. Average price per trade is simply Δy/Δx, and slippage relative to the starting spot price follows the ratio Δx/(x − Δx), which is why slippage rises superlinearly as a trade size approaches the available reserve rather than climbing in a straight line.
A quick numeric walkthrough: suppose virtual reserves sit at 30 SOL (30,000,000,000 lamports) and 1,000,000,000 tokens. A buyer sends 1 SOL. Using the buy formula, dy = (1,000,000,000 × 1,000,000,000) / (30,000,000,000 - 1,000,000,000), which returns roughly 32,258,064 tokens. That works out to an average price near 0.0000310 SOL per token, noticeably above the pre-trade spot price of 0.00003 SOL per token, purely because of the curve's shape.
A few implementation notes worth flagging before you ship this in production code:
- Always confirm
dx < xbefore calculating a sell, or the formula produces a negative or undefined result. - Watch for integer overflow when multiplying large reserve values in 64-bit arithmetic. Pump.fun's own account structures store these as unsigned integers for a reason.
- Round consistently. Rounding direction on the last step can create small but compounding discrepancies against on-chain settlement.
Fees on Every Bonding-Curve Trade
Every trade on a live bonding curve pays a combined 1.25% fee, split into a 0.95% protocol fee and a 0.30% creator fee. That split applies identically to buys and sells while a token remains on the curve, and it disappears entirely once trading moves to PumpSwap after graduation.
In swap event logs, this shows up as a fee_lamports field alongside token_amount and lamports_amount. Converting it to SOL just requires dividing by 1,000,000,000, the same lamports conversion used everywhere else in the schema.
A few things worth checking before you trust a fill estimate:
- Net proceeds on a sell equal the raw
dyfrom the curve formula minusfee_lamports, not the gross amount. - Buys work the other direction: the fee is deducted from the SOL sent before it hits the curve, slightly reducing the tokens received versus a naive calculation.
- For a deeper breakdown of how these fees flow between the protocol and individual token creators, see Pump.fun Fees Explained.
Graduation: When and How a Token Migrates to PumpSwap
A token graduates once its real reserves cross a threshold denominated in SOL, often called R* in technical writeups. Community estimates have historically pointed to roughly 69,000 in market cap terms, equivalent to somewhere near 85 SOL in the pool, but that figure drifts with SOL's own price and should never be hardcoded into production logic. Pull the live threshold from on-chain state instead.
When the threshold is crossed, the program emits a bonding_complete event and migrates liquidity atomically into a PumpSwap pool. Nothing about this step is optional or delayed. The liquidity pool token is then burned, which is the detail that actually matters for trust. Burning the LP means no single wallet, including the deployer, can pull liquidity out later and strand holders.
After migration, price discovery stops following the bonding curve formula entirely. Real reserves now trade on an open market with two-sided liquidity, arbitrage bots active, and normal AMM dynamics replacing the curve's guaranteed-counterparty model. For a full walkthrough of that transition, see How Pump.fun Tokens Migrate to Raydium (and PumpSwap).
What Gets Locked, What Doesn't, and How to Verify Migration
Before graduation, the bonding curve contract controls every real reserve on the token. No creator wallet, and no external party, can withdraw SOL or tokens from that pool directly. Creator fees accumulate separately from reserves and get paid out through the fee split described above, not by draining the curve itself.
The strongest signal that a migration completed safely is the LP burn tied to the bonding_complete event. If you're building verification tooling, watch for that event alongside any subsequent pump_amm entries referencing the same mint. Those two signals together confirm the token left the curve and landed in a pool nobody can unilaterally empty.
A short checklist for anyone auditing a graduation on-chain:
- Confirm the
bonding_completeevent fired for the exact mint address you're tracking. - Verify the LP token supply for the resulting pool dropped to zero, not just that a burn transaction exists.
- Cross-reference
real_lamports_reserveat the moment of the event against the reported threshold to catch anomalies.
A Developer's Checklist for Parsing and Monitoring the Curve
Building anything real on top of this data means reading the BondingCurveAccount structure directly rather than relying on a UI. That fixed-size layout stores reserves, a completion flag, and the creator address in a predictable byte offset, which is exactly how low-latency monitoring tools work in practice.
Before trusting any calculation, run basic sanity checks: confirm dx < x on every sell, confirm virtual reserves are non-zero before dividing, and cross-check computed spot price against a second data source when possible. Once a token graduates, your pricing logic needs to switch data sources entirely and start reading PumpSwap pool state instead of curve fields.
Watching the reserve deltas over time also reveals trading patterns worth flagging: a burst of small, rapid buys from related wallets often signals a bundler, while a single wallet repeatedly buying and selling the same small size can indicate wash trading rather than genuine demand. A setup guide on tracking these patterns lives in Whale Wallet Tracking on Pump.fun.
Pro Tip: If you're polling reserve data instead of subscribing to account updates, tune your RPC provider's rate limits carefully. Latency of even a few hundred milliseconds can mean the difference between catching a snipe pattern early and reading stale reserve numbers. Real-time monitoring at this level is a core focus of platforms that provide trade-mirroring and analytics.
Where to Go Deeper on the Mechanics
Start with the BondingCurveAccount reference and the PumpFunData schema breakdown for exact field layouts. For the full derivation of the buy and sell formulas, Sean Geng's writeup walks through the constant-product math step by step. Internally, Pump.fun Fees Explained and Slippage vs Price Impact cover the two concepts developers ask about most.
Ready to Put the Curve Math to Work?
Understanding the formulas is one thing. Acting on them before a token graduates, while slippage is still cheap and the curve still rewards early positioning, is another problem entirely. Snipethem gives traders access to the trade history of top Pump.fun traders for 24 hours at a time, letting you configure automatic snipe bots that replicate real-time strategies without needing to write your own reserve-parsing logic from scratch. If the math in this article is the theory, the platform is where that theory turns into executed trades.
An Editorial Take on Reading the Curve Correctly
Most explainers still describe Pump.fun's pricing as a step function or a simplified linear ramp, and that framing actively hurts anyone trying to build real tooling. The production mechanism is a constant-product AMM on virtual reserves, and that distinction changes how slippage behaves, how snipers get their edge, and how a pricing bot should be written. If your mental model is wrong, your slippage estimates will be wrong in exactly the trades that matter most, the large ones near graduation.
The conventional advice to "watch market cap for the graduation threshold" is also weaker than it sounds. That number drifts with SOL's price, so hardcoding a dollar or token figure is a bug waiting to happen. Read the reserve fields directly and derive the threshold from chain state every time.
What deserves more attention than it gets is the LP burn at migration. It's a small, easy to miss event field, but it's the actual mechanism that prevents a graduated token from becoming a rug pull. Anyone building verification tooling should treat that burn, not the graduation announcement itself, as the real proof that a migration was final.
— dang