How Bonding Curve Token Graduation Works

A LaunchLab launch starts in Funding status. Its PoolState records the base mint, quote mint, virtual reserves, real base sold, real quote collected, migration type, fee counters, and the target quote amount. Buys move base tokens from the program-controlled base vault to buyers and add net quote to curve accounting. Sells reverse part of that state. The mint supply is already present in the base vault, so ordinary curve purchases transfer tokens rather than minting new supply for each buyer.

When the fundraising condition is met, status advances to Migrate and the appropriate migration instruction can execute. Raydium documents the status progression as Funding, Migrate, then Migrated. The transition is monotonic. A migrated launch cannot return to curve trading even if the destination pool later trades below its opening price. This distinction matters because a threshold reached state can still be waiting for the migration transaction, while a Migrated state indicates that the destination pool was created.

The migration instruction uses the remaining base allocation and the net quote reserve to initialize the destination. For CPMM, those assets become the two vault balances that define the opening reserve ratio. The curve configuration is designed so its terminal marginal price aligns with that reserve ratio, although integer rounding, fees, and a buy that crosses the target can affect exact amounts. Once live, the CPMM follows the constant-product invariant, and each swap changes the reserve ratio.

Migration also handles authorities and liquidity ownership. LaunchLab documentation states that mint authority is revoked at migration and that the post-migration LP position is split according to platform configuration. Raydium's own platform can use Burn & Earn for a locked portion and issue a Fee Key for a fee-bearing portion. A third-party platform may use different settings, so a platform label is not enough to infer the split.

Start with the token mint address, not its name or symbol. Locate the LaunchLab PoolState and confirm that its base_mint equals that address. Check the quote mint, creator, platform configuration, migrate_type, target, real quote, and status. On mainnet, the account owner should be the canonical LaunchLab program. Then inspect the migration signature and confirm that it invokes LaunchLab and the expected destination program, normally Raydium CPMM for current standard launches.

Next, derive or inspect the resulting CPMM PoolState. Confirm that its token mints are exactly the launch base and quote mints, allowing for canonical mint ordering. Inspect both token vaults, the LP mint, AmmConfig, observation account, and pool creation transaction. Finally, read the mint account and confirm the current mint authority and freeze authority. Save addresses and signatures in a verification note so another reader can reproduce the result without relying on a mutable web page.

• Match mint, PoolState, vault, destination pool, and transaction addresses.
• Confirm status is Migrated rather than only Migrate.
• Check program owners against Raydium's current program-address registry.
• Use finalized RPC data and repeat the read through a second endpoint when accuracy matters.

Explorer decoding can lag a program upgrade, APIs can cache status, and a similarly named pool can exist for a counterfeit mint. Raw vault balances may also include accrued fee buckets that are excluded from curve accounting. Prefer decoded on-chain accounts, transaction instructions, and canonical program IDs over screenshots or search results. For automation, pin the IDL version and surface a decoding failure instead of guessing field offsets.

A valid graduation confirms that the specified program transition occurred. It does not show that the pool has deep reserves, that LP rights are locked in a particular proportion, or that token authorities beyond minting are harmless. Treat graduation as one verifiable fact within a wider token review, not as a quality score or a forecast.