// Raydium + Yellowstone gRPC

Stream Raydium swaps from the validator.

Raydium processes billions in daily volume across AMM, CLMM, and concentrated liquidity pools. For arbitrage scanners, price feeds, and trading bots, stale data means missed opportunities. Yellowstone gRPC streams every Raydium transaction within milliseconds of slot confirmation.

Raydium on Solana

Raydium is Solana's largest decentralized exchange by trading volume. It operates three distinct trading mechanisms: AMM V4 for standard constant-product swaps, CLMM (Concentrated Liquidity Market Maker) for capital-efficient concentrated liquidity positions, and the newer Raydium Launchpad for token launches and initial liquidity bootstrapping. Each mechanism serves a different market segment, and each generates a massive volume of on-chain transactions that traders need to monitor.

The complexity starts with Raydium's multi-program architecture. AMM V4 runs under the program ID 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8, while the CLMM concentrated liquidity pools operate under CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK. These are separate programs with different instruction layouts, different account structures, and different event formats. Monitoring Raydium comprehensively means subscribing to both programs and handling their distinct data schemas.

Each of these programs processes thousands of transactions per minute during active trading periods. During token launches or market-moving events, throughput spikes dramatically as bots and traders compete for execution. The sheer volume makes traditional RPC polling impractical — by the time your bot polls for new transactions, parses the response, and identifies a relevant event, the opportunity window has already closed.

Different trading strategies require different Raydium events. For price feed and arbitrage strategies, you need every swap event in real-time — each swap shifts the pool's price curve, and your bot needs to reflect that change immediately to detect cross-DEX discrepancies. For sniping and launch trading, you need pool creation events before anyone else sees them — the first few seconds of a new pool's life produce the widest spreads and the largest profits. For liquidation bots and risk management systems, you need liquidity removal events instantly — a large withdrawal from a pool changes its depth and price impact characteristics, and positions that were safe at one liquidity level may become vulnerable at another.

Set up Raydium transaction filters

Yellowstone gRPC gives you access to every transaction on the Solana network. The key to efficient Raydium monitoring is configuring your SubscribeRequest to capture only the programs and instruction types you care about. Here is a step-by-step setup that delivers comprehensive Raydium coverage without drowning your bot in irrelevant data.

01

Choose which Raydium programs to monitor

Start by deciding which Raydium programs your strategy requires. AMM V4 (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8) handles standard constant-product swaps and is where the majority of Raydium volume flows. CLMM (CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK) handles concentrated liquidity positions with tighter price ranges. For most trading bots, you want both. For a pure arbitrage scanner, AMM V4 alone covers the highest-volume pools.

02

Build your SubscribeRequest with Raydium program IDs

Configure your gRPC subscription by adding the Raydium program IDs to the account_include filter. This tells the Yellowstone node to stream only transactions that involve these programs, reducing your inbound data volume by 95-99% compared to an unfiltered firehose. Each transaction that touches either program will be delivered to your client in slot order.

03

Filter out vote transactions and failed transactions

Even with program-level filtering, your stream will include transactions you don’t need. Vote transactions (from validator consensus) add noise without trading signal. Failed transactions represent attempts that didn’t execute — useful for some MEV analysis but irrelevant for price feeds and execution bots. Exclude both using the vote and failed transaction filter flags in your SubscribeRequest to reduce data volume further and lower your processing overhead.

04

Parse the instruction discriminator to identify event types

Each Raydium instruction begins with an 8-byte discriminator that identifies the operation type: Swap, AddLiquidity, RemoveLiquidity, CreatePool, and others. By reading this discriminator before fully deserializing the instruction, your bot can quickly classify events and route them to the appropriate handler. This two-stage parsing approach — discriminator check first, full decode only for matching events — minimizes CPU spent on instructions your strategy doesn’t use.

raydium-filter.js
const Client = require("@triton-one/yellowstone-grpc");
const RAYDIUM_AMM_V4 = "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8";
const RAYDIUM_CLMM = "CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK";
const client = new Client(
"https://grpc.subglow.io",
undefined,
{ "grpc.max_receive_message_length": 64 * 1024 * 1024 }
);
const request = {
transactions: {
raydium: {
accountInclude: [RAYDIUM_AMM_V4, RAYDIUM_CLMM],
accountExclude: [],
vote: false,
failed: false,
},
},
};

