Curve To AMM Handover: How A Migration Actually Runs

A migration moves a token from a bonding curve to an automated market maker pool by running a transaction that freezes the curve, creates the pool accounts, deposits the accumulated quote asset and a reserved token allocation into them, and disposes of the liquidity position that deposit creates. The mint does not change. The pricing rule is replaced outright. Everything people find surprising afterwards follows from those two sentences.

What a bonding curve is doing

A bonding curve is a pricing function held in a program account. It maps a position, meaning how much of the offered supply has been sold so far, to a price. Buying advances the position and therefore raises the price for the next buyer. Selling reverses it. The program is always willing to fill, because it is not matching you against anybody; it is evaluating an equation and adjusting an internal reserve.

This design solves a specific problem: a brand new token has nobody willing to make a market in it. A curve removes the need for one. It also removes several things people assume exist in any market. There is no depth, because the function is defined over its entire domain. There is no liquidity provider, because nobody deposits anything. There is no spread in the usual sense, because both sides are computed from the same rule.

The reserve behind the curve is real, though. Each purchase pays quote asset into an account the program controls, and that accumulated balance is the thing migration eventually moves. Watching a curve fill is watching that reserve grow toward whatever level the launchpad has defined as complete.

The completion condition

Every launchpad defines a condition that marks a curve finished. The condition is usually expressed either as an amount of quote asset accumulated in the reserve or as a share of the offered supply having been sold, and those two formulations are equivalent given a fixed curve, because one determines the other.

The number attached to that condition is a parameter. It is chosen by whoever operates the launchpad, it is stored in program configuration or hard-coded into a deployed version, and it has been revised across the ecosystem more than once. Any article that prints it as a fact is a document with an expiry date it does not display. Read it from the launchpad or from the deployed program, on the day you need it.

What is stable is the behaviour around the condition. When it is met, the curve is marked complete and further trades against it are rejected by the program. That rejection is important: it is what prevents the same asset trading on two venues with two different prices during the handover. From the perspective of a trader the token becomes briefly untradeable, which is not an outage but the correct behaviour of a system swapping venues.

The migration instruction, step by step

Whatever the launchpad, the routine has the same jobs to do in roughly the same order, because the ordering is forced by what depends on what.

1. Confirm and freeze. The program checks that the completion condition is genuinely met and that migration has not already run. The curve is marked complete so that no further trades can be accepted against it. Idempotence matters here; a routine that could run twice would double-spend the reserve.
2. Create the destination accounts. A pool account is created, along with a token account for each side of the pair and, on most AMM designs, a mint for the liquidity provider token. None of these addresses exist before this point, which is why you cannot look up a pool for a token that has not graduated.
3. Move the quote asset. The reserve accumulated by the curve, less whatever the launchpad retains under its own fee model, is transferred into the pool's quote-side token account.
4. Move the token side. A token allocation held back for exactly this purpose is transferred into the pool's base-side token account. The ratio between this and the quote deposit is what sets the opening price.
5. Mint the LP position. Depositing both sides of a pair into an AMM mints liquidity provider tokens representing a claim on those reserves. They have to go somewhere, and where they go is the most consequential decision in the whole routine.
6. Dispose of the LP position. Migration routines commonly burn these tokens outright or send them to a lock, so that the seeded liquidity cannot be withdrawn by anyone at all. This is the step that people mean when they say liquidity is locked at graduation.
7. Emit the record. The transaction lands in a slot with a signature, subject to the same confirmation and failure behaviour the Solana developer documentation describes for any other transaction. Account balances change, program logs are written, and every claim anybody later makes about this migration can be checked against that record.

The pool that gets created

The pool is a new account with an address of its own, and this is the single most common source of confusion in the hour after a graduation. The mint is the token's identity and it is unchanged, because a mint account under the Solana Program Library token standard is created once and is not rewritten by anything a launchpad does. The pool is the venue and it did not exist an hour ago. People who copy a pool address believing it is a token address, or who search for a token by an address that turns out to be a pool, lose money to that confusion regularly enough that it is worth its own note.

Most launchpad destinations are constant-product pools, meaning the product of the two reserves is held constant across a swap, less fees. That single rule produces every property people notice afterwards. Price is the ratio of the reserves. Large orders move price more than small ones, and the relationship is convex rather than linear. Price impact is symmetric in mechanism but not in feel, because the reserve you are draining gets scarcer as you drain it.

Depth becomes a live variable rather than a design property. The seeding deposit sets a starting point, and from that moment anybody can add liquidity and anybody who added can remove theirs. A pool that opened with a given depth may be deeper or thinner an hour later, and reading turnover without reading depth alongside it produces confident conclusions about nothing at all.

