What Graduation Actually Moves, And What It Leaves Behind

Graduation moves exactly two things: the quote asset the curve accumulated, and a token allocation the program was holding back. It also replaces one thing, the authority that decides price. Everything else people expect to migrate either stays exactly where it was, because it was attached to the mint rather than to the venue, or never existed during the curve phase at all.

Three buckets, not one

The useful way to think about a liquidity handover is not as a move but as a sorting exercise. Every element of a token's situation falls into one of three buckets: it moves, it stays, or it was never there. People who get the first hour after migration wrong almost always have one item in the wrong bucket, and the error is usually the third one, because it is invisible.

The moves bucket is small. It contains two balances. That is genuinely all, and its smallness is the most surprising thing about the mechanism once you see it clearly.

The stays bucket is large and boring, which is why nobody thinks about it. It contains the mint, the supply, holder balances, metadata, and every piece of tooling that was configured against a mint address rather than a trading venue.

The never-existed bucket is where the expensive mistakes live. It contains depth, liquidity providers, withdrawable positions and anything else that is a property of pools rather than of curves. Reasoning about a curve using pool intuitions produces conclusions that feel right and are not.

What moves: the two balances

The first balance is the accumulated quote asset. Every purchase against the curve paid quote asset into a reserve controlled by the launchpad program. Over the life of the curve that reserve grows monotonically, minus whatever leaves through sells, and at completion it holds the bulk of the value that has entered the token so far.

That reserve is the source of the pool's quote side, less a retained share. Retention is normal and is how launchpads earn: they define a fee under their own model and keep it out of the migration deposit. The size of the retained share is a parameter, it has been revised historically, and this desk names it rather than printing it for exactly that reason.

The second balance is the token allocation. A curve does not offer the whole supply for sale. Some portion is held back specifically to be paired against the migrated quote asset, because a pool with only one side is not a pool. This allocation was always part of the supply figure; it simply had not been distributed. When it moves into the pool it is not new issuance, and describing migration as minting tokens misreads what happened.

The ratio between the two deposits is the opening price. Not a price anyone chose, not a price carried over from the curve, and not necessarily equal to the last curve quote. It is the arithmetic consequence of how much of each side got deposited.

What moves: the pricing authority

Strictly this does not move, it is replaced, and the distinction is worth keeping. Before migration, price came from evaluating a function held in program state. After migration, price is the ratio of two balances that anybody's trade can change. The old authority is not transferred to the new venue; it is retired, and a different mechanism takes over.

This is why the last curve price and the first pool price are not required to match. They are outputs of unrelated calculations. It is also why slippage stops behaving the way traders had learned during the curve phase: on a curve, the cost of a given order size is a closed-form consequence of the function, while in a pool it depends on how much depth happens to be there at that instant.

Anything downstream of pricing inherits the change. Oracles reading a price have to read it from somewhere else. Bots computing expected fills have to compute them differently. Charts built from trade prints switch data sources without necessarily saying so.

What stays: the mint and everything keyed to it

The mint address is created once, when the token is created, and it survives migration untouched. That follows from how mint and token accounts are defined in the SPL token documentation rather than from anything a launchpad chooses to do. It is the most important stable fact in the entire sequence, and it is the one that resolves most of the panic in the first hour.

Everything attached to the mint stays with it: name, symbol, decimals, metadata URI, mint and freeze authority state, and the complete record of who holds what. A wallet that showed a balance before migration shows the same balance afterwards. No holder action is required, and any instruction telling holders to send tokens somewhere to complete a migration is describing a step that does not exist in this mechanism.

Tooling configured by mint therefore survives. A holder-count tracker keyed to the mint keeps counting. A supply monitor keyed to the mint keeps monitoring. A transfer alert keyed to the mint keeps firing. If your dashboard broke at migration, the reason is that it was keyed to a venue, and the fix is structural rather than a matter of updating one address.

