// Jupiter + Yellowstone gRPC
Stream Jupiter swaps
in real-time.
Jupiter is the #1 DEX aggregator on Solana by volume — routing swaps across Raydium, Orca, Lifinity, Meteora, and dozens of other venues. For arbitrage scanners, copy trading bots, and portfolio trackers, Jupiter data is the single most valuable stream on the network. Yellowstone gRPC delivers every Jupiter transaction directly from the validator with low execution latency — no polling, no missed swaps.
Why monitor Jupiter?
Jupiter is not just another DEX — it is the routing layer that the majority of Solana swap volume flows through. When a trader executes a swap on any Jupiter-integrated frontend, the Jupiter aggregator finds the best route across all connected liquidity sources and executes it as a single atomic transaction. This means monitoring Jupiter gives you visibility into the aggregate trading activity of the entire Solana DeFi ecosystem, not just a single venue.
Beyond simple swaps, Jupiter handles limit orders and DCA (Dollar Cost Averaging) — two features that generate significant on-chain activity. Limit orders create pending positions that fill when price conditions are met, producing both creation and fill events. DCA schedules execute recurring swaps at fixed intervals, generating predictable transaction patterns that bots can track and anticipate. Together, these three product lines make Jupiter the highest-signal program to monitor on Solana.
Trading bots need Jupiter data for multiple reasons. Arbitrage detection becomes significantly more effective when you see every Jupiter swap route — each route reveals which DEXs provided liquidity and at what prices, exposing cross-venue pricing discrepancies the moment they form. Copy trading is most effective on Jupiter because the majority of whale swaps route through the aggregator regardless of the underlying venue — one Jupiter subscription captures what would otherwise require monitoring dozens of individual DEX programs separately.
MEV protection and detection systems also depend on Jupiter monitoring. Sandwich attacks frequently target Jupiter swaps because they carry the highest volume. By streaming Jupiter transactions with low execution latency, MEV bots can detect pending swaps in the mempool and position accordingly, while protection systems can alert users to suspicious transaction patterns around their swaps. Portfolio trackers that integrate Jupiter data provide the most comprehensive view of a wallet's trading history, since Jupiter transactions represent the canonical record of a user's DeFi activity.
Arbitrage detection
Every Jupiter route exposes cross-DEX pricing. Detect discrepancies the moment they form across Raydium, Orca, and other venues.
Copy trading
Most whale swaps route through Jupiter. Mirror high-value wallets with a single subscription instead of monitoring dozens of DEXs.
MEV protection
Stream Jupiter swaps to detect sandwich attacks and front-running in real-time. Alert users or position defensively.
Portfolio tracking
Jupiter transactions are the canonical record of DeFi activity. Track every swap, limit fill, and DCA execution per wallet.
Jupiter program ID & instruction types
The Jupiter v6 aggregator operates under a single program ID: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4. This program processes all Jupiter swap routing, limit order management, and DCA execution. Unlike Raydium, which splits functionality across multiple programs (AMM V4, CLMM), Jupiter consolidates everything under one address — making your SubscribeRequest configuration straightforward.
Each Jupiter transaction contains an instruction with a discriminator that identifies the operation type. The three primary categories are swaps (route execution through one or more DEX venues), limit orders (create, fill, or cancel pending orders), and DCA (open, close, or fill recurring swap schedules). Your bot parses the discriminator to route each event to the appropriate handler, or you can use Subglow's pre-parsed output which includes a type field already resolved.
Swap
Route execution through one or more DEX venues. Contains input/output mints, amounts, the full route plan with each hop, slippage settings, and the user wallet. This is the highest-volume event type — every Jupiter frontend swap generates a Swap instruction.
Limit Order
Create, fill, or cancel pending orders. Create events include the target price, token pair, and expiry. Fill events fire when the order matches — containing the execution price and filled amount. Cancel events indicate user-initiated order withdrawal.
DCA
Open, close, or fill Dollar Cost Averaging schedules. Open events include the token pair, interval, and total allocation. Fill events fire on each recurring execution. Close events indicate the schedule completed or was cancelled by the user.
A single program ID captures all Jupiter activity — swaps, limit orders, and DCA. Set vote: false and failed: false to exclude noise.
Connecting with Node.js
The fastest way to start streaming Jupiter transactions is with the @triton-one/yellowstone-grpc client for Node.js. Subglow's gRPC endpoint at grpc.subglow.io is fully Yellowstone (Dragon's Mouth) compatible — the same client, the same SubscribeRequest format, the same streaming protocol. No custom SDK needed.
The example below establishes a persistent gRPC connection, authenticates with your Subglow API key, subscribes to all Jupiter v6 program transactions, and logs each incoming event. In production, you would replace the console.log with your trading logic — route analysis, copy trade execution, or arbitrage detection.
Uses the standard @triton-one/yellowstone-grpc client. The reconnection logic in the error handler ensures your bot recovers from transient network issues. See the TypeScript guide for type-safe patterns.
Connecting with Rust
For latency-sensitive trading systems, Rust provides the lowest overhead for processing Yellowstone gRPC streams. The yellowstone-grpc-client crate connects to any Yellowstone (Dragon's Mouth) compatible endpoint — including Subglow's grpc.subglow.io. The Rust client eliminates the garbage collection pauses inherent in Node.js, giving your bot consistent low execution latency even under heavy stream throughput.
The example below creates a gRPC client, constructs a SubscribeRequest targeting the Jupiter v6 program, and processes incoming transactions in an async loop. Each update is pattern-matched to extract the transaction payload for further parsing.
Requires yellowstone-grpc-client and yellowstone-grpc-proto crates. The async runtime processes each update in microseconds, ideal for latency-critical arbitrage and MEV systems.
Jupiter swap event schema
Every Jupiter swap transaction contains a rich set of fields that describe the route, amounts, slippage, and execution details. When using Subglow's pre-parsed output, these fields arrive as structured JSON — ready for your trading logic with zero deserialization work on your end. The route_plan array is particularly valuable: it reveals every hop in the multi-DEX route Jupiter selected, letting you see exactly which venues provided liquidity and at what effective rates.
Here is the complete pre-parsed JSON output that Subglow delivers for a Jupiter swap event. Every field is labeled, typed, and ready for direct use in your bot's logic. Amounts are in raw token units (respecting each mint's decimals), wallet addresses are full base58 strings, and the route plan includes the DEX label for each hop.
The route_plan array shows Jupiter split this 5 SOL → USDC swap across Raydium (70%) and Orca (30%) for optimal execution. The slippage_bps of 50 means the user set 0.5% max slippage. Arbitrage bots can use the route plan to identify which DEX legs had the best rates and where cross-venue opportunities exist.
Limit order & DCA schemas
Beyond swaps, Jupiter processes two additional event categories that carry valuable trading signal. Limit order events reveal pending orders, fill prices, and cancellation patterns — data that exposes the order book depth invisible to most traders. DCA events reveal recurring swap schedules, their execution cadence, and accumulated volumes. Both event types are delivered with the same pre-parsed JSON structure through Subglow, with all fields extracted and labeled.
// Limit order fill event
// DCA fill event
Limit order fills reveal execution prices that diverge from market — a signal for arbitrage bots. DCA fill events expose predictable recurring flows: if a whale has a 30-cycle DCA buying SOL with USDC, you know 23 more fills are coming at regular intervals. Both event types include the user_wallet, enabling wallet-level tracking for copy trading strategies.
Raw gRPC vs pre-parsed JSON
Raw Yellowstone gRPC delivers binary protobuf messages containing Borsh-encoded instruction data. To extract meaningful information from a Jupiter transaction, you need to deserialize the protobuf wrapper, locate the Jupiter instruction within the transaction's instruction array, read the 8-byte discriminator to identify the event type, then deserialize the remaining bytes using Jupiter's IDL to extract field values. You also need to resolve account indices, decode the route plan structure, and convert raw amounts using each token's decimal configuration.
This parsing pipeline adds 15–30ms of execution latency to every event your bot processes. In competitive trading environments — arbitrage, copy trading, MEV — that overhead is the difference between capturing an opportunity and missing it. Pre-parsed JSON eliminates 15–30ms parsing overhead by moving all deserialization server-side, delivering structured data that your bot can act on immediately.
Subglow handles protobuf decoding, Borsh deserialization, instruction discriminator mapping, account resolution, route plan extraction, and amount labeling at the source. Your bot receives a clean JSON object and can start executing trading logic in the same millisecond the event arrives.
// With raw Yellowstone
// With Subglow
Pre-parsed JSON eliminates 15–30ms parsing overhead.
Subglow handles Borsh deserialization, protobuf decoding, route plan extraction, account resolution, and amount labeling at the source. Your bot receives structured Jupiter events and can focus entirely on execution logic. Compare plans →
Use cases for Jupiter gRPC streaming
Jupiter's position as the dominant swap aggregator makes its transaction stream one of the most versatile data sources on Solana. The route plan data, combined with user wallet addresses and execution amounts, enables use cases that individual DEX streams cannot support alone. Here are four high-value applications that teams build on Jupiter gRPC data.
Arbitrage detection
Jupiter routes expose which DEXs provided liquidity for each swap and at what split percentages. When Jupiter sends 70% through Raydium and 30% through Orca, the price differential between those venues is the arbitrage signal. Monitor route plans in real-time to detect cross-DEX pricing discrepancies the moment they form. Combine with direct DEX pool subscriptions to confirm the opportunity before executing.
Arbitrage guide →Copy trading
Most whale swaps route through Jupiter regardless of the underlying venue. A single Jupiter subscription captures the aggregate trading activity of any wallet. Track high-value wallets by filtering the user_wallet field, mirror their swap parameters, and submit your copy trade in the same slot window. The low execution latency of gRPC data gives copy bots the speed to match whale entries before the market moves.
Copy trading guide →DEX volume analytics
Every Jupiter swap event includes the route_plan array showing which venues processed volume. Aggregate this across all Jupiter swaps and you have a real-time view of where Solana liquidity flows — by DEX, by token pair, by time window. This data powers dashboards, research reports, and trading strategies that depend on understanding market structure dynamics.
View documentation →MEV detection
Sandwich attacks and front-running are most common on Jupiter because it carries the highest swap volume. By streaming Jupiter transactions with low execution latency, MEV detection systems can identify suspicious patterns — consecutive buy-sell-buy sequences targeting the same token within adjacent slots. Alert platforms use this data to notify users when their swaps were sandwiched, while MEV bots use it to identify profitable opportunities.
MEV detection guide →Frequently asked questions
What is the Jupiter v6 program ID for Yellowstone gRPC?
The Jupiter v6 program ID is JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4. Use this address in your SubscribeRequest account_include filter to receive all Jupiter swap, limit order, and DCA transactions through your Yellowstone gRPC stream. This single program ID covers the core Jupiter aggregator routing engine.
Can I stream Jupiter limit orders and DCA events via gRPC?
Yes. Jupiter limit orders and DCA (Dollar Cost Averaging) operations are executed through the same Jupiter v6 program. Subscribe to transactions that include JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4 in your account_include filter and parse the instruction discriminator to distinguish between swap, limit order create/fill/cancel, and DCA open/close/fill events.
How fast is Yellowstone gRPC vs WebSocket for Jupiter swaps?
Yellowstone gRPC typically delivers Jupiter swap events within 5–10ms of slot confirmation. WebSocket subscriptions add 50–200ms of overhead from JSON serialization and connection management. Standard RPC polling adds 1–5 seconds of delay. For arbitrage detection and copy trading, low execution latency data from gRPC lets your bot react before competing bots even receive the event.
Does Subglow pre-parse Jupiter swap data?
Yes. Subglow delivers pre-parsed Jupiter events as structured JSON. Instead of raw protobuf with Borsh-encoded instruction data, you receive labeled fields like input_mint, output_mint, in_amount, out_amount, route_plan, slippage_bps, and user_wallet. Pre-parsed JSON eliminates 15–30ms parsing overhead, giving your bot a measurable execution latency advantage.
Why should I monitor Jupiter instead of individual DEXs?
Jupiter is the #1 Solana DEX aggregator by volume — the majority of swap volume on Solana routes through Jupiter regardless of which underlying DEX provides liquidity. Monitoring Jupiter gives you a single stream that covers Raydium, Orca, Lifinity, Meteora, and dozens of other venues. Instead of subscribing to each DEX separately, one Jupiter subscription captures the aggregate flow.
Is the Subglow gRPC endpoint Yellowstone (Dragon's Mouth) compatible?
Yes. Subglow's gRPC endpoint at grpc.subglow.io is fully Yellowstone (Dragon's Mouth) compatible. You can use the standard @triton-one/yellowstone-grpc client for Node.js or the yellowstone-grpc-client crate for Rust with no modifications. The same SubscribeRequest format, the same filter syntax, and the same streaming protocol — with pre-parsed JSON available as an additional layer.
Continue reading
Pump.fun gRPC Guide
Monitor token launches, buys, and sells in real-time with Yellowstone gRPC filters.
Read more →Raydium gRPC Guide
Stream AMM and CLMM swap events, pool creation, and liquidity changes.
Read more →Filter Reference
Complete guide to SubscribeRequest filters — account, transaction, slot, and block subscriptions.
Read more →TypeScript Integration
Type-safe Solana gRPC with full TypeScript definitions and autocomplete support.
Read more →Arbitrage Guide
Detect and execute cross-DEX price discrepancies using real-time gRPC streams.
Read more →Documentation
Full API reference, authentication, endpoints, and schema documentation.
Read more →Every swap. Every route. Every millisecond.
Pre-parsed Jupiter events with route plans, amounts, and wallet data. Low execution latency. Zero Borsh decoding.