How to Detect New Solana Liquidity Pools Across Raydium, Meteora, Orca and PumpSwap

A PumpFun token hits graduation threshold. In the same block, the bonding curve closes and a PumpSwap pool opens with the graduated liquidity. If you were only watching the PumpSwap program, you caught the pool creation but missed the graduation context: no bonding curve history, no final price data, no clarity on what the initial liquidity actually represents. If you were only watching PumpFun, you saw the withdrawal but had no pool address to route to. Both programs, correlated on token mint, in the same event handler. That's just one DEX.

Raydium runs three separate AMM programs. Meteora runs two. Each fires pool creation on a different program address with a different instruction layout. There's no cross-DEX registry on Solana. A filter on Raydium AMM V4 receives nothing from Meteora, Orca, or PumpSwap. Teams that subscribe to one program and check that box typically catch under half of what's actually launching.

What follows is the complete map: all eight program addresses, the pool creation instruction for each, and the specific cases that break detection when you miss them.

01Why Polling Fails for Solana Pool Detection#

The first instinct is polling. Call getProgramAccounts against known factory accounts on a timer. Diff against the last response. New accounts in the diff are new pools.

It seems reasonable. It's not. Not for this use case.

Speed. A new pool on Raydium can see bot activity in the same block it's created. PumpFun graduation pools are actively traded before a 2-second polling interval has fired once. You're not detecting the opportunity. You're detecting what's left of it after the first-movers are already in.

Volume. On active days, Raydium AMM V4 alone creates several hundred new pools. getProgramAccounts without filters hits the full account set for the program. That's a 100× weighted call on most RPC providers. Many block it unfiltered entirely.

Context gap. Polling tells you a pool account exists. It doesn't give you the creation transaction. The token mints, the fee tier, the initial deposit amounts. All of that lives in the creation transaction, which you won't see from an account diff. You'd have to fetch the transaction separately — another round trip after you've already missed the timing window.

Yellowstone gRPC subscriptions solve all three. You receive the creation transaction in the same slot it's confirmed. Full transaction data. No polling, no rate-limit exposure, no context gap.

02How Yellowstone gRPC Pool Detection Works#

Yellowstone gRPC lets you subscribe to transactions by the programs they interact with. A transaction filter on a program ID means: deliver every confirmed transaction that touches this program as an instruction target.

For pool detection, you subscribe to each DEX's pool factory program. When an initialization instruction hits that program, you receive the full transaction. Parse the instruction accounts and data to extract the pool address, token mints, and fee parameters.

Four DEXes. Four programs. Four subscriptions.

03Raydium: Three Pool Types#

Raydium runs three separate AMM variants. Each is its own program and they're not interchangeable.

AMM V4 (Legacy)

Program: 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8

The original Raydium AMM. Still the highest-volume route for new token launches in 2026: meme coins, early PumpFun graduations, and direct AMM pools. If you're only subscribing to one Raydium program, it's this one.

Pool creation instruction: initialize2. Not initialize. There's an older initialize instruction that doesn't create pools. Getting this wrong means you're filtering for something that doesn't fire on new pool events.

CLMM (Concentrated Liquidity)

Program: CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK

Concentrated liquidity pools. More common for established pairs where market makers are setting tight ranges. Fewer new pools per day but typically higher initial liquidity.

Pool creation instruction: createPool. Anchor-style 8-byte discriminator: sha256("global:create_pool")[:8].

CPMM

Program: CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C

Newer constant-product implementation with an updated account structure. Growing share of new token launches.

Pool creation instruction: createPool.

from yellowstone_grpc_proto.geyser_pb2 import (
    SubscribeRequest,
    SubscribeRequestFilterTransactions,
)

request = SubscribeRequest(
    transactions={
        "raydium_amm_v4": SubscribeRequestFilterTransactions(
            vote=False,
            failed=False,
            account_include=["675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8"],
        ),
        "raydium_clmm": SubscribeRequestFilterTransactions(
            vote=False,
            failed=False,
            account_include=["CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK"],
        ),
        "raydium_cpmm": SubscribeRequestFilterTransactions(
            vote=False,
            failed=False,
            account_include=["CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C"],
        ),
    }
)