What stays: holders and their balances

Balances live in token accounts owned by wallets and associated with the mint. Migration touches none of them. A holder who bought on the curve holds the same quantity of the same token after graduation, at whatever the new venue prices it, and anybody can confirm that for a specific address in an explorer such as Solscan rather than taking it on trust.

What changes for that holder is entirely about exit conditions. During the curve phase, selling meant trading back along a function that would always quote something. After migration, selling means taking liquidity out of a pool, and the price received depends on the depth present at that moment and on what everybody else is doing in the same block. The token in the wallet is identical; the market around it is not.

Concentration is likewise unchanged and unimproved. If a small number of addresses accumulated most of the circulating supply during the curve phase, they still hold it afterwards. Migration is not a redistribution event and does not dilute anybody. Reading a graduation as a fresh start for the holder base is a category error that costs people money regularly.

What never existed on the curve

This is the bucket that catches experienced traders, because their instincts were trained on pools and order books.

• Depth. A curve has no depth. The function is defined over its whole domain, so there is no book to exhaust and no size at which quoting stops. Asking how deep a curve is has no answer.
• Liquidity providers. Nobody deposits into a curve, so nobody can withdraw from one. There is no LP position to check, no LP token to trace and no provider to worry about leaving.
• A withdrawable pot. The curve reserve is controlled by program logic, not by a signer with discretion over it. The pre-graduation risk profile is therefore not the one people picture when they say liquidity could be pulled.
• Arbitrage against another venue. While the token trades only on the curve there is nowhere else to arbitrage against. Cross-venue price differences become possible only once a second venue exists, which is one reason the minutes after migration look unusually busy.
• Routing. A curve is not part of a general routing graph in the way a pool is. Aggregator behaviour before and after graduation is not comparable, and a route that existed before is not evidence that one exists after.

The full inventory

The liquidity handover in particular

The phrase liquidity handover suggests liquidity being passed from one holder to another. What actually happens is that value which was held as a program-controlled reserve is converted into a liquidity position in an AMM, where depositing both sides of a pair mints a provider token representing the claim on those reserves, as the Raydium documentation sets out for its own pools. That position is then usually disposed of so nobody holds it.

Burning or locking the LP tokens produced by the deposit is the step that gives the seeded liquidity its permanence. It is a real guarantee about a specific position and it is narrow. It says the migration deposit cannot be withdrawn. It says nothing about liquidity added later by other providers, who can withdraw whenever they like, and nothing at all about price.

The practical consequence is that pool depth an hour after migration is not necessarily the depth the migration created. Providers may have added, and providers who added may have left. Anybody reasoning about slippage from the seeding deposit alone is reasoning from a snapshot that expired within minutes.

Illustrative arithmetic on the retained share

What this means for anything you have configured

Sort your own stack into the same three buckets and the migration checklist writes itself. Anything keyed to the mint needs nothing. Anything keyed to a venue needs a new address. Anything that assumed a property from the never-existed bucket needs rethinking rather than reconfiguring.

Alert rules are the usual casualty. A rule watching the curve account for large buys simply stops firing, and stopping is silent. Nobody gets an error, no dashboard turns red, and the first sign of trouble is somebody noticing the channel has been quiet for two hours. That failure mode is worse than a loud one because it looks exactly like a calm market.

The same applies to anything that produces market activity rather than just observing it. A campaign configured against the curve keeps trying to trade a venue that now rejects trades, and one configured against a single pool has no answer when routing changes again later. Teams that run this kind of activity across a launch tend to end up wanting a multi-DEX Solana volume bot for the same reason they want a mint-keyed dashboard: the token is the constant, and the venue is the thing that changes underneath it.

The last item on the list is documentation. Whatever your team decided at migration, write down the pool address, the migration signature and what happened to the LP position, in a place somebody can find at speed. The window when that information matters most is the window when nobody has time to go and derive it.

Questions the desk is sent