The Jupiter API for real-time aggregator swap data on Solana
Jupiter doesn't run a pool. It routes through everyone else's. That's why a Jupiter swap stream is the closest thing Solana has to a unified DEX feed: one program, four route instructions, and roughly half the spot volume on the chain flowing through it on any given day. The catch is that Jupiter's swap is a meta-instruction. It packs a sequence of inner swaps across Raydium, Orca, Meteora, Phoenix, and a long tail of other AMMs into one transaction, then settles the user's net delta against a shared accounts table. Decoding that without an IDL is a slog. We've already done it. NoLimitNodes ships parsed Jupiter route events over gRPC, with the full DEX hop list, input/output mints, and the effective price already computed. Delivered on slot landing to your callback.
- Jupiter Aggregator v6JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4, The current production aggregator. Handles route, sharedAccountsRoute, exactOutRoute, and routeWithTokenLedger
- Jupiter v6 alt deploymentJUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN, Secondary v6 program ID seen on a subset of integrator routes
- Jupiter Limit Order v2j1o2qRpjcyUwEvwtcfhEQefh773ZgjxcVRry7LDqg5X, Limit order fills route through here. Fills land as a swap once the price condition triggers
- Jupiter DCADCA265Vj8a9CEuX1eb1LWRnDT7uK6q1xMipnNyatn23M, Dollar-cost average orders. Each scheduled fill emits a route through Jupiter v6
The Jupiter events you can stream
every decoded route, plus Limit Order v2 fills and DCA legs
| Event | Type | Description | Frequency |
|---|---|---|---|
| route | instruction | Standard aggregator swap. Carries the full RoutePlanStep array, input/output mints, slippageBps, and platformFeeBps. | Very high |
| sharedAccountsRoute | instruction | Shared-accounts variant used by integrators (Phantom, Solflare, Bull). Same payload, different account layout to save space. | Very high |
| exactOutRoute | instruction | Exact-out swap. Specifies the output amount and lets Jupiter solve for the input. Common in payment flows and dust sweepers. | Medium |
| routeWithTokenLedger | instruction | Route variant that uses a token ledger account to track balances across composed instructions. Used by program-to-program callers. | Medium |
| sharedAccountsExactOutRoute | instruction | Shared-accounts plus exact-out combined. Lower frequency, surfaces wallet-app payment intents. | Low |
| SwapEvent (CPI log) | event | Anchor CPI event emitted on every inner-DEX hop. Contains amm program ID, input mint, output mint, in amount, out amount. | Very high |
| fillOrder (Limit Order v2) | instruction | Limit order fill. Triggers when the maker price hits a Jupiter-found route. Pairs with a v6 route in the same tx. | Medium |
| DCA fill | instruction | Scheduled DCA leg. Each scheduled fill produces a v6 route plus a DCA program log with the order ID. | High |
Jupiter streaming performance
last reviewed 2026-04-28
What a Jupiter route actually looks like on chain
A Jupiter swap is one transaction with one outer call into JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4. That outer call doesn't do the trade. It dispatches. The actual swaps are inner instructions: a CPI into Raydium AMM v4 here, an Orca Whirlpool tick crossing there, sometimes a Meteora DLMM bin step, sometimes a Phoenix orderbook fill. Each inner program runs its own swap math against its own pool state, and the outer call collects the deltas.
That's why a single Jupiter signature can move 7 different mints across 4 different DEXes and still settle as one user-visible trade. It's also why a naive parser sees a v6 route and reports “swap” without knowing which pool actually got hit. The interesting data lives one level deeper.
The four route variants are route, sharedAccountsRoute, exactOutRoute, and routeWithTokenLedger. Wallet integrators (Phantom, Solflare, Bull) lean on sharedAccountsRoute because it packs more into a single transaction. Payment flows use exactOutRoute when they need a precise output. Everyone else uses the plain route. All four end up emitting an Anchor SwapEvent log per inner hop, which is the cleanest single source of truth for what actually happened.
The route instruction shape, decoded
A v6 route instruction carries a small header and a RoutePlanStep[]. The header has the input amount, the quoted output amount, the slippageBps, and the platformFeeBps if an integrator stamped one on. The plan steps describe the hops, in order.
| Field | Type | What it tells you |
|---|---|---|
| inAmount | u64 | User's input, raw units |
| quotedOutAmount | u64 | What the quote-api promised |
| slippageBps | u16 | Slippage tolerance the user accepted |
| platformFeeBps | u8 | Integrator skim, if any |
| RoutePlanStep[] | vec | Per-hop swap label, percent, input/output index |
The plan-step entries are where the routing intelligence lives. Each step has a swap label (e.g. Raydium, Whirlpool, MeteoraDlmm, Phoenix), a percent of the input allocated to that hop, and an in/out token index that maps into the accounts list. A 100/0 split means single-hop. A 60/40 split is a parallel route across two AMMs. A 50/50 chained into another 50/50 is a four-leg, two-hop tree.
Reconstructing the actual fills means correlating each plan step to the inner CPI that ran. We do that on our side and emit one event per hop with the inner program ID, the pool, the in/out mints, the amount in, and the amount out. Sum the legs and you have the route's real effective price; subtract from quotedOutAmount and you have the realized slippage.
Why aggregator data matters more than DEX-by-DEX feeds
On a typical Solana day, Jupiter handles a meaningful chunk of all spot DEX volume. If you're building anything that needs a market-wide view (price discovery, MEV detection, slippage attribution, copy trading) the Jupiter feed gets you closest to a unified order flow with the least integration work.
Three reasons it's the right starting point:
Price discovery. Quoted vs executed price, sampled across thousands of routes per second, gives you a noise-resistant measure of where each token actually clears. Pool-level swap data tells you what one venue did; the aggregate tells you what the market did.
Slippage attribution. Every route has a quoted out, an actual out, and a list of hops. Subtract, divide, and you get a per-hop slippage number. That breaks down where execution quality is leaking, and whether it's the routing or the venue.
MEV signal. Sandwiches around Jupiter routes remain a thing. The pattern is recognizable: a v6 route sits between two same-pool swaps from another wallet, often inside the same slot. You can't see that without subscribing to both Jupiter and the underlying pools, which is why we recommend pairing this stream with the Raydium, Orca, and Meteora feeds when you care about MEV.
Cross-DEX routing patterns you'll see in the stream
Single-hop
One plan step, 100% allocation, into a single AMM. The most common pattern. Roughly two-thirds of routes take this shape on a normal day. If you're sampling Jupiter to estimate per-venue volume, this is your cleanest signal.
Parallel split
Same input mint, same output mint, two or more pools, split by percent. Jupiter does this when one pool can't absorb the full size without too much price impact. The classic 60/40 across Raydium AMM v4 and CPMM is the textbook case.
Multi-hop chain
A → B → C, where the intermediate token is usually USDC or SOL. Common for long-tail mints with no direct pair against the user's input. Each hop is a separate plan step with its own pool, and the intermediate balance lives in the user's ATA between steps.
Tree route
The interesting one. Jupiter splits across two pools, then re-converges through a third. Up to seven legs in extreme cases. Almost always large notionals where saving 5-10bps of slippage justifies the extra compute. If you're running execution analytics, these are the routes worth replaying.
What teams build with the Jupiter stream
The teams we see using this feed in production fall into four camps, with a fifth growing fast.
Copy traders. Filter on a wallet, get every Jupiter swap that wallet executed, mirror it. The stream gives you the full route, so you can replay the same hops if you want, or just take the input/output mints and find your own path. Latency matters here. We see copy bots fire follow-on bundles within ~30ms of the source signature confirming.
Execution analytics teams. Each route has a quoted out, a realized out, and a hop list. Bucket by integrator, by token pair, by route shape, and you have an ongoing view of who actually delivers good fills. Useful internally if you're a wallet picking integrators; useful externally if you're publishing benchmarks.
MEV researchers. Sandwich detection, JIT detection, backrun analysis. The Jupiter stream alone tells you the victim; paired with pool-level streams it tells you the attacker.
Volume dashboards and price oracles. Birdeye and DexScreener pull from streams that look very similar to this one. If you're building anything that needs a clean per-token spot tape, sourcing it from Jupiter routes is faster than rolling up every individual AMM.
Trading-loss attribution. The fastest-growing use case. Wallet apps and discretionary traders want to know how much of their realized loss was bad price vs bad timing. The stream gives you the price; pair it with mempool data and you have the timing.
Frequently asked questions
Related products
Most Jupiter routes touch Raydium. Subscribe alongside to see both the aggregated and the underlying pool-level fills.
Pair with Jupiter to attribute volume between aggregated and direct flow on Solana's second-largest CLMM.
Bin-based DLMM events. Jupiter routes through DLMM heavily for stablecoin pairs.
Browse every decoded Solana program we expose, including Jupiter v6 and the DEXes it routes through.
The streaming layer behind every NoLimitNodes Jupiter subscription.
18 curated topics across DEXes, lifecycle, and system events. The catalog hub.
Start streaming Jupiter routes in under 60 seconds
Pro plan from $49/mo includes 2 parsed streams (pick Jupiter plus any of Raydium, Orca, Meteora, PumpSwap, and more). Ultra adds 20 streams and 30 hours of custom dev time.