The graduation threshold explained
Graduation is a program state transition triggered by a balance condition on the curve reserve. It changes the venue, the pricing mechanism and the depth profile of a token in a single transaction, and it certifies nothing about the project behind the mint.
Graduation is the moment a bonding-curve token stops trading against its curve reserve and starts trading in an automated market maker pool. It fires when the reserve held by the curve program reaches a threshold written into that program. Liquidity is moved, the curve is closed to further swaps, and the token becomes an ordinary pool asset. Nothing about the project is audited, reviewed or endorsed by that event.
The word carries an implication the mechanism does not support. Graduation is a state transition triggered by an arithmetic condition on a balance. It is worth understanding precisely, because the assumptions people attach to the word are the assumptions that cost them money in the ten minutes on either side of the transaction that performs it.
What graduation actually is
In program terms a curve launch holds two things that matter here. There is a mint whose supply is fixed at deployment, and there is a reserve account that accumulates SOL as buyers swap into the token. The pricing function reads the reserve and produces a quote. The program also carries a completion condition: once the reserve crosses a defined level, the curve is marked complete and further swaps against it are refused.
What follows is a migration routine. The accumulated reserve, together with a matching allocation of tokens held back for this purpose, is deposited into a liquidity pool on an automated market maker. In the general design the resulting pool position is burned or locked, so that no single party retains the ability to withdraw the deposited liquidity later. That mechanism is what people mean when they say liquidity is locked at graduation.
Notice the direction of causation. Nothing about the token improves. The same mint, the same total supply, the same holder distribution, the same metadata and the same team persist across the boundary untouched. What changes is the venue, the pricing mechanism and the way depth responds to trade. Those are meaningful changes, but they are changes to market structure, not to the quality of the asset.
Graduation is the last of four stages, and it is much easier to read if you have followed the earlier ones. The stage-by-stage account of how a token arrives at this point is set out in the launch timeline in four stages, which covers what breaks during the fill and why most tokens never reach a migration at all.
The threshold and what it measures
The threshold is expressed in reserve terms. Not in market capitalisation, not in holder count, not in elapsed time, not in transaction count. It is a balance in an account. The Pump.fun threshold is widely documented as roughly 85 SOL of curve reserve, and interfaces commonly display progress as a percentage of that figure. Treat the number as documented history: launchpad parameters are program constants, teams have revised them before, and the protocol is the only authority on the current value.
Because the threshold is a reserve level, progress responds to net flow rather than gross volume. A token can process a very large amount of turnover and barely move the bar, if buys and sells roughly offset each other. A smaller number of one-directional buys will move it much further. This is the single most useful thing to understand about the progress percentage, and it is invisible if you only read the volume figure above it.
The destination venue has also changed over time. Migrations were historically routed to Raydium, and the platform later introduced its own automated market maker, PumpSwap, as the migration target. Both of those are documented history rather than a promise about what happens today. Before you plan around a post-migration pool address, check the current routing in the protocol's own documentation instead of assuming.
Progress is not a countdown
A countdown only moves one way. The curve progress bar measures a balance, so it moves in both directions. When holders sell, SOL leaves the reserve and the percentage falls. A bar that oscillates between sixty and seventy for an hour is telling you the market is churning, not that migration is imminent.
What changes in the same block
Migration is not a process that unfolds over minutes at the protocol level. The state changes are performed by a transaction, and a transaction either succeeds in full or fails in full. The confusion arises because the human-visible consequences, such as trackers reattributing the market and aggregators indexing the new pool, take longer to catch up than the state change itself takes to land.
The table below separates the three moments. The left column names the aspect, and the three that follow describe its condition before migration, what the migration transaction does to it, and how it behaves once the token is trading in the pool.
| Aspect | Before migration | At migration | After migration |
|---|---|---|---|
| Pricing mechanism | Deterministic curve formula over one reserve | Curve marked complete, further swaps refused | Pool quote derived from two paired reserves |
| Who supplies liquidity | The program, from accumulated net buying | Reserve and token allocation deposited into a pool | Anyone, subject to the pool rules |
| Depth | Fixed by curve parameters set at deployment | Set once by the deposited amounts | Changes whenever providers add or remove |
| Pool position | Does not exist | Created, then burned or locked by design | Cannot be withdrawn by the launcher |
| Impact of a fixed-size buy | Rises predictably as the reserve grows | Undefined during the handover | Depends on pool size at that instant |
| Where trades route | Launchpad interface and curve-aware clients | Handover of the tradeable venue | Aggregators and any pool-aware client |
| Fee schedule | Launchpad protocol fee on swap notional | Not applicable to the transition itself | Pool swap fee plus any protocol share |
| Volume attribution | Curve market record | Accounting boundary between records | New pool market record |
| Exit path | Sell back into the curve reserve | Momentarily unavailable | Sell into whatever depth the pool holds |
The row that surprises people most is the one about depth. On a curve, depth is a fixed function of parameters chosen at deployment, so the cost of a given sell is knowable in advance. In a pool, depth is whatever providers have chosen to leave in it, which means the same sell can cost very different amounts depending on when you submit it.
How liquidity is handed over
The handover deposits two assets. The SOL side comes from the curve reserve that buyers accumulated during the fill. The token side comes from an allocation that the program held back rather than selling along the curve. The two are deposited together, which establishes the opening ratio of the new pool and therefore the opening quote, generally close to the final curve quote.
The pool position representing that deposit is then burned or locked. This is a real and meaningful protection: it removes the possibility that whoever launched the token later withdraws the deposited liquidity and leaves holders with an asset that cannot be sold. It is also the protection most frequently overstated, because of what it does not cover.
What it does not cover is supply. Locking the pool position says nothing about who holds the tokens. If a small group accumulated a large share of supply during the curve phase, they can still sell that share into the new pool. The economic effect on other holders is close to identical to a withdrawal, since both drain the same SOL side. Concentration is a separate check and it has to be done separately.
Two different risks, one word
Liquidity risk is the risk that the pool is emptied by whoever supplied it. Supply risk is the risk that a concentrated holder sells into it. A burned pool position addresses the first and leaves the second untouched. Reading a top-holder list takes a minute and answers a question the burn cannot.
The first minutes after migration
Several things happen at once, and none of them is about the project. The pool is new, so aggregators and price trackers need to discover and index it. Different interfaces update at different speeds, which produces short-lived divergence between quotes. Automated participants that monitor migrations act immediately. Retail flow arrives later, once the token page in whichever interface someone is using has caught up.
The venue change also breaks anything that was pointed at the curve. A multi-DEX Solana volume bot has to be repointed at the pool address taken from the migration transaction, because the curve program stops accepting swaps in the same block, and a route that still targets it simply fails. Whether a given tool covers the destination venue at all is worth checking before the threshold is reached rather than after.
Depth also resets in a way that catches people out. During the fill, the curve reserve grew steadily and the cost of selling was a smooth function of how far along you were. After migration, depth is a fixed deposit sitting in a pool, and the first large sell consumes a visible share of it. A sell that was routine on the curve can be expensive in the first minutes of the pool.
Read the reserve, not the bar
Open the curve account in an explorer and read the SOL balance directly. The percentage in an interface is a rendering of that balance against an assumed threshold. If the threshold parameter has changed, the rendering is wrong and the balance is still right.
Record the mint address first
Write down the mint before anything moves. Migration events attract imitation mints with the same name and image. The mint address is the only identifier that survives the transition unchanged, and it is what you should paste into any interface afterwards.
Watch for the migration transaction
The state change is a transaction against the curve account. Finding it tells you exactly when the boundary occurred, which matters when you later try to reconcile volume figures that are split across two market records.
Find the new pool and read its depth
Locate the pool created by the migration and read the deposited amounts on both sides. That pair of numbers, not the market capitalisation, determines what a trade of your intended size will cost. Everything else on the page is downstream of it.
Model your exit before you enter
Take the size you are considering and work out what selling it would do to the pool ratio. If the answer is a large percentage, the position is bigger than the market, and no amount of activity on the token page changes that arithmetic.
The behaviour of volume across this boundary deserves its own treatment, because a large part of the apparent collapse in reported figures after a migration is an artefact of how trackers attribute trade rather than a real decline in interest. That is worked through in the note on post-migration volume, along with what the first pool hour typically contains.
Five misconceptions about graduation
These five come up constantly, in that order of frequency. Each of them is a reasonable inference from the word graduation and an incorrect inference from the mechanism. The right column is not an opinion about the token; it is a statement about what the program did and did not do.
| Belief | What the mechanism actually supports | How to check for yourself |
|---|---|---|
| The token has been vetted | A balance crossed a threshold. No party inspected the mint, the metadata or the holders | Read the mint authority and the top-holder list in an explorer |
| The price will rise from here | The migration sets an opening ratio close to the final curve quote and implies no direction | Compare the first pool trades against the last curve trades |
| Liquidity is now deep | Depth is exactly what was deposited, which is bounded by the threshold | Read both deposited sides and model a sell of your size |
| Nobody can take the money now | The pool position is locked or burned, but token supply in wallets is untouched | Check what share of supply the largest holders control |
| The progress bar is a countdown | It renders a reserve balance, so net selling moves it backwards | Watch the reserve balance over several minutes, not the percentage |
There is a sixth that is harder to state as a row. People treat graduation as a rare achievement, and the rarity is real, but rarity is not the same as quality. A filter that selects for enough net buying to fill a reserve selects for attention. Attention and durability are correlated only weakly, and the correlation is weakest exactly where the attention was manufactured.
A before and after checklist
This is the sequence the lab runs when a token is approaching the threshold and again once it has crossed. None of it requires paid data. All of it is readable from a block explorer and the token page itself, and the whole pass takes a few minutes once you know which fields matter.
Before the threshold
- Read the curve reserve balance directly rather than trusting a rendered percentage against an assumed threshold value.
- Compare net reserve growth against reported volume. A large gap means turnover, not accumulation, and the bar will stall.
- Count distinct signers over the last hour. Progress driven by a handful of addresses can reverse as quickly as it appeared.
- Check top-holder concentration now, while the exit path is still the curve and the numbers are easy to read.
- Confirm the current threshold parameter and the current migration destination against the protocol, not against a blog post.
After the transaction lands
- Verify you are looking at the same mint address you recorded before the migration, not an imitation created around the event.
- Read the deposited amounts on both sides of the new pool and treat that pair as the real definition of available depth.
- Confirm the pool position was burned or locked, and note that this covers liquidity withdrawal only.
- Model a sell at your intended size against the deposited depth before treating any position as exitable.
- Give trackers time before reading volume. Figures in the first minutes often split across two market records.
One closing caution that applies to every number in this note. Threshold values, fee percentages and migration destinations are program parameters, and program parameters change. Nothing in the reasoning here depends on a specific value, which is deliberate. Any specific value you carry away should be re-verified against the protocol before you size a position or a budget around it.
Questions readers ask
What is the Pump.fun graduation threshold?
It is the level of accumulated curve reserve at which the program marks the curve complete and migrates liquidity into an automated market maker pool. The figure is widely documented as roughly 85 SOL of reserve, but launchpad parameters are program constants that have been revised before, so verify the current value against the protocol rather than against an article.
Does graduation mean a token is safe?
No. Graduation is an arithmetic condition on a balance, not a review. Nobody inspects the mint authority, the holder distribution, the metadata or the team. A token that reaches the threshold has demonstrated that enough net buying occurred to fill the reserve, and that is the entire content of the signal.
Where does the liquidity go when a token graduates?
Into an automated market maker pool created by the migration routine. Migrations were historically routed to Raydium, and the platform later introduced PumpSwap as a destination. Both statements describe documented history rather than a current guarantee, so confirm the destination venue and the resulting pool address before you trade the post-migration market.
Why does the curve progress bar move backwards?
Because it tracks a reserve balance, not elapsed effort. Buying adds SOL to the reserve and selling removes it, so net selling reduces the percentage. A bar that climbs and falls repeatedly is describing a market that is churning rather than one that is steadily approaching the threshold.
Can a team still take the money after graduation?
Burning or locking the pool position removes the ability to withdraw the deposited liquidity, which is a real protection. It does nothing about token supply held in wallets. A concentrated holder can still sell into the new pool, and that sell drains the same reserve that a withdrawal would have taken.
What happens to price in the first minutes after migration?
Depth resets to whatever the migration deposited, aggregators and trackers need time to index the new pool, and stale quotes across interfaces create short-lived arbitrage. The direction of price in that window carries no information about the project. The only reliable read is the actual depth in the new pool.
Parameters and routing should be checked against the launchpad itself at Pump.fun. Reserve balances, migration transactions and pool deposits are all verifiable in a block explorer such as Solscan, and the account and transaction semantics behind them are described in the Solana documentation. Thresholds and destinations have changed before and can change again.