The handover is one transaction, or a small number of them, and almost everything people believe about it is inferred from what a screener displayed afterwards rather than from what the instruction actually did. This phase covers the event: the completion condition, the routine that runs, the accounts it creates, and the state it leaves behind.
Nothing in this section states a threshold, a fee or a duration as a fixed number. Those are operator-controlled parameters that have been revised before and can be revised again, so the desk names what each parameter governs and points you at the protocol for its current value.
A migration routine is not magic; it is a sequence of ordinary account operations that anyone can read back afterwards. These are the jobs it has to complete for a token to be tradeable on the destination venue.
The curve must stop accepting trades before its reserves are moved, or the same asset could be traded in two places at once. In practice the curve account is marked complete and further buys against it are rejected by the program.
A pool needs its own address plus token accounts to hold each side of the pair. These are created during migration, which is why the pool address does not exist and cannot be looked up until the routine has run.
The quote asset accumulated by the curve and the token allocation reserved for the pool are transferred into the new accounts. This deposit is what sets the opening ratio, and therefore the opening price.
Depositing into an AMM mints liquidity provider tokens. Migration routines commonly burn or lock them so nobody can pull the seeded liquidity back out. What happened is visible on the transaction; it should be read there, not assumed.
The result is a signature, a slot and a set of account balances. Everything anyone later claims about the migration can be checked against that record, which is the only reason a desk like this one can write about it at all.
The migration event itself. What the launchpad program does when a curve completes, what it hands to the destination venue, and the ways the sequence can stall or land somewhere nobody was watching.
The full sequence from a bonding curve reaching its completion condition to a live pool accepting swaps, described as program behaviour rather than as a number that changes whenever the launchpad decides it should.
Open the noteAn inventory of what changes hands at migration and what does not. The mint stays. The reserves move. The pricing rule is replaced outright, and half the things people expect to migrate never do.
Open the noteMigration is a transaction, and transactions fail. Stalled routines, pools that exist but are not indexed, front ends holding a dead route, and the impostor pair that shares a ticker with nothing else.
Open the noteThe handover only makes sense with the states around it. Before covers the curve phase and what can be settled while it lasts; After covers the pool, the routing and the chart that has to be read across two mechanisms.
The state a token is in while it still trades on a bonding curve, what can be prepared while that state lasts, and how to watch a curve approach its completion condition without guessing.
Open this phaseThe state a token is in once a pool exists. New account, new pricing rule, new fee path, new routing dependencies, and a chart that has to be stitched across two different mechanisms.
Open this phase