Liquidity migration on Solana is the moment a token stops being priced by a launchpad bonding curve and starts being priced by an automated market maker pool. A migration transaction creates or funds that pool, deposits both sides of the pair, and mints LP tokens. Nothing about the token changes. What changes is the function that quotes it, the reserves behind that quote, and who controls them.
That distinction is the whole subject. Readers treat graduation as a milestone, a signal that a token has arrived. Mechanically it is a venue handover with a measurable before and after, and most of the confusion around it comes from reading a continuous chart across a discontinuous event. This note describes the handover in the order it happens on chain, then sets out what a careful reader can verify without trusting any dashboard.
Graduation as an on-chain event
A launchpad curve is a program that holds a token supply and quotes a price from a deterministic function of how much of that supply has been sold. Buying moves the quote up, selling moves it down, and the program is the only counterparty. There is no liquidity provider in the usual sense: depth is a property of the program's parameters rather than of anyone's deposited capital.
Graduation is the point at which that program's own completion condition is met and it stops accepting swaps. The condition is set by the launchpad, and it differs between launchpads, so the useful thing to know is not the threshold but the mechanism: the program flips a state flag, refuses further trades, and becomes eligible for migration. The comparison between the two pricing regimes is worked through in detail in the note on curve liquidity versus pool liquidity.
Two properties of this event are worth stating plainly. It is atomic at the level of the transaction that performs it, because a Solana transaction either applies all of its state changes or none of them. And it is observable: the flag flip, the pool creation and the deposits all appear in the ledger at a specific slot, which means every claim about what happened during a migration is checkable rather than arguable.
What graduation is not is a change in ownership, supply or contract. The mint is the same mint. The token accounts holding it are the same accounts, with the same nine-decimal or other configured precision they had before. Any account that held the token through the migration holds exactly the same balance afterwards, valued at whatever the new venue quotes.
What the migration moves, and what it does not
The migration transaction does a small number of concrete things. It creates or funds a pool account for the pair. It transfers a quantity of the quote asset and a quantity of the token into that pool's reserve accounts. It causes LP tokens to be minted, representing a claim on those reserves. Depending on the launchpad's design, it may also route part of the accumulated quote asset elsewhere, and it will mark the curve as retired.
It does not move holder balances. It does not create new buyers. It does not transfer the trading history to the new venue in any structural sense — the curve's swap records stay attached to the curve program, and the pool starts with an empty record of its own. Every dashboard that shows a continuous line across the boundary is stitching two independent data sources together, which is a display decision rather than an on-chain fact.
The most consequential detail is where the LP tokens go. An LP token is a redeemable claim: whoever holds it can withdraw the corresponding share of both reserves. If the LP tokens are burned or sent to an address that cannot act, the deposited depth is structurally permanent. If they sit in a wallet that can sign, the depth is removable at any block. Both arrangements are common and neither is announced on a chart, so it has to be read from the ledger.
The second detail is composition. A pool has two sides, and a pool is only as deep as its scarcer side allows for the direction you want to trade. A pool opened with a large token quantity and a modest quote balance can look substantial by token count while offering very little room for quote-denominated buying. Reading the account correctly is a mechanical exercise, covered step by step in reading a Solana liquidity pool.
The first hour on the new venue
The first hour after migration is the least representative hour in a token's trading life, and it is also the hour that generates the most screenshots. Three things are happening at once. Arbitrage is aligning the new pool with whatever price the curve last printed. Routers and aggregators are discovering the pool and beginning to include it in quotes. And a queue of participants who were waiting for the handover are all acting inside the same few minutes.
Each of those produces prints that look like market activity but describe plumbing. Arbitrage trades are corrective, not directional. Router inclusion changes where volume is recorded without changing how much trading occurs. And a compressed queue of orders against fresh reserves produces price movement that has more to do with depth than with demand. Slots on Solana target roughly 400 milliseconds, so a great deal of this resolves inside the first few minutes.
What makes the hour readable is that all of it is verifiable. The pool's opening reserves are a balance you can look up. The first swaps against it are a list you can enumerate. The signers of those swaps are addresses you can group. None of this requires special access; it requires knowing what to fetch before the chart has time to form an impression.
- Locate the migration signatureFind the transaction that created or funded the pool, note its slot, and treat that slot as the boundary between the two data series.
- Read the opening reservesRecord both sides as deposited, in raw units and in quote terms, because every depth claim for the next hour is derived from these two numbers.
- Trace the LP tokensIdentify the LP mint and the account that received the supply, then determine whether that account can sign a withdrawal.
- Confirm the curve is inertCheck that no new swaps are landing against the launchpad program, so you know the two series do not overlap in time.
- Enumerate the first swapsList the earliest fills against the new pool with sizes and signers, rather than reading the candle they collectively produced.
- Group the signers by funding sourceSeveral fresh addresses funded from one source in the same window are one participant for structural purposes, however many prints they generate.
- Recompute depth at your own sizeDo not accept a generic liquidity figure; compute what the reserves imply for the specific order you intend to place.
- Check which routers list the poolUntil aggregators include it, quoted prices and executed prices can diverge for reasons that have nothing to do with the token.
- Keep the two volume series separateRecord curve volume and pool volume as distinct lines from the migration slot onward, and never present their sum as a single market's activity.
Why depth resets, and what the new profile looks like
Depth resets because depth was never transferred. On the curve, the resistance to a buy came from the program's parameters. In the pool, the resistance comes from the reserves the migration deposited. Those are unrelated quantities. The new pool inherits the last price, approximately, but it does not inherit the shape of the cost curve that produced that price.
On a constant-product pool the invariant is x × y = k, where x and y are the two reserve balances. That produces a specific and useful result: for a buy of size X against a quote reserve x, the average execution price is the spot price multiplied by (x + X) / x. The premium you pay is simply your order size as a fraction of the quote reserve. Halve the reserve and you double the premium for the same order.
Many launchpad curves are implemented as the same constant-product function applied to virtual reserves — notional balances written into the program rather than deposited by anyone — which makes the two regimes directly comparable. If the virtual quote reserve was larger than the reserve the migration deposits, the identical order becomes more expensive the moment the token graduates, even though nothing about the token changed.
Illustrative arithmetic
The reserve figures below are invented to demonstrate a relationship between order size and depth. They measure nothing real, describe no particular launchpad or pool, and are not representative of any token. Only the ratios between the columns carry meaning. Swap fees are excluded so the depth effect is visible on its own.
Take a curve with a virtual quote reserve of 400 SOL against 800 million tokens, and a pool opened with 100 SOL against 200 million tokens. Both quote the same spot price, 0.5 SOL per million tokens, so a chart would show no gap at the handover. Their responses to an order are not the same, because the quote reserve differs by a factor of four.
| Buy size | Tokens out, curve | Tokens out, pool | Average price, curve | Average price, pool | Tokens lost |
|---|---|---|---|---|---|
| 10 SOL | 19.51 M | 18.18 M | 0.5125 | 0.5500 | 6.8% |
| 30 SOL | 55.81 M | 46.15 M | 0.5375 | 0.6500 | 17.3% |
| 60 SOL | 104.35 M | 75.00 M | 0.5750 | 0.8000 | 28.1% |
Read the last column rather than the price columns. At 10 SOL the difference is a rounding annoyance. At 60 SOL the same money buys 28 per cent fewer tokens on the new venue than it would have bought on the retired one. Nothing was sold, nothing was withdrawn, and no sentiment changed. The order simply met a shallower reserve, and the convexity of the invariant did the rest.
The other half of the reset is behavioural rather than arithmetic. A curve's depth is fixed by its parameters and cannot be removed. A pool's depth is a balance that liquidity providers can add to or withdraw from, and that arbitrage rebalances continuously as price moves. The new profile is therefore both shallower at the start and mutable, which is a genuinely different risk to hold. The cost consequences of shallow reserves are treated separately in the note on price impact on thin pairs.
How volume attribution splits
From the migration slot onward, a token has one live market and one retired one. Any window that spans the boundary contains activity from both. This is where most published figures go wrong, because the sum is arithmetically valid and analytically meaningless: it adds trades that could only have happened against one depth profile to trades that could only have happened against the other.
The split is clean if you use the migration slot as the divider. Everything before it is curve volume, attributed to the launchpad program. Everything after is pool volume, attributed to the AMM. There is no interleaving, because the curve refuses swaps once it is marked complete. The difficulty is not ambiguity; it is that most dashboards present a token-level total that hides which side of the divider each trade fell on. The venue classes involved, and why their shares cannot simply be added, are set out in where Solana volume comes from.
A second attribution question appears once routers include the pool. Before migration, curve trades were largely direct interactions with the launchpad interface. After migration, the token becomes routable, which means a single user action can produce pool-level executions in more than one place, and an aggregator will also record the user-facing trade. Volume can rise at the token level purely because the token became reachable by more paths. Anyone running execution through a handover inherits the same problem in reverse: a professional Solana volume bot has to know which side of the migration slot it is on, because the venue it should be quoting changes at that block and the reporting it produces has to be split there too.
The honest presentation is two labelled series with a marked boundary, not one line. If a single number is required, it should carry the window, the venue and the side of the boundary it describes. Anyone measuring activity across a handover should also fix their method before the event rather than after it, which is the discipline described in measuring a volume campaign.
What the chart shows during the handover, and why it misleads
Charts are built by indexers that read swap events from programs. During a migration the set of programs being read changes. A chart therefore has to switch sources mid-series, and the artefacts of that switch are routinely interpreted as market events by readers who have no reason to suspect a source change occurred.
Three artefacts recur. A gap, when the indexer stops reading the curve before it starts reading the pool, producing an interval with no candles that looks like a halt. A duplicate, when both sources are read for an overlapping period and the same minute appears twice with different values. And a spike, when the first thin trades against fresh reserves produce a wick far outside the preceding range on a handful of fills.
None of the three is a trade signal. All three are properties of the data pipeline meeting a discontinuity in the underlying market. The reliable test is to check whether the movement is present in the ledger at the same slot: pull the swaps in that interval and see whether the size and count justify the candle. A move produced by four fills against a shallow pool is a depth event, and it will usually retrace as soon as the reserves are rebalanced by arbitrage. Transaction-level records for any signature can be read directly on a public explorer such as Solscan.
The rolling window compounds all of this. A 24-hour figure taken shortly after migration is mostly curve activity, and it will keep looking that way for nearly a full day before falling sharply for purely arithmetic reasons. Readers watching that decline routinely describe it as interest fading. It is a window emptying.
What to watch and verify
The handover is one of the few moments in a token's life where the entire state change is contained in a small set of transactions. That makes it unusually verifiable, provided you know which phase you are looking at. The table below maps each phase to what changes on chain, what a chart tends to display, and the specific artefact to fetch instead of trusting the display.
| Phase | What changes on chain | What a price chart shows | What to verify yourself |
|---|---|---|---|
| Late curve | Swaps still price against the curve program; its quote balance grows with net buying | A steepening line with no venue change | The curve account's current balances and the program that owns them |
| Completion | The program marks itself complete and refuses further swaps | Usually nothing; the last curve print simply holds | The transaction that flipped the state, and its slot |
| Migration transaction | A pool is created or funded, both sides are deposited, LP tokens are minted | A gap, or a minute that appears twice | The signature, the pool address, both opening reserves, the LP mint and its recipient |
| First blocks on the pool | The earliest swaps hit the new reserves; fees begin accruing to LP holders | A large candle in either direction on very few fills | The first swaps by size and signer, and whether the reserves moved as much as the candle implies |
| First hour | Arbitrage aligns the pool; routers begin including it in quotes | One volume bar blending two venues | Whether the quote reserve is growing, flat or draining |
| Steady state | The curve is inert; all new volume is pool volume; LP composition tracks price | A single continuous series | Depth at your intended order size, recomputed from current reserves |
The underlying discipline is small. Treat the migration slot as a hard boundary. Derive depth from reserves rather than from any published liquidity figure. Read the LP token destination before forming any view on permanence. Token accounts and mints behave the same way here as anywhere else on the chain, and the account model that makes all of this legible is documented in the Solana token documentation.
Graduation is worth watching precisely because it is one of the few events where the record is complete and immediate. The chart will be ambiguous for an hour. The ledger will not be ambiguous at any point.
Follow-up questions on the handover
What does liquidity migration mean on Solana?
It means a token stops being priced by a launchpad bonding curve and starts being priced by an automated market maker pool. A migration transaction creates or funds that pool, deposits both sides of the pair, and mints LP tokens. From that point the price comes from the pool reserves rather than from the curve program.
Does migration make a token more liquid?
Not automatically. Migration changes who supplies depth and how depth can change, but the opening reserves of the new pool are whatever the migration deposited. If those reserves are smaller than what the token was trading against before, an identical order will move price further after migration than it would have before it.
Why does the price gap at the moment of migration?
Two separate things happen. The pricing function changes, so the same nominal price sits on a different cost curve. And the data source changes, so an indexer stops reading curve swaps and starts reading pool swaps. A gap or a duplicated candle is usually the second effect, and no trade produced it.
Can the retired curve still record volume?
Trades executed against the curve before it closed stay in the record permanently, and any rolling window still covering them keeps including them. What the curve cannot do is record new swaps once the program has marked itself complete. The two series therefore overlap inside a window without ever overlapping in time.
What should I check first after a migration?
The migration signature, the new pool address, both opening reserves, and where the LP tokens went. Those four facts determine what the pool can absorb and who is able to remove it. Everything else, including the first candles and the first volume bar, is downstream of them.
Why does 24-hour volume look inflated right after migration?
A rolling window spanning the handover holds the final hours of curve activity plus the opening hours of pool activity. That total describes two different markets summed together. It is arithmetically correct and analytically misleading, because neither market on its own was capable of absorbing the combined figure.
Filed under Liquidity and depth. Corrections and method questions go to the desk; our sourcing rules are on the editorial policy page.