Detecting New Raydium CPMM Pools in Real Time for Sniping

Raydium's CPMM (Constant Product Market Maker) program is where most new Solana token launches land first. If you want to enter at or near the opening price, you need to detect pool initialization inside the same slot it happens — not 30 seconds later when an aggregator indexes it. This article walks through exactly how to do that at the RPC and instruction level, with the specific discriminators, log patterns, and architectural decisions that separate a fast sniper from a slow one.

Why CPMM, Not CLMM or AMM v4

Raydium runs three pool programs concurrently. CLMM is concentrated liquidity — creators pick tick ranges and it's overwhelmingly used for established token pairs. AMM v4 (the original) is still alive but new launches almost never go there. CPMM is the default for the Raydium token launchpad and for the majority of manually created pools in 2025. Its program ID is CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK.

Conflating the three wastes compute on the wrong logs and causes missed detections.

The Initialize Instruction Discriminator

Every Anchor program prefixes instructions with an 8-byte discriminator derived from sha256("global:<instruction_name>")[0..8]. For CPMM's initialize instruction, that discriminator is 0xd0 0x46 0xa0 0x3e 0x29 0x3d 0xf1 0x4b (verify by running anchor idl fetch CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK and hashing the method name yourself — discriminators are derivable and stable across deployments, but always confirm against the published IDL).

When a transaction calls initialize, the instruction data starts with those 8 bytes followed by the init params: init_amount_0 (u64), init_amount_1 (u64), open_time (u64). That's 32 bytes of instruction data total for the core payload.

Subscribing at the Right Level

Two subscription strategies exist, and the choice has real latency implications:

logsSubscribe with a program filter — the cheapest and fastest path. Solana validators emit program logs during transaction execution. By subscribing to logs mentioning the CPMM program ID, you receive a notification as soon as the validator processes the transaction, before it's confirmed. The downside is that you're parsing text logs, not structured data, and log output can be truncated by compute unit exhaustion.

blockSubscribe with transactionDetails: "full" — gives you the complete transaction including all inner instructions, account keys, and post-balances. Latency is higher (you wait for block production) but the data is authoritative and you can deterministically parse the instruction bytes rather than regex over log strings.

For sniping, combine both: use logsSubscribe as the trigger to know something happened, then immediately fire a getTransaction call with maxSupportedTransactionVersion: 0 to fetch the full transaction and extract the pool address from account index 3 (the pool_state account in the CPMM initialize instruction's account list).

Account order in initialize:
0  creator
1  amm_config
2  authority (PDA)
3  pool_state      <-- this is your new pool
4  token_0_mint
5  token_1_mint
6  lp_mint
7  creator_token_0
8  creator_token_1
9  creator_lp_token
10 token_0_vault
11 token_1_vault
12 create_pool_fee
13 observation_state
14 token_program
15 token_0_program
16 token_1_program
17 associated_token_program
18 system_program
19 rent

Extract account index 3 from transaction.message.accountKeys and that's the pool address you'll use for every downstream operation.

Filtering for Actionable Pools

Not every new CPMM pool is worth entering. Before sending a buy, run these checks in parallel — they should complete within one additional RPC round trip using getMultipleAccounts:

• Mint authority status. Fetch the token-0 or token-1 mint account (whichever is the new token) and confirm mintAuthority is null. If mint authority is still set, the creator can print unlimited supply.
• Freeze authority status. Same account, check freezeAuthority. A live freeze authority means the creator can lock your tokens in the account.
• LP token burn. Fetch the creator's LP token account (index 9) and check whether the LP supply has been burned or transferred to the null address. Unburned LP is the single largest rug signal.
• open_time field. The initialize instruction encodes open_time as a Unix timestamp. If it's set to a future time, swaps will revert until that timestamp passes — you'll waste the gas and possibly tip a failed transaction.

These four checks together take one getMultipleAccounts call. If any fail, drop the pool. Speed without signal quality produces losses, not alpha.

Execution After Detection

Once a pool passes filters, you're constructing a CPMM swap instruction against CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK's swap_base_input or swap_base_output instruction. Use swap_base_output if you want to specify exactly how many tokens out (cleaner slippage accounting). Set your amount_in_maximum based on the pool's initial reserves — which you can read from the post-balances in the detection transaction — to avoid overpaying into a thin book.

On Solana, priority fees determine ordering within a slot. For new pool sniping, set computeUnitPrice to whatever clears the slot — in practice, 0.01–0.05 SOL in priority fee per transaction is common during contested launches. The trading bots we build at TierZero run dynamic fee estimation by sampling the last 20 blocks' landing fees for the CPMM program and targeting the 90th percentile.

Latency Budget and What Actually Kills You

The theoretical minimum is: validator processes tx → log emitted → your subscriber receives it → your getTransaction resolves → your swap tx lands. On a co-located RPC node (Latitude or Edgevana bare metal, same data center as a validator), the subscribe-to-receipt leg is under 20ms consistently. The getTransaction call adds another 15–40ms. Your swap construction should be pre-compiled (versioned transaction with pre-fetched lookup tables) so that step is under 1ms.

What actually kills most implementations is not the network leg — it's a serial pipeline. If you await each step before starting the next, you're adding unnecessary latency. Parallelize the filter checks. Pre-fetch the lookup tables on startup. Cache the CPMM program's account metas. The bots that win on contested launches have done all the pre-work before the event; the detection is just the trigger.

---

If you want this running in production without building the infrastructure from scratch, reach out to us at TierZero — we design, build, and operate Solana sniping and market-making systems end to end.