Planning for Graduation Without Assuming It
Graduation is a mechanical event with a small window and a long list of things that should already be finished when it arrives. This page covers what actually changes when trading moves from a curve to a pool, what the desk signs off in advance, and why the same plan has to work if it never happens at all.
Graduation is the moment a bonding curve reaches the launchpad completion condition and trading moves to an automated market maker pool. The platform takes the reserve collected by the curve and the remaining supply, seeds a pool with them, and from that point price comes from pool reserves rather than the curve formula. Everything after that sentence is preparation, because the event has a short window and no rehearsal.
This page is the preparation piece. It covers the mechanics plainly, sets out what is different on the other side, and gives a readiness sheet you can sign before launch day. It also insists on something teams dislike hearing: most launches never reach this event at all, and a plan that only works if migration happens is not a plan.
What graduation is, mechanically
A bonding curve is a formula that sets price against the quantity of tokens already sold. Every buy moves along the curve and raises the price for the next buyer; every sell moves back down it. There is no counterparty and no order book. The curve also accumulates the SOL that buyers pay in, and that accumulated reserve is the material the next step is built from.
Completion happens when enough of the curve has been bought out to satisfy the platform condition. At that point the launchpad closes the curve and creates a pool on an automated market maker, funded with the collected reserve on one side and the remaining token supply on the other. An AMM pool holds two reserves and prices trades from the ratio between them. Trading continues there.
Three things about that sentence are launchpad decisions rather than facts of nature: the completion condition itself, any fee taken at migration, and which venue the pool is created on. All three have changed over the life of these platforms and all three can change again without asking you. An independent desk should not hand you a number for any of them.
Definition: the completion condition
The completion condition is the launchpad's own rule for when a curve is finished. It is expressed in the platform's terms, it is enforced by the platform's code, and it is published by the platform. Read it on the launchpad itself at the time you are planning, and read it again close to launch. Launch Desk is independent and has no view into what the current setting is.
It is worth being precise about what does not change. The mint address is the same token before and after. Holder balances are unaffected by migration. Nothing in your metadata is rewritten by the event. What changes is where trading happens and how price is determined there, which is enough to invalidate a surprising number of assumptions carried over from the curve.
Curve and pool, side by side
The table below is the single most useful artefact on this page. Read it before you write any communications, because most of the confusion published on migration day comes from a team describing pool behaviour in curve language, or telling holders to expect something that only applied on the other side of the event.
| Surface | On the bonding curve | In the AMM pool |
|---|---|---|
| Price source | A formula applied to the quantity sold so far | The ratio between the two reserves held by the pool |
| Slippage | Follows the curve shape; predictable from position on the curve | Depends on trade size relative to pool depth; large trades move price more |
| Counterparty | The curve contract itself, always available | The pool reserves, which can be added to or withdrawn by liquidity providers |
| Routing | Bought and sold through the launchpad interface | Routable by aggregators, which may split a trade across venues |
| Liquidity | Fixed by the curve design; no one adds to it | Anyone can in principle add liquidity, and providers can withdraw |
| Monitoring surface | One page, one chart, one transaction stream | Pool address, chart indexers, aggregator listings, LP positions |
| Typical failure | Curve never completes; nothing happens | Thin pool, wide execution, a chart that has not indexed, LP surprises |
| Sell pressure | Moves back down the same curve | Draws down one reserve and can move price hard when depth is low |
The bottom two rows are the ones teams underprepare for. A curve that never completes is a quiet failure that costs you the launch, and it is dealt with in the triage sequence for a stalled launch. A thin pool is a loud failure that costs you credibility on the day you were expecting to celebrate, because everything is suddenly working and looking bad at once.
What changes for someone buying
From a buyer's point of view the biggest change is how the price of a given trade is formed. On the curve, the cost of a purchase is determined by where the curve currently sits. In a pool, the cost is determined by how large your trade is compared to the reserves standing behind it, which means the same order can execute very differently in a deep pool and a shallow one.
As an illustration, and ignoring fees entirely, take a pool that holds 100 SOL on one side and 1,000,000 tokens on the other. The reference price implied by that ratio is 0.0001 SOL per token. A buyer spending 1 SOL raises the SOL reserve to 101, and a constant-product pool returns roughly 9,901 tokens, which is an average cost of about 0.000101 SOL per token, or roughly one percent above the reference price.
Now run the same illustrative pool against a larger order. A buyer spending 10 SOL raises the SOL reserve to 110 and receives roughly 90,909 tokens, an average cost of about 0.00011 SOL per token, or roughly ten percent above the reference price. Same pool, same moment, ten times the size, ten times the cost above reference. That is the whole of what people mean by depth.
The illustration is arithmetic, not a forecast
The figures above are invented for the purpose of showing how the ratio behaves and they exclude fees, routing and every other real-world effect. They are not a claim about any pool you will ever see. Use them to understand the shape of the relationship between size and cost, and nothing else.
The second change is routing. Once a token trades in a pool, aggregators can find it and route trades to it, potentially splitting an order across venues to improve execution. That is generally good for buyers and it introduces a surface you did not have before, where your token appears in interfaces you do not control. The mechanics of that routing are documented by the aggregators themselves, for example in the Jupiter developer documentation.
What changes for the team
Your monitoring surface multiplies. Before migration there is one page to watch. After it there is a pool address, at least one chart source, aggregator listings that appear on their own schedule, and any liquidity positions that exist. Each of those can be wrong or lagging independently of the others, and each will generate a question in your chat within minutes of somebody noticing.
Liquidity provision becomes a live question for the first time, and it deserves a decision made in advance rather than in the excitement of the day. Providing liquidity means holding a position whose composition changes as the price moves, with real and well-documented downside. If your team has not decided its position on that before migration, the correct answer on the day is that you are not doing anything yet.
Tooling choice belongs to the same category. Teams reach for monitoring, alerting and trading services at exactly the moment they have least capacity to evaluate them, which is why the selection should be finished before the completion condition is anywhere near being met. That applies as much to a paid Solana volume bot platform as it does to a free chart alert, and the honest framing is the same for both: no tooling makes a curve complete, and none of it creates a buyer who did not exist.
Say that clearly inside the team, because the pressure runs the other way. A curve sitting close to completion invites the idea that a push would finish it. Buying does move a curve, since buying is the only thing that moves it, but a purchase you funded is your own money changing your own position, and the wallets involved are permanently readable by anyone who looks. Activity is not demand and cannot be presented as demand.
The readiness sheet, signed in advance
Everything below should be done, checked and initialled before launch day, not on migration day. The test of the sheet is simple: if the completion condition were met while you were asleep, could the person on the rota execute the entire list without waking anyone or making a judgement call? If not, the item is not ready.
- The migration announcement is drafted, approved and saved somewhere the on-call person can publish from, with a blank left only for the pool link.
- A second draft exists for the case where migration does not happen, so the team is never composing that message under pressure.
- The method for finding and verifying the new pool address is written down, and the person on the rota has practised it on somebody else's token.
- The chart source your community will use has been named, and everyone on the desk knows it may lag the pool by some minutes.
- A rota exists covering every hour in which completion is plausible, with a named person, a contact method and a fallback for each slot.
- The team position on providing liquidity is decided and written down, including the answer no.
- Monitoring and alerting are configured and tested, including a test that fires when nothing is wrong so you know the alert path works.
- The wallet policy for the post-migration period is agreed, including which wallets may transact and who authorises it.
- A single sentence is agreed for what the team will and will not say about price. Write it now, while nobody is watching.
- The post-migration budget line is ring-fenced and cannot be consumed by launch-day spending.
That last item is the one most often broken. A budget written as one pool of SOL gets eaten by an eventful launch day, and the team arrives at migration with nothing left for the week that follows. Splitting the budget into lines that cannot borrow from each other is the whole point of the arithmetic in budgeting the curve.
The moment itself: who does what
Migration is a short event with a lot of simultaneous demand for attention. The schedule below allocates that attention in advance. It assumes three roles, which one person can hold in a small team as long as the order is respected: a publisher who controls the accounts, a reader who works the chain, and a host who answers the room.
| Phase | Owner | What must happen |
|---|---|---|
| Approach | Reader | Watch the curve position and tell the desk when completion is plausible within the hour. |
| Trigger | Reader | Confirm on chain that the curve has closed and the pool exists. Confirmation comes from the chain, not from a chart. |
| Verify | Reader | Check the pool address, confirm both reserves are present, and hand the verified link to the publisher. |
| Publish | Publisher | Post the prepared announcement with the verified link. No improvisation, no price commentary. |
| Hold | Host | Answer the room. Expect questions about charts that have not indexed yet and say so plainly. |
| Sweep | Reader | Run the thirty-minute checks below and log every result, including the ones that are fine. |
| Stand down | Publisher | Confirm in the chat when the desk is closing and when it opens again. Then close it. |
The rule that saves the most trouble is the one in the trigger row. Confirmation comes from the chain. Charts, bots, screenshots and enthusiastic community members will all announce migration before it has happened at least once in your launch, and publishing on their word is how a team ends up correcting itself in public on the day it most wanted to look competent.
The first thirty minutes on the new venue
Run these in order, log the result of each, and do not skip the ones you expect to pass. The value of the sequence is that it produces a written state of the world at the start of the post-curve period, which is the baseline everything in the following week is compared against.
- Verify the pool on an explorer. Confirm the pool exists, holds both reserves and references your mint address. An explorer such as the Solana explorer is the authoritative surface here; a chart is not.
- Confirm the mint is unchanged. Check that the mint address people held before migration is the address trading now, and be ready to state it in the chat when someone asks whether they need to do anything. They do not.
- Do a small round trip. From a wallet outside the team, buy a small amount and sell it. You are testing that trading works and that execution behaves as expected, not moving the price.
- Check every published link. Open the announcement as a stranger and click through. A migration post with a wrong or unindexed link is worse than a post published ten minutes later.
- Check the chart sources. Note which have indexed the pool and which have not. Tell the room which link is authoritative until the others catch up.
- Check aggregator routing. See whether the token is routable and, if not yet, say that it may take time rather than letting the chat conclude something is broken.
- Read the first trades. Look at who is trading and in what size. This is the first page of the post-curve holder record and it is worth reading properly.
- Write the log. Time, pool address, reserves at verification, chart status, routing status, anything unexpected. Ten minutes now, valuable all week.
What happens after those thirty minutes is a different job with a different rhythm, and it belongs to the week after migration. Do not let migration day expand into an improvised week. The desk closes, the log gets written, and the next phase starts on its own schedule with its own plan.
The plan that works either way
Most launches on a bonding curve never complete it. That is the base rate, it is not a comment on your project, and the only sensible response is to build the plan so that both branches are real. A plan with one branch is a wish with a schedule attached, and it fails in a specific way: the team keeps waiting for an event that is not coming, and the waiting itself consumes the time and budget that the other branch needed.
Practically, that means every commitment you make in public before migration must be phrased so that it survives the curve not completing. Do not announce a date for something that depends on a pool existing. Do not promise a listing, an integration or a milestone whose precondition is an event nobody controls. Describe what you will do, and describe the branch, and let people judge you on the part you actually decide.
It also means the calendar has a defined end. Decide before launch how long you will keep a desk staffed for a curve that has not completed, and what standing down looks like when that time is reached. Teams without that line either burn out slowly or spend against the post-migration budget on the assumption that they will get there, which is how a launch ends with nothing left for a pool it never opened.
Write both announcements before you launch
Draft the migration post and the we-are-standing-down post on the same afternoon, before either is emotionally loaded. The second one is short: what happened, what you are doing with the token, when you will speak again. Having it written removes the temptation to say nothing, which is the response that costs a team the most for the longest.
The wider version of this argument, applied across all four phases of a launch rather than only this one, sits in the launch strategy overview. The short form is worth carrying into every meeting between now and launch day: separate the things you decide from the things you merely hope for, plan the first group properly and in writing, and never publish a commitment whose precondition sits in the second group.
Read the platform, not this page
Launch Desk is independent. It is not affiliated with any launchpad, has no privileged access to any of them, and cannot tell you what today's rules are. Everything on this page describes a mechanism: a curve accumulates a reserve, a completion condition is met, a pool is created from that reserve and the remaining supply, and trading continues in the pool. That mechanism has been stable in shape while its parameters have not.
The parameters that must come from the platform are the completion condition, any fee applied at or around migration, and the destination venue the pool is created on. Each of those has changed before. If you find a number for any of them in a blog post, including this one, treat it as out of date until you have confirmed it against the platform's own current documentation on the day you are planning around it.
The rest of the after-graduation material, including liquidity questions and the reporting rhythm for the days that follow, is collected in the after graduation hub. Read it before you need it. The consistent pattern in launches that handle migration well is not that they knew more on the day, but that they had already decided almost everything they would otherwise have been deciding while the room watched.
Questions the desk is asked
What is graduation on a bonding curve launchpad?
It is the point at which the curve has been bought out to the platform completion condition. The launchpad then moves the collected reserve and the remaining token supply into an automated market maker pool, and trading continues in that pool instead of against the curve formula.
What is the threshold for graduation?
It is set by the launchpad, it has changed more than once, and it is not something an independent desk should quote at you as a fixed number. Read the current completion condition, the fees attached to it and the destination venue on the platform itself before you plan around any figure.
Does most of a launch graduate?
No. The large majority of tokens launched on a bonding curve never complete it. That is the base rate a plan should be built on, which is why every commitment that depends on migration needs a version that works when migration does not arrive.
What actually changes at the moment of migration?
The price source changes. On the curve, price follows the formula against tokens sold. In a pool, price comes from the ratio of two reserves, so slippage depends on trade size against pool depth. The token also becomes routable by aggregators and appears on different charts.
Do we need to add liquidity ourselves?
Usually not at the moment of migration, because the launchpad seeds the pool from the collected reserve. Anyone can in principle add liquidity to an open pool afterwards. Whether your team should is a separate decision with real risk and it should be made before the day, not during it.
Who should be awake when migration happens?
Someone with publishing rights, someone who can read the chain, and someone who can answer the chat. Migration does not schedule itself around your timezone, so the rota needs a named person for every hour in which the completion condition could plausibly be met.
What if the chart shows nothing after migration?
Chart indexers pick up a new pool at their own pace. Verify the pool on an explorer first, then check whichever chart source your community uses, and tell people which link is authoritative. Publishing a chart link that has not indexed yet creates avoidable confusion.
Can tooling make a curve complete?
No. Buying moves a curve because buying is what moves it, and paid activity is buying you funded yourself. It does not create demand, the wallets involved are visible on chain, and presenting purchased activity as organic interest misrepresents the token to the people you are asking to buy it.
Filed in After graduation by The Launch Desk. Protocol behaviour on this page is described from public documentation; every figure that is not a protocol fact is labelled illustrative. How the desk handles numbers and corrections is set out in the editorial policy.