Dang chew's OrganizationVisit Website →
← Back to blog

How Pump.fun Tokens Migrate to Raydium (and PumpSwap)

August 28, 2026
How Pump.fun Tokens Migrate to Raydium (and PumpSwap)

Since March 20, 2025, most Pump.fun graduations route to PumpSwap, the platform's own AMM, not Raydium. Raydium migrations still happen for older tokens and certain edge cases, but it's now a legacy path. Either way, migration executes a migrate instruction from the migration account that seeds AMM liquidity (commonly around $12k) and burns LP tokens. Developers track it with logsSubscribe on the migration account's log stream, following up with getTransaction to confirm pool addresses. Platforms like Snipethem watch for these events to trigger copy trades within seconds of graduation.

TL;DR:

  • Most migrations now route directly to PumpSwap, meaning traders should focus on PumpSwap program IDs rather than Raydium for detection.
  • Liquidity seeded into new pools is typically around $12,000, and the burn of LP tokens prevents rug pulls instantly after migration.
  • Detection relies on subscribing to migration account logs and parsing full transaction details within seconds of migration events.
  • Post-migration, the token's price shifts from bonding curve calculations to traditional AMM models, increasing slippage and volatility.
  • Rapid response and execution are critical because liquidity can be thin and volatile within the first 10 to 20 seconds after migration.

Table of Contents

What Happens When a Pump.fun Token Migrates to Raydium?

A Pump.fun token starts life on a bonding curve, not an order book or liquidity pool. Price moves algorithmically as buyers push the curve up and sellers pull it down, with no external liquidity provider involved. That changes the moment the token's market cap crosses roughly $69,000 in cumulative buy pressure, the historical graduation trigger that flips the token's complete flag on-chain.

Once complete is set, the Pump.fun migration account fires a migrate (or, in the Raydium era, initialize2) instruction. That single transaction does three things at once: it creates a new AMM pool, deposits the graduating liquidity into that pool, and burns the resulting LP tokens rather than handing them to a deployer wallet.

Burning the LP tokens matters more than it sounds. It means nobody, including the original token creator, can pull the seeded liquidity later. That single design choice is why "rug the pool right after graduation" isn't a viable exploit path here. Community discussion on Solana StackExchange has flagged this locked liquidity as one of the original reasons Pump.fun leaned on Raydium in the first place. Deeper liquidity, plus a mechanism that reduced rug risk, was a stronger pitch than keeping trades trapped inside a bonding curve forever.

The economics shift the instant migration completes:

  • Pricing moves from bonding-curve math (a fixed function of cumulative supply sold) to constant-product AMM pricing, where price depends on the ratio of reserves in the pool.
  • Seed liquidity is commonly cited around $12k, a figure repeated across developer guides for building migration listeners.
  • Slippage behavior changes immediately. Bonding curves absorb large buys predictably; a shallow AMM pool does not.
  • LP tokens are burned, not custodied, which is verifiable on-chain by checking the LP mint's supply against the burn address.

For traders, this is the moment the token stops behaving like a curve and starts behaving like every other Solana pair on an automated market maker, reserves in, reserves out, and price is whatever the ratio says it is.

How Do You Detect a Pump.fun Migration in Real Time?

Detection comes down to picking the right subscription method and knowing which program IDs to watch. Three options exist on Solana's RPC layer, and they are not interchangeable.

  1. logsSubscribe on the Pump.fun migration account is the standard approach. It's lightweight and fires the moment a matching transaction lands, but logs can truncate on complex transactions, so you can't treat log text alone as ground truth.
  2. programSubscribe watches account state changes tied to a program ID. It's heavier bandwidth but catches state mutations that log-only listeners occasionally miss.
  3. blockSubscribe streams entire blocks. It's the most expensive option and rarely worth it unless you're already indexing full block data for other reasons.

Most production systems don't pick just one. Because logsSubscribe can miss truncated logs on versioned transactions, developers commonly run logsSubscribe and programSubscribe in parallel and deduplicate by transaction signature, a pattern documented in Chainstack's migration listening guide.

Once you catch the signal, the real work starts. A raw log line rarely gives you enough to act on, so the standard workflow is: subscribe to migration account logs, catch the Migrate event, then immediately call getTransaction on that signature to pull the full instruction data. From there you extract the poolAddress, lpMint, tokenAddress, and the quote/base vault accounts, per the parsing patterns in GetBlock's migration listener docs.

Versioned transactions complicate this further. When addressTableLookups are present, account indexes inside the instruction don't map to fixed positions, so a listener that assumes "the pool address is always account index 4" will break silently on some transactions. Robust parsers resolve every account through the transaction message's accountKeys array instead of hardcoding index positions, a detail that trips up a lot of first-pass implementations.

