Trading Around a Solana Token Migration: The Handover

At migration the pricing engine is replaced. A bonding curve prices from a formula whose only state is how much has been bought; an automated market maker pool prices from two reserve balances that anyone can add to or withdraw from. The mint stays the same, so charts and wallets carry on as though nothing happened, while the cost of trading the pair has been rebuilt from scratch.

What actually changes at migration

Four things change simultaneously, and confusing them is the source of most migration mistakes. The pricing formula changes. The identity of the liquidity providers changes, from nobody to whoever holds pool positions. The fee model changes, because curve fees and pool fees are set separately. And the venue changes, which means the set of routers and interfaces that can reach the pair changes with it.

What does not change is the token itself. The mint address, the decimals and the holder distribution carry straight through. That continuity is exactly what makes the event confusing: every surface a trader looks at implies the market is continuous, while the mechanism producing prices has been swapped out underneath.

The useful mental model is a relocation rather than an upgrade. The same participants and the same supply arrive in a differently shaped room. Orders that were cheap in the old room may be expensive in the new one, and the depth that made your position sensible was a property of the room you have just left.

The handover, step by step

The specifics differ by launch venue and are published by each of them, but the shape of the sequence is consistent enough to be worth writing out. Treat this as the structure to verify against the venue's own documentation rather than as a substitute for it.

The curve accumulates. Buyers pay into the curve, the formula raises the quoted price as supply is issued, and the value collected accrues against a published threshold.
The threshold is reached. The condition for graduation is met. This is arithmetic on public state, so the distance to it is knowable, while the timing is not, because other traders close the distance.
Curve trading stops. The curve stops quoting. There is typically a brief window where the pair is between markets, and interfaces that read only one venue can show stale or missing prices during it.
A pool is created or seeded. The accumulated reserves, less whatever the venue's rules allocate elsewhere, are used to create a pool on an automated market maker, generally at or near the curve completion price.
The liquidity position is handled. Depending on the venue's rules the position representing that liquidity may be burned, locked, or held by an account. Which of the three it is decides whether the pool can be drained by its owner, and it is checkable.
Routers pick the pair up. Aggregators discover the new pool and begin including it in routes. Until they do, the pair is only reachable directly, which shows up as poor prices on interfaces that route rather than trade a pool directly.
Providers arrive or do not. Third parties may add liquidity to the new pool, deepening it, or may not, leaving it exactly as seeded. This is the single largest determinant of what the pair costs to trade a day later.

Step seven is the one traders under-weight. A migration produces a pool of a known size at a known moment, and everything about the pair's tradability afterwards depends on whether anyone else chooses to add depth to it. Nothing in the migration mechanism guarantees that they will.

Three windows, three different markets

The three windows around a Solana curve migration, compared by what prices the pair, what the main structural risk is, and what a trader can verify in each.
Window	What prices the pair	Depth characteristics	Main structural risk	Verifiable at the time
Pre-migration	The curve formula, driven only by cumulative purchases	Deterministic; the cost of a given order is a function of curve state	The threshold is closed by others, so your exit timing is not yours to choose	Curve state, distance to threshold, holder concentration
Handover	Briefly nothing, then the newly seeded pool	Undefined during the transfer, then whatever the seed produced	Interfaces disagree; a stale quote is not an opportunity	Whether the pool exists yet and which program owns it
Post-migration	Pool reserves under the pool's own invariant	Set by the seed, then changed by every provider action afterwards	Depth may never grow beyond the seed, and can shrink	Reserves, fee tier, liquidity position ownership, router coverage

Reading the table by row gives you three separate trades, which is the point. A position opened on the curve and held into the pool has changed its risk profile without any decision being taken, and a risk profile that changed without a decision is the definition of an unmanaged position.

The pre-migration window

On the curve, cost is deterministic. The formula is published, the state is public, and the price your order receives is a function of how much has been bought before it. That determinism is genuinely useful: it is one of the few places in this market where you can compute your cost precisely before signing.

The risk is not pricing, it is timing. Your exit depends on there being buyers on the curve, and the approach to the threshold is closed by other people at a pace you do not control. A position taken with an assumption about when graduation will happen is a position with a hidden dependency on strangers.

Curve state is also where produced activity shows up most legibly, because the curve has no liquidity providers to confuse the picture: every transaction is a buy or a sell against the formula. That legibility is why the curve stage is often where activity is generated deliberately, and why reading signer counts on a curve is more informative than reading them on a pool.

The post-migration window

After the handover, the pair is an ordinary thin pool and should be treated as one. The first job is to identify which venue received the liquidity, because that decides everything about how orders will be priced. A constant-product pool always quotes and degrades smoothly; a concentrated design can be far better near price and much worse once ranges are left behind. Raydium's documentation and Meteora's documentation set out the parameters of the designs most commonly involved.

The second job is to check the size of the pool against your intended position, because the migration seed is frequently smaller than the turnover figures around the event suggest. A pair can show large migration-day turnover while sitting on a pool that makes any meaningful position expensive to exit. That is not a contradiction; turnover and depth are different quantities and they routinely diverge.

Illustrative arithmetic: the seed decides your size, not the turnover

Invented round numbers, describing no real pair. A curve completes and seeds a constant-product pool with 70 SOL on the quote side. On the same day the pair reports 900 SOL of turnover, which looks like a busy market and is often read as one.

Now size a position against it. If your rule is that a full exit must not move the quoted price by more than two percent, the arithmetic on a constant-product pool puts your maximum at roughly two percent of the reserve you would be selling into, so around 1.4 SOL of position value. The turnover figure was thirteen times the size of the pool and changed that number not at all, because turnover measures how often the pool was used, while depth measures what it can absorb in one order.