This filter captures all successful Raydium transactions across both AMM V4 and CLMM programs while excluding vote and failed transactions.

Parse Raydium swap events

Every Raydium swap transaction contains a set of critical fields that your bot needs to extract and process. The core data points are: the pool address identifying which liquidity pool the swap occurred in, the token_in object containing the input token's mint address and the raw amount deposited, the token_out object with the output token's mint and the amount received, the direction indicating whether the trade was a buy or sell relative to the base token, and the price_impact measured in basis points showing how much the swap moved the pool's price.

Calculating the effective price from a swap event is straightforward once you have the parsed fields. Divide the token_out amount by the token_in amount, adjusting for each token's decimals. For example, if a swap sends 1,500,000,000 lamports of SOL (1.5 SOL at 9 decimals) and receives 42,819,200 units of a 6-decimal token, the effective price is 42,819,200 / 10^6 divided by 1,500,000,000 / 10^9 — which gives you 28.546 tokens per SOL. Tracking this price across consecutive swaps in the same pool gives you a real-time price feed with slot-level granularity.

Sample output — Raydium AMM V4 swap event
{
"signature": "5vK9r...mQ4w",
"slot": 284391210,
"slot_lag_ms": 3,
"program": "raydium_amm",
"type": "swap",
"parsed": {
"pool": "58oQChx4yWmvKdwLLZzBi4ChoCc2fqCUWBkwMihLYQo2",
"token_in": { "mint": "So11111111111111111111111111111111111111112", "amount": 1500000000 },
"token_out": { "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "amount": 42819200 },
"direction": "buy",
"price_impact_bps": 12
}
}

Raw Yellowstone gRPC data does not arrive in this format. The instruction data for every Raydium transaction is Borsh-encoded — a compact binary serialization format that requires Raydium's specific IDL (Interface Definition Language) to decode. You need to read the 8-byte instruction discriminator, match it against Raydium's known instruction set, then deserialize the remaining bytes into typed fields using the correct layout for that instruction variant. Account keys must be resolved from the transaction's account list by index position, which varies between AMM V4 and CLMM programs.

This decoding pipeline is where most teams spend weeks of development time. Raydium's instruction layouts change across program upgrades, edge cases around CPI (cross-program invocation) inner instructions require special handling, and token amounts need decimal adjustment based on each mint's configuration. Subglow handles all of this server-side — delivering pre-parsed JSON like the example above with every field extracted, amounts labeled, and accounts resolved. Your bot receives trade-ready data and can skip the entire Borsh deserialization pipeline.

Detect new pool creation

New pools on Raydium represent some of the highest-value opportunities in Solana DeFi. When a token migrates from Pump.fun's bonding curve to a Raydium AMM pool, or when a project launches a new trading pair, the first seconds of that pool's existence produce the widest spreads and the least competition. Sniper bots and launch traders depend on detecting these CreatePool events before anyone trading through standard RPC infrastructure.

To filter for pool creation events, subscribe to the AMM V4 program (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8) and watch for transactions containing the Initialize instruction discriminator. When a new pool is created, the transaction includes the base token mint, the quote token mint (usually SOL or USDC), the initial liquidity amounts for both sides of the pool, and the newly generated pool address. These fields tell your bot everything it needs to evaluate the opportunity: what token is launching, how much liquidity backs it, and where to route a swap.

The timing advantage is significant. gRPC-based pool detection delivers the CreatePool event within milliseconds of slot confirmation. RPC-based scanners that poll getSignaturesForAddress in a loop typically detect the same event 100–500ms later, depending on their polling interval and the RPC node's response time. In a market where dozens of bots compete to be first into a new pool, that 100–500ms gap is the difference between buying at launch price and buying after the initial spike.

For production sniper bots, the workflow after detection is: validate the token (check creator history, verify liquidity thresholds, run safety checks), construct a swap transaction targeting the new pool address, and submit via Jito bundle for atomic execution. The faster your bot sees the pool, the more time it has for validation without sacrificing its position in the execution queue. See our arbitrage guide for the full execution pipeline.

Sample output — Raydium pool creation event
{
"program": "raydium_amm",
"type": "create_pool",
"slot": 284391502,
"parsed": {
"pool": "9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM",
"base_mint": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
"quote_mint": "So11111111111111111111111111111111111111112",
"base_amount": 1000000000000,
"quote_amount": 85000000000
}
}

Build a Raydium price feed

One of the most practical applications of a Raydium gRPC stream is building a real-time price feed. Every swap that flows through a Raydium pool shifts the pool's reserves and therefore its effective price. By processing these swap events as they arrive, you can construct a price ticker that updates with every trade — not every few seconds like a polling-based approach, but with every single on-chain swap.

The calculation is straightforward. For each swap event, divide the output amount by the input amount (adjusted for decimals) to get the effective exchange rate. Store this alongside a timestamp derived from the slot number, and you have a tick-by-tick price history. Aggregate these ticks over time windows — 1 second, 5 seconds, 1 minute — and you have volume metrics for each pool. Track the cumulative token_in amounts for volume, and count the number of swap events for trade frequency.

This data feeds multiple downstream use cases. For arbitrage detection, compare the Raydium price against other DEXs — any discrepancy beyond your gas + slippage threshold is an opportunity. For portfolio trackers, map token holdings to real-time prices without relying on third-party oracle services. For dashboards, display live trading activity with per-pool granularity. For on-chain risk systems, monitor price impact trends to detect liquidity drain or manipulation attempts.

raydium-price-feed.js
const prices = new Map();
const volumes = new Map();
const client = new Subglow({)
url: "grpc.subglow.io:443",
apiKey: process.env.SUBGLOW_API_KEY,
filter: ["raydium"],
});
client.subscribe((event) => {
if (event.type !== "swap") return;
const { pool, token_in, token_out } = event.parsed;
const price = (token_out.amount / 1e6) / (token_in.amount / 1e9);
prices.set(pool, { price, slot: event.slot, ts: Date.now() });
volumes.set(pool, (volumes.get(pool) || 0) + token_in.amount);
console.log(
`${pool.slice(0,8)}: ${price.toFixed(4)} | vol: ${volumes.get(pool)}`
);
});