Pro Tip: Once you have the pool address, don't reinvent vault resolution from scratch. DeFi APIs like Shyft will return base/quote vault details and LP mint metadata in a single call, saving you a second or third round-trip to the RPC node.

Why Did Pump.fun and Raydium's Relationship Change?

For most of Pump.fun's history, graduation meant one thing: send the token to Raydium. Raydium had the deepest liquidity on Solana for new pairs, and Pump.fun had no AMM of its own, so the two were functionally locked together. Every graduated token became Raydium volume, and Raydium collected the swap fees on all of it.

That ended on March 20, 2025, when Pump.fun launched PumpSwap, its own native AMM. Graduations that once had to leave the platform now stay inside it.

  • Pump.fun kept the fee revenue on post-graduation trading instead of handing it to Raydium.
  • Traders got a simpler experience: one platform, start to finish, no wallet redirection at graduation.
  • Raydium answered with LaunchLab, its own token-launch product aimed at recapturing issuance volume, according to Decrypt's coverage of the launch.
  • Analysis from The Block framed the split as a straightforward incentive rebalancing: Pump.fun wanted fee capture, Raydium wanted market share.

Raydium migrations didn't disappear. They became the exception rather than the rule, which is exactly why any serious listener needs to check both program IDs rather than assuming one destination.

What Changes for Traders and Liquidity Providers After Migration?

Bonding curves absorb size predictably. AMM pools don't, and that's the core risk window right after graduation. A pool seeded with roughly $12,000 in liquidity can swing hard on a single moderately sized buy, which is exactly the setup that invites front-running and priority-fee wars in the first few blocks after migration.

Hands moving crypto tokens on neon desk

Fee routing matters just as much as slippage. Whichever AMM captures the swap volume also captures the fee stream, and that has knock-on effects for protocol tokenomics. Reporting attributed a single-day $18.4 million combined protocol fee record on Solana to concentrated graduated-pool activity, a figure that shows how much economic weight sits on the destination AMM decision.

For LPs and traders alike, the first period post-migration carries the highest volatility and thinnest liquidity of the token's trading life.

How Snipethem Traders Act on Migration Signals

Detecting a migration is only useful if you can act on it before the pool's early volatility settles. Snipethem's infrastructure is built around that exact gap, with a fast response time and a high success rate on tracked trades, figures the platform states as its own performance benchmarks.

The workflow looks like this in practice:

  • A migration event fires on-chain and gets picked up through log monitoring.
  • Pool addresses, LP mint, and vault accounts get resolved automatically.
  • The platform surfaces which top-ranked Pump.fun traders are already positioned in that token.
  • A user with active copy access or a configured sniper bot can execute very quickly after the migration event.

The point isn't to replace on-chain literacy. It's to compress the gap between detection and execution down to something a manual listener setup can't match without serious engineering time.

What Traders Get Wrong About Migration Timing

Most guides on this topic treat migration detection as a solved technical problem: subscribe to logs, parse the transaction, done. The part that actually determines whether a trade is profitable is what happens in the 10 to 20 seconds after the pool exists, when liquidity is thinnest and everyone watching the same program ID is racing for the same fills.

What Traders Get Wrong About Migration Timing — overview diagram

The conventional advice, "just watch for the Migrate event," undersells how much the destination matters. A listener that only checks Raydium's program ID will silently miss the majority of graduations now, since PumpSwap has been the default since March 2025. Anyone still building detection systems around Raydium alone is optimizing for a path that's become the exception.

What actually matters is speed after detection, not detection itself. The bonding curve to AMM transition is well understood and well documented at this point. The competitive edge lives in how fast you can go from "event fired" to "position filled," which is an infrastructure problem, not a knowledge problem. Traders who treat this as purely educational, read the docs, understand the mechanics, stop there, will keep losing the race to systems built specifically to close that gap.

— dang

Trade Migrations Faster With Snipethem

Reading the on-chain mechanics is useful. Acting on them in real time is a different problem entirely, and it's the one Snipethem was built to solve. Rather than running your own listener infrastructure and racing to parse transactions manually, you get access to top Pump.fun traders whose positions are already tracked against migration events as they happen.

Snipethem

Setup is straightforward: pay a one-time SOL fee for 24-hour copy access to a trader with a strong track record, or configure the sniper bot to react automatically once a migration event and pool address resolve. Set your position size and slippage tolerance before migration windows open, since that first minute of thin liquidity is where most of the risk sits. Start by browsing current trader rankings and picking one whose recent history matches the risk level you're comfortable with.

Sources