PumpSwap Explained: Where A Graduated Token Lands

A graduated token lands wherever its launchpad currently routes graduations. That destination is a configuration set by the launchpad operator, it has been changed across the ecosystem more than once, and for any specific token the authoritative answer is the migration transaction rather than any article. What the venue changes for a holder is the fee model, the routing situation and the pool design; what it does not change is the token.

The destination is a setting

For a long stretch, launchpad graduations on Solana meant migrating into a pool on an established third-party automated market maker, and that pattern became so routine that people described it as though it were part of the definition of graduating. It was never part of the definition. It was a routing choice encoded in a program.

Once a launchpad reaches meaningful volume, building its own automated market maker becomes attractive for obvious reasons: fee capture stays in-house, the migration path shortens, and the operator controls the whole lifecycle instead of handing it off. Pump.fun did exactly this with PumpSwap, and graduating tokens began landing on infrastructure operated by the same team rather than on a third party.

The lesson is not about any particular venue. It is that the destination is the kind of fact that expires. Guides written before a change keep circulating afterwards, still confidently naming a venue that is no longer the destination, and readers cannot tell from the page which era it belongs to. Verify the destination against the launchpad or against a recent migration transaction, every time it matters.

What a launchpad-native AMM is

A launchpad-native automated market maker is an AMM operated by the same team that operates the launchpad, built to receive graduations from it. Underneath it is the same category of machine as any other AMM: pools hold reserves, a pricing invariant relates them, swaps move the ratio, and liquidity providers earn a share of the fee.

The integration is where the difference lives. When one operator controls both sides of the handover, the migration path is shorter and there are fewer moving pieces that can disagree with each other. Account creation, deposit and LP disposal can be composed into a tighter sequence. The launchpad's own board can display the post-graduation pool without waiting to be told about it by a third party.

The trade-off is ecosystem depth. A venue that has existed for years is integrated into wallets, aggregators, charting sites, bots and analytics stacks that were written against it. A newer venue has to be adopted by all of those independently, and adoption is not instantaneous. Most of it arrives quickly for a venue with real volume, but not on the day it launches, and the gap is exactly where routing problems live.

What a general-purpose AMM brings

A general-purpose AMM hosts pools for anything, not only graduating launchpad tokens. Raydium is the long-standing example in this ecosystem, and its published documentation describes pool creation as something any participant can do. Its integrations predate any particular launchpad, and its pool addresses are recognised by essentially everything that indexes Solana trading.

The practical advantage is coverage. A pool on a widely integrated venue is likely to be indexed by aggregators, wallets and charting sites quickly, because those systems already watch that program for new pools. That is not a claim about quality; it is a claim about plumbing, and plumbing is what decides whether a token is routable in its first hour.

The practical disadvantage from the launchpad's point of view is that the value of the handover accrues partly to a third party. That tension is what produced the shift toward native venues in the first place, and it is why anyone reasoning about where graduations go should think in terms of operator incentives rather than tradition.

For teams that maintain deliberate market activity across a launch, the difference shows up as a configuration problem rather than a philosophical one. A campaign built around a specific AMM has to be re-pointed when the destination changes, which is the practical case a Raydium volume bot covers well and a single-venue script does not.

Differences that reach a holder

Read that table and the honest summary is that venue choice is a plumbing decision with real consequences and no moral dimension. Neither column contains a claim that a token performs better. It cannot, because a venue is a place to trade and not a reason for anybody to trade.

Routing decides more than the venue does

Once a mint has pools on more than one venue, the question stops being where the token trades and becomes which pool a given swap uses. That is decided by an aggregator, on a per-request basis, from its own index of pools and its own view of depth. Two people swapping the same token in the same minute can take different paths if their sizes differ.

This has a consequence people find counterintuitive: the pool a team watches is not necessarily the pool most volume goes through. A second pool opened by somebody else on another venue can attract routing if it is deeper, and a dashboard pointed at the original pool will show a market that looks quieter than it is.