If providers later add liquidity and the quote-side reserve reaches 210 SOL, the same two percent rule permits roughly 4.2 SOL. Nothing about the token changed. The tradable size tripled because somebody else committed capital, which is the variable that actually governs a post-migration pair.

The third job is to check router coverage. Until aggregators index the new pool, orders sent through routing interfaces may take poor paths or fail to find the pair at all. The public routing documentation, for example the Jupiter developer documentation, describes how venue discovery works, and the practical consequence is simple: early post-migration, a direct swap against the pool and a routed swap can differ meaningfully.

Post-migration pools are also where produced flow reappears in a different form, since a pair that has just moved to an automated market maker needs to be visible on venue screens to attract organic participants. A Raydium volume bot is the tool class used for exactly that stage, and reading its signature matters for the same reason as always: activity that arrives without depth does not make the pair cheaper to exit.

The migration rule set

Rule one: two trades, not one

A curve position and a pool position are separate trades with separate sizes and separate invalidations. Carrying one into the other requires an explicit decision, recorded before the handover. Cost: extra exit and re-entry costs on pairs that would have been fine held through. Failure case: the handover is fast enough that re-entry happens at a materially worse price.

Rule two: identify the destination before it matters

Which venue receives the liquidity, and how large the seed will be, are knowable in advance from the launch venue's published rules. Establish both before the threshold is near. Cost: research time spent on pairs that never graduate. Failure case: the venue changes its rules, or the pair is routed to a destination the rules did not describe.

Rule three: re-derive size from the new pool

The moment the pool exists, recompute your maximum position from its reserves and hold the smaller of that number and your existing position. Cost: forced partial exits on pairs where the seed was small. Failure case: the pool deepens quickly and the reduction was unnecessary, which you will only know afterwards.

Four recurring mistakes

The first is assuming continuity. The chart is continuous, the mint is continuous, and traders infer that the market is. Cost of the assumption: a position sized for one liquidity structure is carried into another without recalculation.

The second is trading the handover window itself. Prices during the transfer are unreliable and interfaces disagree, so apparent opportunities in that window are usually stale data rather than real dislocation. Acting on a quote that no venue will honour is not arbitrage.

The third is treating migration as an achievement. Graduation means a threshold was met, which is a statement about how much was bought, not about durability, distribution or team behaviour. It removes exactly one uncertainty, and the pair afterwards is a thin pool like any other.

The fourth is ignoring who holds the liquidity position. If the position representing pool liquidity is held by an account able to withdraw it, the depth you are relying on is one transaction away from disappearing. This is checkable and takes a minute, and a Solana volume bot platform or any other activity tool cannot compensate for a pool whose liquidity is not committed.

Where these rules fail

They fail when the launch venue's mechanics differ from the general pattern described here. Venues change graduation rules, destinations and liquidity handling, and the only reliable source is the venue's own current documentation. Anything written generally, including this page, ages.

They fail when the pool deepens fast. Rule three forces a size reduction on the seed figure, and on pairs where providers arrive immediately the reduction is unnecessary. This is a real and recurring cost of the rule, not a hypothetical one.

They fail when a trader uses the framework to justify staying in a losing position: the trade was reclassified, the size was re-derived, the paperwork was done, and the position is held anyway because it is underwater. Process can be performed rather than followed, and the journal is the only place that distinction becomes visible.

The related reading is the exits note, because the practical form of rule three is a scale-out decision made against the new pool's depth rather than against your entry price. Nothing about a migration changes the arithmetic of getting out of a thin market; it only changes which pool that arithmetic is computed against.

Questions the desk gets asked

What is a token migration on Solana?

It is the moment a bonding curve launch completes and the value accumulated in the curve is used to create or seed a liquidity pool on an automated market maker. The token stops being priced by the curve formula and starts being priced by pool reserves. The mint does not change, so wallets and charts continue to reference the same token while the market underneath it is replaced.

Does price gap at migration?

The pool is typically seeded at or near the curve completion price, so there is no mechanical reason for a gap at the moment of transfer. What changes immediately is the shape of the cost curve around that price, because a pool of a given size and a curve at completion do not respond to the same order in the same way. Any move that follows comes from trading, not from the transfer itself.

Is liquidity locked after a migration?

It depends entirely on the launch venue and its rules, and it is a fact to be checked rather than assumed. Some models burn or lock the liquidity position created at graduation; others do not. The relevant question is who holds the position that represents the pool liquidity and what they are able to do with it, and that is readable on chain.

Should you hold a position through a migration?

That is a choice with a clear trade-off rather than a question with a correct answer. Holding through means carrying a position across a change in the pricing mechanism you cannot control the timing of. Closing before means paying an exit cost and possibly re-entering higher. This desk treats the two sides as separate trades so that each has its own size and its own invalidation.

Why does the destination venue matter?

Because pool design decides how your order is priced. A constant-product pool spreads liquidity across all prices and always quotes something. A concentrated design can be far deeper near the current price and effectively absent once price leaves the active ranges. The same nominal amount of migrated liquidity produces different execution depending on which design received it.

How do you know a migration is close?

On curve models the threshold is a published parameter and the progress toward it is a matter of arithmetic on public state rather than speculation. What is not knowable is the timing, because the remaining distance is closed by other people buying. Treat the threshold as a scheduled event with an unknown clock.

Does turnover mean anything different after migration?

Yes. Curve turnover passes through a formula with no external liquidity providers, while pool turnover passes through reserves that providers can add to or withdraw. After migration the turnover figure should always be read against pooled depth, because the same headline number implies a very different market depending on the size of the pool it moved through.