Where launchpad liquidity ends up after graduation

When a Solana launch graduates, the accumulated reserve is deposited into one pool on one program, and the venue chose which. Four destination types are in use: a launchpad-native automated market maker, a general-purpose one, a concentrated design, and hybrids that combine them. The choice sets the depth, the routing behaviour and the fee treatment a token wakes up with.

The destination is a product decision

There is nothing technically necessary about any particular destination. A migration routine is a program instruction that creates a pool and deposits into it, and the program it calls is whatever the venue wrote into the instruction. Venues have written different ones, and several have changed the one they write.

Understanding the destination as a decision rather than as physics changes how it should be evaluated. A venue that deposits into its own AMM keeps the fee stream and the relationship. A venue that deposits into an established third-party AMM buys immediate routing and integration for its tokens. Both are reasonable business choices and they produce different experiences for a graduated token.

It also explains why the destination changes. When the calculation shifts - because the venue builds its own AMM, or because a partner's terms change - the parameter is edited and future graduations land somewhere else. Tokens already graduated stay where they were sent, which is how a single venue ends up with tokens spread across several destinations.

The four destination types

General-purpose destinations are the easiest case to reason about because their behaviour is documented and stable; the pool programs and their fee tiers are set out by operators such as Raydium. Native destinations are the case where a venue's incentives and a token's interests can quietly diverge, and the divergence shows up as routing lag rather than as anything dramatic.

What the destination does to depth

Depth is how far an order moves the price, and it is the property a freshly graduated token is most immediately judged on. Two pools seeded with identical assets can have wildly different depth at the current price if one of them concentrates its liquidity into a range.

On a constant product pool the relationship is simple and unforgiving: the reserves are spread across every possible price, so the depth near the current price is a small fraction of the total value deposited. A large order eats into it quickly, and the price impact of a given order size is computable directly from the reserves.

This is why the migration deduction described elsewhere in this ledger matters more than its size suggests. A retention of a few per cent of the reserve is a few per cent less depth at every price forever, and depth compounds into everything a token is judged on afterwards: the price impact of an ordinary purchase, the spread a router quotes, and whether a moderately sized order looks like a market event or like a routine trade.

On a concentrated design the same deposit placed into a narrow band around the opening price produces far more depth where trading actually happens, and none at all outside the band. That is excellent while price stays in range and abrupt when it does not. For a token whose first hour is unpredictable by construction, the range choice is a genuine risk decision and it is made by whoever seeded the pool.

Burned, locked or simply held

Depositing into an automated market maker mints a position representing a claim on the reserves. The migration routine produces one, and what it does with it is the single most consequential thing to verify about any graduation.

• Burned. The position is destroyed, so no account can withdraw the underlying reserves. The liquidity is permanently committed and this is verifiable from the chain without trusting anyone's statement.
• Locked. The position is transferred into a program that will not release it until a condition or a date. Verifiable, but only as strong as the locking program and the terms written into it.
• Held. The position sits in an ordinary account. Whoever controls that account can withdraw the reserves at any time. Sometimes this is deliberate and disclosed; sometimes nobody checked.
• Split. Part burned, part retained. Common enough to be worth checking for specifically rather than assuming the answer is uniform.

All four are ordinary outcomes and all four are readable. A claim about liquidity that has not been checked against the position is not a fact about the token; it is a report of something somebody said.

Routing and who indexes what

A pool being live and a pool being routable are different states, and the gap between them is where a great deal of post-graduation confusion lives. Routers build a graph of pools they know about and quote paths through it; a pool they have not indexed is simply not in the graph.

Indexing depends on the program. A destination on a widely integrated program is normally picked up promptly, because the router already watches that program for new pools. A destination on a newer or narrower program may require explicit support, and until that support exists the token is tradeable by anyone who addresses the pool directly and invisible to everyone using an aggregator interface.

The behaviour of routers is documented by the router operators themselves; the interfaces and coverage model are described in the Jupiter developer documentation. The practical point for a launching team is that the destination decision is also a decision about how quickly the token becomes visible to the majority of Solana traders, who reach markets through routers rather than through pool addresses.

Same deposit, two pool designs

Second pools and permissionless creation

Pool creation on Solana is permissionless. Once a mint exists anybody can create a pool for it on any AMM by depositing both sides, which means the venue's chosen destination is the first pool rather than the only one.

For a token that attracts attention this happens routinely, and it is usually benign: arbitrage keeps prices across the pools roughly aligned, and additional venues improve routing. It is also the mechanism behind a specific hazard, because a pool for a different mint with the same name and symbol is equally easy to create and equally indistinguishable on a screener row.

The defensive habit is to verify by mint rather than by name. Teams that produce activity across several venues run into the same requirement from the other direction, because a Raydium volume bot pointed at a pool address rather than at a verified mint will keep working perfectly on a pool that has nothing to do with the token it was bought for.

Fee accrual after the handover

The destination charges its own fee per swap, and that fee belongs to the AMM rather than to the launchpad. It is normally split between liquidity providers and a protocol share, in proportions the AMM sets.

This produces a question teams rarely ask before graduation: who receives the provider share of fees on the migrated liquidity? If the position was burned, the fees accrue to a position nobody can claim, and the treatment depends on the AMM design - on some, fees accumulate into the reserves and effectively benefit remaining providers; on others they are stranded. If the position was locked, the terms of the lock decide. If it was retained, whoever holds it collects.

None of this is hidden and almost none of it is prominent. It is a consequence of two independent design choices - the AMM's fee model and the venue's position handling - meeting at migration, and it is worth an explicit answer before a team makes any public claim about what happens to trading fees.

Verifying where a token actually landed

1. Find the migration transaction by walking the mint's recent history in Solana Explorer to the point where the curve was marked complete.
2. Read which program created the pool. The invoked program id is the destination and is the fact everything else depends on.
3. Record the pool address as it appears in the transaction, in full, and store it somewhere your team can paste from.
4. Confirm the pool holds your mint by opening its token accounts and comparing addresses character for character rather than matching a ticker.
5. Read the deposit amounts and compare them with the curve reserve immediately before migration; the difference is whatever the venue retained.
6. Trace the provider position to a burn, a lock program or a holding account, and write down which of the three it was.
7. Request a router quote for the mint and check whether the route passes through the pool you just verified. If it does not, the destination is not indexed yet and that is a timing problem rather than a mistake.

Destinations get changed

The destination is a parameter, and parameters get edited. A venue that built its own AMM has a strong reason to send future graduations there instead of to a third party, and at least one widely used venue has changed its destination during its operating life.

The consequence for anyone maintaining tooling is that a venue cannot be characterised once. Two tokens from the same launchpad, graduated months apart, can sit on entirely different programs with different account layouts and different fee models. Any integration written against the assumption of a single destination per venue will break silently the first time the parameter changes, which is a strong argument for keying against verified mints and reading destinations per token rather than per launchpad. That reasoning is followed through in the note on what changes if you switch.

What the destination does not decide

It does not decide whether the token trades. Depth is a property of the pool; participation is a property of the world, and a deep pool with nobody in it is a common and entirely ordinary outcome.

It does not decide the price. The opening price is the ratio of what was deposited, and everything after that is decided by whoever turns up. A generous destination and a thin one both start wherever the deposit put them.

It does not decide whether liquidity is safe. That is the provider position question, which is independent of destination type. A burned position on an obscure program is more provably committed than a retained position on a famous one, and only one of those two facts is visible on a screenshot.

Questions this desk is asked