The correct habit is to query an aggregator for a quote and read the route it returns, rather than inferring the route from where you believe the token trades. Routing interfaces are documented for exactly this purpose, and the Jupiter developer documentation is the usual reference on Solana. The quote is the aggregator telling you what it will actually do, which is strictly better information than any assumption about venue.

The same reasoning applies to anything that trades programmatically rather than analytically. Teams evaluating a volume bot on Solana DEXs tend to ask which venues it supports; the sharper question is whether it routes per swap or hard-codes one pool, because a hard-coded pool is a configuration that expires the first time the routing landscape changes.

Comparing fee models honestly

A swap costs three separable things and conflating them produces most bad venue comparisons.

• The swap fee. Charged by the AMM program, typically split between liquidity providers and a protocol treasury. It is a parameter of the venue and often of the specific pool, and it is not the same across all pools on one venue.
• Price impact. Not a fee at all. It is the mechanical consequence of moving the reserve ratio, and it is a property of the pool's depth relative to your order size. A deep pool on an expensive venue can be cheaper overall than a thin pool on a cheap one.
• Network cost. Base transaction fees plus whatever priority fee is needed to land in the block you want. This layer is described in the Solana documentation, it is identical across venues, and it is set by network conditions rather than by anybody's pricing decision.

This desk does not print fee percentages for any venue, because they are operator-set parameters that change and because pool-level variation makes any single figure misleading even on the day it is written. Read the venue's own documentation, and read the specific pool's configuration if you need precision.

Illustrative arithmetic on fee drag

Constant product and concentrated liquidity

Most graduation destinations are constant-product pools, where the product of the two reserves is held fixed across a swap. It is the simplest design, it needs no active management, and its behaviour is easy to reason about, which is why it is a sensible target for an automated handover.

Concentrated-liquidity designs let providers place their capital within a chosen price range instead of spreading it across every possible price. Within that range the pool behaves as though it were far deeper. Outside it, the provider's capital contributes nothing to the trade.

For a freshly graduated token this matters because depth can be much less uniform than a single number suggests. A pool can look adequately deep and still deliver poor fills if the price moves out of the range where most liquidity was placed. When a chart and a fill disagree sharply, this is one of the first explanations to check.

Determining the venue for one token

The reliable method takes a few minutes and does not depend on trusting anybody's summary, including this one.

1. Start from the mint address. It is the only stable identifier the token has, and everything else is derived from it.
2. Find the migration transaction, either from the launchpad's own interface or by walking the mint's transaction history to the point where the curve was marked complete.
3. Open that transaction and read which program was invoked to create the pool. That program identifies the venue, without any inference.
4. Record the pool account address created in the same transaction. This is the venue-side identifier every tool will want.
5. Check whether other pools exist for the same mint on other venues, because permissionless pool creation means the first pool is not necessarily the only one.
6. Ask an aggregator for a quote at a realistic size and read the route it returns, which tells you where trading is actually happening rather than where it started.

What venue choice does not decide

It does not decide whether anybody wants the token. A venue is a mechanism for exchanging one asset for another at a price derived from reserves. It has no view on the asset and no ability to produce demand for it.

It does not decide the token's safety. Burned migration liquidity behaves the same way on any venue that supports burning, and holder concentration is a property of the distribution rather than of the pool. Reading a venue name as a safety signal is a mistake in both directions.

It does not decide long-term liquidity. The seeded deposit is the starting point; what happens afterwards depends on whether independent providers add depth, and that is a decision made by people weighing fee income against the risk of holding both sides of a volatile pair. No venue can compel that decision.

What venue choice does decide is whether your tooling recognises the program, how quickly third-party surfaces display the pool, what the swap fee split looks like, and which pool designs are available to providers who show up later. Those are real and worth knowing, and they are smaller than the way venue choice usually gets discussed.

Questions the desk is sent