Each swap event updates the local price state and running volume counter per pool. Extend with time-windowed aggregation for OHLCV candles.

For a production-grade price feed, you would add several enhancements: maintain separate decimal configurations per mint (fetched once at startup), implement time-windowed volume buckets for 1s/5s/1m aggregation, track bid-ask spreads by analyzing both buy and sell swaps separately, and store historical ticks for charting and backtesting. The Yellowstone gRPC filter guide covers additional filter refinements for narrowing to specific token pairs.

The advantage of building your price feed on gRPC rather than polling is consistency and completeness. Every swap that executes on-chain appears in your stream in slot order. With RPC polling, rapid-fire swaps within the same slot can be missed if your polling interval is too wide or the RPC node's response doesn't include them all. A gRPC-based feed gives you a complete, ordered record of every price movement — the same data a chain indexer would see, delivered in real-time rather than retroactively. See our Yellowstone gRPC tutorial for the full setup walkthrough and our TypeScript guide for strongly-typed client patterns.

Frequently asked questions

Which Raydium programs should I subscribe to?

AMM V4 (675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8) for standard swaps and CLMM (CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK) for concentrated liquidity. Include both program IDs in your SubscribeRequest for comprehensive coverage of all Raydium trading activity.

Can I detect new Raydium pool creation via gRPC?

Yes. Subscribe to the AMM V4 program and filter for Initialize/CreatePool instructions. You’ll see every new pool the moment the transaction confirms — typically 100–500ms before RPC-based scanners detect it through polling.

How do I parse Raydium instruction data from Yellowstone?

Raw Yellowstone data contains Borsh-encoded instruction data. You’ll need Raydium’s IDL to decode the instruction discriminator and extract fields like pool address, token mints, and amounts. Alternatively, Subglow delivers pre-parsed Raydium events with all fields extracted as clean JSON — no Borsh decoding required.

Does Subglow support Raydium monitoring?

Yes. Subglow’s Raydium filter delivers pre-parsed swap, liquidity, and pool creation events. Fields include pool, token_in, token_out, direction, and price_impact — structured as JSON and delivered within milliseconds of slot confirmation.

Every swap. Every pool. Every millisecond.

Pre-parsed Raydium events with pool data, token amounts, and price impact. No Borsh decoding.