Detecting Pump.fun Graduation Events Before Raydium Migration

The window between a pump.fun token hitting its bonding curve ceiling and the Raydium pool going live is measured in slots, not seconds. Most traders react to price movement after the fact. The ones who capture the real edge are subscribed to the migration program itself, watching for the instruction that triggers pool creation before any swap is possible. Here is exactly how that works and what it takes to act in the same block.

The Bonding Curve Mechanics

Pump.fun runs every new token through its own AMM until 85 SOL of real SOL liquidity accumulates inside the bonding curve account. That threshold is not approximate — it is a hard constant baked into the program: virtual_sol_reserves must reach 85_000_000_000 lamports. Once the curve is saturated, the program locks the token, burns the LP tokens it held internally, and emits a Migrate instruction to the Raydium migration program (39azUYFWPz3VHgKCf3VChUwbpURdCHRxjWVowf5jUJjg).

The migration creates a Raydium CPMM pool, seeds it with the remaining token supply (roughly 206 million tokens) plus the 85 SOL, and opens the pool for public swaps — all in a single transaction. Every millisecond you spend reacting to secondary signals (price alerts, Telegram calls, DEX screeners) is a millisecond you have already lost.

Subscribing to the Migration Program

The correct primitive here is logsSubscribe with a filter on the migration program address, not a polling loop against an RPC. Polling introduces 200–800 ms of avoidable latency depending on slot time and your endpoint health. A persistent WebSocket subscription on a co-located node cuts that to under one slot confirmation.

The subscription filter you want:

{
  "mentions": ["39azUYFWPz3VHgKCf3VChUwbpURdCHRxjWVowf5jUJjg"]
}

When the migration fires, the log stream will contain Program 39azUYFWPz3VHgKCf3VChUwbpURdCHRxjWVowf5jUJjg invoke followed by the createPool discriminator. Parse the transaction signature out of the notification, fetch the full transaction with getTransaction at confirmed commitment, and extract:

• The new Raydium pool address (account index 4 in the createPool instruction)
• The token mint (account index 6)
• The seeded SOL amount (to calculate opening price)

At this point the pool exists but may not yet be in the processed state on your RPC. Submit your buy instruction immediately anyway — Solana validators will include it in the next available slot if your priority fee is competitive.

Constructing the Snipe Transaction

Priority fees are the entire game here. The opening slot of a new Raydium pool attracts dozens of competing bots. A fee of 0.01 SOL in setComputeUnitPrice is the floor for landing consistently; 0.05–0.1 SOL is realistic during high-contention launches. Compute unit estimation via simulateTransaction before submission is not optional — Raydium CPMM pools will reject under-budgeted transactions and you will eat the failed-tx fee without getting a fill.

Build the buy as a Raydium CPMM swap instruction, not a Jupiter route. Jupiter adds one hop of latency for quote aggregation and occasionally routes through intermediate pools. Direct CPMM calls with a hardcoded slippage tolerance (typically 15–25% for a graduation snipe) will land faster and fail less.

Key accounts to include in the instruction:

• poolState — the address you extracted from the migration transaction
• inputVault and outputVault — derivable from the pool state PDA
• observationState — the CPMM oracle, required even if you are not reading it
• Your associated token account for the graduated token (create it in the same transaction with createIdempotent to avoid a pre-flight round-trip)

Reading Bonding Curve State Without an Event

If you want to anticipate graduation rather than react to the migration instruction, subscribe to account changes on the bonding curve accounts for tokens you are tracking. The virtual_sol_reserves field is at a fixed byte offset in the curve account data — offset 40 for the u64 value. When you see that field cross 80_000_000_000 lamports (roughly 94% of the threshold), queue a standby transaction pre-built and pre-signed, ready to submit the moment the migration fires.

This two-stage approach — pre-build on 80 SOL, fire on migration — is what the bots we run in production at TierZero use for graduation plays. The standby transaction eliminates serialization latency at the critical moment.

Risks That Will Actually Hurt You

Rug-at-graduation is real. Some token deployers pre-coordinate a sell at the first Raydium swap, extracting liquidity from bots that buy the migration. Mitigation: check the deployer's wallet history before subscribing to that token's curve — a wallet with three prior launches that all spiked and dumped in the first block is a pattern, not a coincidence.

RPC latency variance is the other killer. A shared RPC node under load can delay your log subscription notification by 1–3 slots, which on Solana is 400–1200 ms. That is enough for three or four competing bots to fill ahead of you. Dedicated Triton or Helius Business-tier nodes with geographically co-located endpoints are table stakes for this strategy, not a luxury.

Slippage on thin opens compounds with high priority fees. If the pool opens with only 85 SOL of depth and you are buying 2 SOL worth, you are moving the price 2–3% before fees. Model your expected fill price, not just your entry price.

---

If you want this running in production without building the infrastructure yourself, reach out to us — we design, build, and operate on-chain execution systems exactly like this.