Jupiter and DEX routing, explained

The short answer

Jupiter is a DEX aggregator, not a DEX—it holds no liquidity itself. When you request a swap, its Metis routing engine scans 30+ integrated Solana venues (Raydium, Orca, Meteora, PumpSwap, and dozens more), computes the cheapest path, and can split a single trade across multiple pools or hop through an intermediate token to get there. All of that gets packed into one transaction you sign once (Eco). Ultra Mode automates slippage, priority fees, and routing for a fee of 0–0.1% on top of whatever the underlying pools already charge; Manual Mode exposes every parameter directly.

How a route actually gets built

Metis runs off-chain, maintaining a live liquidity graph across every integrated venue, and returns an optimized path through its quote API. Solana imposes real constraints on this—transactions are capped at roughly 1,232 bytes in legacy format (about 1,644 bytes with version-0 transactions and address lookup tables), and every venue a route touches consumes some of that budget for program IDs and account references. Jupiter's router uses lookup tables to compress those references, fitting 4–6 hops into a single transaction where the older format would only allow 2–3 (Eco).

On a large or illiquid trade, Metis will split-route: part of the order fills through one pool, the rest through a different path, all inside the same transaction—useful when no single venue has enough depth to fill the whole size without heavy price impact.

Ultra Mode vs. Manual Mode

Ultra Mode handles slippage tolerance, priority-fee estimation, and route selection automatically, and charges a fee of roughly 0–0.1% of the trade—usually more than offset by the pricing improvement from aggregation (MEXC). Some Ultra swaps route through Jupiter Z, a request-for-quote system where a market maker pays the transaction fee directly, making that leg of the swap gasless (Jupiter docs). Manual Mode gives full control over the same parameters a Metis quote exposes—slippage in basis points, an explicit priority fee, and even a Jito tip for faster inclusion. Either way, Jupiter's own fee is a separate line item from the AMM fee charged by whichever pool the trade actually routes through—see the fee breakdown guide for how every layer stacks.

Integrators can add their own cut on top using a platformFeeBps parameter tied to a referral account—so a wallet or terminal you're swapping through may be charging a fee that never shows up as a distinct line in Jupiter's own numbers.

Slippage and price impact, precisely

A quote's priceImpact reflects how much a trade of that size moves the price across the route it takes—distinct from slippageBps, the tolerance you're willing to accept between quote and execution. Jupiter also exposes otherAmountThreshold, the actual minimum output your transaction will accept once slippage tolerance is applied, and restrictIntermediateTokens, which forces multi-hop routes through only highly liquid intermediate tokens instead of thin, random ones—reducing failed transactions at the cost of occasionally missing a marginally better price (Jupiter developer docs).

For the execution decision—when to re-quote, resize, reroute, or change the protected boundary—continue with slippage, price impact, and failed swaps, then use choosing a route mid-trade to compare current alternatives by protected output, costs, permissions, and failure surface.

What a Jupiter-routed journal must reconstruct

1. The route plan. Every venue and hop the transaction actually touched, not just the input and output tokens.
2. Fee layers, kept separate. Jupiter's own fee, any integrator platform fee, the underlying AMM fee, and the priority fee or Jito tip—four distinct numbers, not one.
3. Slippage tolerance vs. realized price impact. What you set going in against what the fill actually cost.
4. Token trust tag at time of trade. Verified, Unverified, or Banned—useful context if a token's status changes after the fact.

Official sources