Trading through liquidity migration
A token can keep the same mint while its market moves from a bonding curve to a new pool. Token continuity does not make the old route, quote, fee model, or liquidity state continuous.
The short answer
Treat migration as a state machine, not a celebration banner. On Pump.fun, the bonding curve first becomes complete. A separate onchain migration instruction then creates the canonical PumpSwap market from the completed curve's liquidity. Finally, routers and interfaces must discover and quote the new pool.
Pump.fun describes graduation as automatic and irreversible. At the program level, its public documentation says any user can call the permissionless, idempotent migrate instruction after the curve is complete. Those descriptions fit together operationally, but they expose distinct evidence: curve completion, successful migration, pool creation, and route availability.
The four execution states
Curve active
The bonding curve is incomplete and holds real tokens available for buys. Trades use the curve's accounts, formula, and fee path.
Curve complete
The program has marked the curve complete after its real token reserves reach zero. The old market is no longer an ordinary open curve even if an interface has not updated.
Migration confirmed
A successful migrate instruction creates the canonical PumpSwap pool, moves the designated liquidity, and establishes the destination market.
Route available
The pool exists, but a terminal, indexer, or aggregator may need to observe and index it before returning a reliable new quote.
What Pump.fun's program makes observable
Pump.fun's public program reference defines a completed curve as complete == true with no real token reserves remaining. Its current migrate(user, mint) instruction is permissionless, so the caller does not need to be the token creator. It is also idempotent: calling it again after a completed curve has already migrated produces no second market transition.
The migration sends the curve's designated liquidity into PumpSwap and the resulting LP tokens are burned according to the program documentation. That is what distinguishes the canonical graduated pool from a manually created PumpSwap pool for the same mint.
Read Pump.fun and PumpSwap: a deep dive for the wider curve, pool, and fee model. This guide stays focused on what a trader should do during the handoff.
The token continues; the executable price is rebuilt
The mint address and wallet inventory do not change merely because the venue changes. But the pool uses a different execution model and reserve state than the live curve did. Pool fees, LP accounting, routing, price impact, and the source of the quote all change.
Migrated reserves help initialize the new market, but they do not freeze the last curve price as a guaranteed first fill. The migration transaction and earliest PumpSwap trades can change state before your transaction lands. Compare the new quote at your actual size and set a new minimum output.
Old curve transactions become stale instructions
A prebuilt curve trade names curve-specific accounts and program instructions. After completion, refreshing only the token's displayed price does not turn that payload into a PumpSwap trade. The destination venue requires its own pool accounts, swap instruction, quote, and protection threshold.
If the old transaction fails, do not widen slippage and resend it blindly. Check the curve state, confirm the migration transaction, identify the canonical pool, and request a route built for the new venue. The quote-to-fill lifecycle explains why a signed payload cannot follow the market automatically.
Confirm the canonical pool, not just any pool
Anyone can create markets for SPL tokens. A PumpSwap pool can therefore exist without being produced by Pump.fun's migration instruction. A matching mint is necessary to identify the token, but the pool-creation trail identifies whether the liquidity came from protocol graduation.
Trace the completion
Confirm the bonding curve account changed to complete and its real token reserves reached zero.
Trace the migrate instruction
Find the successful Pump.fun program transaction for the same mint and inspect the destination accounts it created or funded.
Verify pool identity
Use the pool address produced by that transaction, not a ticker search or the first pool shown by a third-party interface.
Check the current route
Confirm the aggregator's route actually touches the canonical pool—or understand why another venue now produces a better executable result.
Not every chain has Pump.fun's migration rule
Robinhood Chain and other EVM networks do not impose one universal graduation lifecycle on ERC-20 tokens. A launch contract may create a pool, move liquidity, replace a market, or issue a new token according to its own code. “Migration” can therefore mean the same contract moving venues or an entirely new contract requiring a conversion.
Before applying this Pump.fun workflow elsewhere, identify which contract defines the transition, whether the token address stays the same, who can trigger it, what happens to old liquidity, and whether holders must sign a claim, approval, bridge, or swap.
The migration trading checklist
- Stop relying on the last curve quote once completion is visible.
- Confirm the migration transaction succeeded for the exact mint.
- Identify the canonical destination pool from onchain creation evidence.
- Wait for a fresh executable route and inspect its actual pool path.
- Recalculate impact, fees, minimum output, and exit capacity under the new AMM.
- Record curve trades and pool trades as different execution phases in the same token position.
Primary sources
Reconstruct the handoff
Separate curve fills from pool fills.
Paste a public Solana address to inspect migration timing, trade venues, fees, and remaining inventory without connecting a wallet.
Open Solana preflight