What happens to the LP position

Burning the LP tokens is a strong guarantee and a narrow one. It guarantees that the specific position created by the migration deposit can never be withdrawn, because the claim on it no longer exists in any account. It does not guarantee anything about the token's price, its supply distribution, its holder concentration, or liquidity that other providers add later and can remove whenever they want.

Locking is different from burning. A lock places the position in a program that will release it under some condition, usually time-based. The distinction matters because a lock has an end and a burn does not. Both are commonly described in the same breath as "liquidity locked", and the two produce quite different risk profiles a month later.

The correct way to know which happened is to open the migration transaction and read what became of the LP mint supply. If a burn occurred, the supply went to zero or the tokens moved to an address that provably cannot spend. If a lock occurred, the tokens sit in a lock program's account. If neither occurred, they sit somewhere spendable, and that is a fact worth knowing before anybody describes the token as safe.

The first swaps on the new venue

The pool is live from the slot it was created in. There is no warm-up period, no announcement step and no gate. Anybody who was watching the curve approach completion, and who has the pool address, can trade in the same block the pool appears. Anybody relying on a screener to tell them the token has migrated will find out some minutes later.

That asymmetry is structural rather than unfair. On-chain state is public the moment it is written; third-party indexes are derived data with their own refresh cycles. Teams that expect the two to be simultaneous are consistently surprised, and teams that plan for the gap have a much less dramatic first hour.

The other thing that happens immediately is routing. Aggregators build routes from an index of known pools. A pool that does not exist in that index yet is not routable, so a swap request that would ideally go through it will either fail or take a worse path through some other venue. This resolves on its own, but it resolves at different times for different aggregators, which is why two front ends can quote noticeably different prices during the same ten minutes.

Teams that run any kind of scheduled market activity across a launch hit this from the other direction: their tooling was configured against the curve and now points at a venue that rejects trades. If a campaign is meant to continue across the seam, the venue it targets has to change with the token, which is exactly the case a Pump.fun volume bot has to handle rather than assume away.

Illustrative arithmetic on the opening ratio

Curve and pool, side by side

Read down the middle column and the curve looks like the simpler instrument, because it is. Read down the right column and the pool looks like a normal market, because it is one. The migration is the moment a token stops being a simple instrument and becomes a normal market, and most of the difficulty is that nobody announces this to the people holding it.

Why no parameter is printed here

This desk does not publish the completion threshold, the migration fee or the expected time from completion to pool creation, and the reason is not caution for its own sake. Those values are set by operators. They live in program configuration or in a deployed program version. They have been changed before, occasionally more than once in a year, and changes are not accompanied by a notification to every site that quoted the old value.

What happens next is predictable. A number gets published, other sites copy it, it becomes the number everybody repeats, and eighteen months later people are budgeting against a figure that stopped being true. The failure is silent, which is what makes it worth avoiding. Naming the parameter and explaining what it governs stays correct indefinitely; printing its value stays correct until somebody changes a config.

The same discipline applies to venue destination. Where graduated tokens land has changed across the ecosystem, including launchpads that built their own automated market maker and began routing graduations to it rather than to a third party. That is a live setting, not a permanent fact, and treating it as permanent is how people end up watching an empty pool on a venue the token no longer uses.

What to read on the transaction

The whole sequence leaves a record, and the record answers most questions people would otherwise argue about. Open the migration signature in a block explorer such as Solana Explorer and work through this list.

• Which program invoked the pool creation, which tells you the destination venue rather than letting you guess it from a chart.
• The pool account address, which is the thing to save and paste to anybody asking where the token trades.
• Both deposit amounts, whose ratio is the opening price and whose product is the constant the pool will hold.
• Whether an LP mint was created and what happened to its supply immediately afterwards.
• Whether the destination for the LP tokens was a burn, a lock program or an ordinary spendable account.
• The slot and block time, which give you the exact boundary between the curve series and the pool series on any chart.
• Any remaining balance left on the curve account, which is normally the launchpad's retained fee under its own model.

Doing this once for a token you care about takes a few minutes and replaces every second-hand claim with something you read yourself. Doing it habitually is what separates people who can describe what happened from people repeating what a screener implied.

One practical note for teams that run activity across the transition rather than only observing it. The configuration you are carrying across is not the token; it is the venue. Anything venue-shaped in your setup needs to change, which is why the useful question to ask of any Solana volume bot is not what it can do on one venue but whether it follows a mint across a change of venue without a human noticing that it stopped.

Questions the desk is sent