Curve to AMM handover
The whole sequence from completion condition to first pool swap, written as program behaviour, with the parameters named rather than guessed and the failure points marked where they occur.
Read the mechanismThe moment a token changes venue
A launchpad token spends its first life on a bonding curve, where price is a function and there is no counterparty. Then a completion condition is met, a migration routine runs, and the same mint wakes up inside an automated market maker pool where price is a ratio of reserves and every trade moves it.
This desk documents that single event and the two states either side of it. Not the hype around it, not a prediction of what a chart does afterwards: the mechanism, the accounts involved, what carries across, what is left behind, and the specific ways the sequence goes wrong for people who were not watching.
Four words, four different things
Most confusion about graduation comes from treating these as interchangeable. They are not.
- Mint
- The token account address. It is the identity, it is created once, and migration never changes it.
- Curve
- A program-held pricing function. Price depends on how much of the supply has been sold, not on who is willing to trade.
- Pool
- A new account holding two reserves. Price is their ratio, and it moves because a trade changes the ratio.
- Route
- The path a swap actually takes. It is rebuilt by aggregators after migration, and it is the part that lags.
The handover, in five movements
Every launchpad implements this differently and every launchpad has changed its implementation at least once. What follows is the shape the sequence takes, not a schedule. Where a parameter would normally appear, this desk names the parameter instead of printing a number that will be wrong by the time you read it.
- Movement one
The curve fills
Buyers trade against a deterministic pricing function held in a program account. Each purchase advances the curve, raises the quoted price for the next buyer, and adds quote asset to a reserve the program controls. Nobody provides liquidity, because there is no liquidity to provide; there is only the function and the reserve behind it.
- Movement two
The completion condition is met
The launchpad defines a condition that marks the curve complete, usually expressed in terms of the reserve accumulated or the share of supply distributed. The condition is a parameter set by whoever operates the launchpad, it has been revised in the past, and it should be read from the protocol rather than from an article. When it is met, the curve stops accepting trades.
- Movement three
The migration routine runs
A privileged instruction creates the destination pool, moves the accumulated quote asset and the reserved token allocation into it, and mints liquidity provider tokens against that deposit. This is a transaction like any other. It occupies a slot, it has a signature you can open, and it can fail and be retried.
- Movement four
Liquidity is put beyond reach
The LP tokens created by the deposit are typically burned or locked by the routine so that the seeded liquidity cannot be withdrawn by anybody, including the launchpad. Whether that happens, and how, is the single most important thing to verify on the transaction rather than assume from a screenshot.
- Movement five
The rest of the world catches up
The pool is live from the slot it was created in, but aggregators, screeners, wallets and charting sites each discover it on their own schedule. For a period that nobody controls, the token is tradeable and simultaneously mis-priced, mis-routed or entirely absent on half the surfaces people use to look at it.
Featured desk notes
Four pieces that cover the ground most readers arrive looking for: the mechanism end to end, what actually changes hands, how to identify the real pool, and why the chart jumps at the seam.
What graduation actually moves
A line-by-line inventory of what migrates and what does not. The mint persists, the reserves move, the pricing rule is replaced, and several things people expect to carry across never existed in the first place.
Read the inventoryThe new pool address
The mint is the identity and the pool is the venue. Confusing them is the most expensive error of the first hour. How to derive the real pool from the mint and prove it before sending anything to it.
Read the methodPrice and depth discontinuity
Two different equations meeting at one instant. Why the last curve price and the first pool price need not agree, why slippage behaves differently afterwards, and what a stitched chart is hiding.
Read the analysisThree phases, one event
Everything on this site is filed by where it sits relative to the handover. Before is the curve phase and what can be settled while it lasts. The handover is the event itself. After is the pool, the routing and the chart.
The handover
The migration event itself. What the launchpad program does when a curve completes, what it hands to the destination venue, and the ways the sequence can stall or land somewhere nobody was watching.
Open this phaseBefore
The state a token is in while it still trades on a bonding curve, what can be prepared while that state lasts, and how to watch a curve approach its completion condition without guessing.
Open this phaseAfter
The state a token is in once a pool exists. New account, new pricing rule, new fee path, new routing dependencies, and a chart that has to be stitched across two different mechanisms.
Open this phaseThe post-migration checklist
Three groups of checks for the window that opens the moment the pool exists. None of them require paid tooling; all of them require knowing which account you are looking at.
Verify the venue
- Open the migration transaction by signature and read which program created the pool.
- Confirm the pool holds the mint you expect, not a mint with the same ticker.
- Check whether LP tokens were burned, locked or left in a withdrawable account.
- Record the pool address somewhere your team can paste from, before anyone needs it.
Verify the routing
- Ask an aggregator for a quote and see whether it returns a route through the new pool.
- Compare the quoted price against the pool reserves you can read directly.
- Watch for front ends still quoting a curve that has already stopped accepting trades.
- Expect a lag, and expect different surfaces to end that lag at different times.
Verify the reading
- Treat the first candles as a new series, not a continuation of the curve series.
- Read depth alongside turnover, because the same turnover means different things at different depths.
- Count distinct signers, not just transactions, before concluding anything about participation.
- Note which claims you are inferring, and keep them separate from what the chain shows.
Coverage has to follow the token
Anything that watches, measures or interacts with a token by venue has a problem at migration: the venue it was configured for stops being the venue the token trades on. Alert bots keyed to a curve go quiet. Dashboards keyed to a pair address show a flat line. Any automation pointed at the old route simply stops landing, and the failure is silent rather than loud.
The same applies to tooling that produces market activity deliberately. Teams that treat activity on activity-ordered screens as a distribution expense have to re-point that tooling at the new pool, or it keeps paying fees into a venue nobody is trading on. Multi-venue coverage is not a feature people ask about until the day the venue changes underneath them.
This desk takes no position on whether producing activity is worth doing. It insists only on describing it accurately: it changes what an activity-ordered screen displays, and it does not change whether a person who sees the row decides the token is worth their attention.
What breaks at the seam
- Alert rules bound to a curve account that no longer accepts trades.
- Price feeds reading a pair address that is not the pair the token now uses.
- Cached routes inside front ends that quote a path which can no longer execute.
- Charts stitched across two pricing mechanisms without a marker at the join.
- Holder tooling that assumed liquidity is withdrawable when it was burned, or the reverse.
- Any automation configured by pair rather than by mint, which is most of it.
How this desk documents transitions
Three rules that decide what gets published here and, much more often, what does not.
Mechanism, never a number
Launchpad thresholds, migration fees and timing parameters are set by operators and have been changed more than once. Printing them as constants creates a document that is wrong later without ever announcing it. This site names the parameter, explains what it controls, and tells you to read the current value from the protocol.
Documented, observed, inferred
Every claim about program behaviour belongs in one of three buckets. Documented means the project published it. Observed means anyone can open a transaction and see it. Inferred means the desk worked it out and could be wrong. The bucket is stated on the line where the claim appears.
No outcomes are promised
Nothing here predicts what a token does after it graduates. There are no price targets, no success rates, no survival statistics, because the desk holds no dataset that would support any of them. What can be described is the machinery, and the machinery is what most people are actually missing.