Your stream receives every confirmed transaction touching any of those programs. Filter for pool creation by checking the instruction discriminator: the first 1 or 8 bytes of instruction data depending on whether the program uses Anchor's convention or a flat index scheme.

04Meteora: Two Different Programs#

Meteora runs two liquidity products on separate programs. They're not the same codebase and they don't share subscription coverage.

Dynamic AMM

Program: Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EkAW7vAm

Constant-product pools with dynamic fees that adjust to volatility. Similar structure to Raydium AMM V4 in concept.

Pool creation instruction: initialize.

DLMM (Liquidity Book)

Program: LBUZKhRxPF3XUpBCjp4YofRKcPKtBXFtNen1eTw2zRgb

Discrete liquidity bins instead of continuous curves. Teams use it to seed liquidity into specific price ranges without full-range exposure. It's grown significantly since 2025 as more projects launch with controlled initial liquidity profiles — a common bootstrapping mechanism for new token pairs that want bins concentrated around the initial price rather than spreading capital across levels that won't see volume for months.

Pool creation instruction: initializeLbPair.

Teams that only watch Meteora's Dynamic AMM miss the DLMM feed entirely. It's the same mistake as watching only one Raydium program. Different programs, different subscriptions.

05Orca: Whirlpool#

One program. The simplest case of the four.

Program: whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc

All Orca pools go through Whirlpool, including those created via the Orca UI. Concentrated liquidity with fixed fee tiers expressed in hundredths of a basis point (3000 = 0.03%).

Pool creation instruction: initializePool.

The Whirlpool initialization transaction is clean. It includes both token mints, the fee tier, and tick spacing. Everything you need to characterize the pool comes from a single transaction. There's no secondary event to correlate, no secondary program to watch.

06PumpSwap: The Graduation Problem#

PumpSwap is the most complex detection case. Not because the program's complicated. Because pool creation isn't a direct user action. It fires when the bonding curve completes.

When a PumpFun token completes its bonding curve and hits the graduation threshold, two things happen in sequence:

• The PumpFun program (6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P) fires a withdraw instruction, closing the bonding curve account.
• The PumpSwap AMM program (pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA) fires a create instruction, seeding the new pool with the graduated liquidity.

If you're only watching the PumpSwap program, you'll catch the pool creation. But you're missing the graduation context: which bonding curve just closed, what the final bonding curve price was, the token's PumpFun mint history. That context isn't in the PumpSwap transaction. It's in the PumpFun withdrawal transaction that fired first.

The right approach: subscribe to both programs. Correlate on the token mint address, which appears in both the PumpFun withdrawal accounts and the PumpSwap pool creation accounts, giving you the link that joins the graduation context to the pool address it produced. The withdrawal and pool creation land in the same block in most cases. When graduation bots are active, they're often bundled in the same transaction.

07The Solana Transaction Parsing Problem#

Subscribing to these programs gets you transactions. Transactions are binary.

What Geyser delivers is a protobuf message containing the raw transaction bytes. To extract anything useful — the token mints, the fee tier, the initial deposit amounts — you're deserializing against each program's specific instruction encoding.

Each program has a different layout. Raydium AMM V4 uses flat little-endian structs with instruction byte indices. Whirlpool uses Anchor's IDL-based Borsh encoding with 8-byte discriminators. Meteora DLMM has its own struct. PumpSwap has another.

Four programs. Four deserialization schemas to build, test, and maintain.

The maintenance part is what breaks teams over time. Programs upgrade — not with notice emails, not with a migration window you can plan around, but as a silent on-chain deployment that starts processing new transactions against a field layout your byte-offset code has never seen. Discriminators stay stable but struct field layouts shift. A schema change on Raydium's CLMM program silently breaks your CLMM parser. It'll still deserialize. It'll return incorrect field values without throwing any errors. Your downstream sniper fires on wrong token mints or wrong fee tiers. You won't know until something downstream fails in a way that's hard to trace back.

08Normalizing Pool Events Into One Struct#

Once you're receiving creation events from all four DEXes and parsing them correctly, normalize into a consistent structure. Downstream code shouldn't need to know which DEX emitted the event.

from dataclasses import dataclass
from typing import Optional

@dataclass
class PoolCreated:
    pool_address: str
    dex: str                        # raydium_amm_v4 | raydium_clmm | raydium_cpmm
                                    # meteora_dynamic | meteora_dlmm
                                    # orca_whirlpool | pumpswap
    token_a_mint: str
    token_b_mint: str
    fee_bps: int
    slot: int
    signature: str
    initial_liquidity_sol: Optional[float]
    graduated_from_pumpfun: bool

The graduated_from_pumpfun flag matters for filtering. MEV bots hunting first-mover positions on genuinely new markets aren't looking at PumpSwap graduation pools the same way they'd look at a fresh Raydium AMM V4 pool. A graduated token's got price history, known holder concentration, and specific initial liquidity characteristics. Different risk profile. Worth separating at normalization rather than having every consumer implement its own check.

The routing function that maps incoming transactions to the correct parser and emits normalized PoolCreated events is the piece you'll maintain as programs upgrade. Everything downstream can be stateless consumers.

09Frequently Asked Questions#

What's the fastest way to detect new Solana pools?

Yellowstone gRPC subscription. Subscribe to each DEX's pool factory program and your subscriber receives the creation transaction in the same slot it's confirmed. There's always a gap with polling: a new pool can be traded and arbitraged before your next poll fires. Stream subscriptions don't have that gap.

Do I need a subscription for each DEX?

Yes. There's no cross-DEX pool registry on Solana. A filter on the Raydium AMM V4 program won't see Meteora or Orca events at all. You need one filter per program. Raydium runs three programs alone.

How do I detect PumpFun graduation pools?

Subscribe to both the PumpFun program (6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P) and PumpSwap AMM (pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA). Graduation fires a withdraw on PumpFun and a create on PumpSwap within the same block. Correlate on the token mint to link them.

What's in a pool creation transaction?

Both token mint addresses, the pool account address, fee parameters, and the initial liquidity transfer in the same transaction. For PumpSwap graduation pools, the initial liquidity comes from the completed bonding curve. That full context is only available in the creation transaction. Polling an account diff doesn't return it.

How do I tell Raydium AMM V4 from CLMM?

Program address. AMM V4 is 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8. CLMM is CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK. They're separate programs. The subscription filter you set determines which pool type you receive.

What breaks when DEX programs upgrade?

Raw byte parsers. The program address doesn't change, so your subscription still fires. But if the instruction struct layout changes, your parser returns incorrect field values without errors. You'll get wrong token mints or wrong fee data silently. Decoded event streams handle upgrades on the provider side. Your consumer gets the same typed struct regardless of what version of the program fired the event.

How many new pools appear per day?

It varies. During active market periods, Raydium AMM V4 alone sees several hundred new pools. PumpSwap volume tracks the PumpFun graduation rate, which spikes sharply around viral token launches. Meteora and Orca add volume at lower frequency. On high-activity days across all four DEXes, total new pool creation can exceed a thousand pools. Manual monitoring isn't viable at that rate.

Should I filter failed transactions?

Set failed=False in your subscription filter. Failed transactions touch the program accounts and trigger your filter, but the instructions rolled back and no pool was created. You'd be parsing account slots that weren't written and emitting false PoolCreated events downstream.

If you'd rather not maintain four separate deserialization schemas as programs upgrade, NLN Yellowstone gRPC handles the subscription infrastructure and delivers pool creation events across Raydium, Meteora, Orca, and PumpSwap with program upgrade handling on our side. For teams that want pool and token creation data pre-processed rather than building the subscriber themselves, NLN Trading Datasets has normalized pool creation and token creation records queryable without running any stream infrastructure. If you want to talk through your detection setup, talk to an engineer.