How Jupiter DEX aggregator routes swaps across Solana liquidity

05 September 2026

Solana holds over $30 billion in total value locked across dozens of automated market makers. No single venue holds all the liquidity for any pair. Jupiter, the dominant aggregator on the chain, solves this fragmentation by scanning every available pool and splitting orders across them.

The problem is straightforward. A trade that moves 10,000 USDC through a single Raydium pool might incur 2% slippage. The same trade routed across four venues might cost 0.3%. Jupiter’s algorithm calculates the cheapest path in real time, factoring in pool reserves, fee structures, and network congestion.

The three AMM designs Jupiter works with

Raydium uses the standard constant-product formula - x * y = k. This is the simplest design. Liquidity is distributed evenly across the entire price curve. Large trades push price significantly because the curve is flat. Raydium pools tend to have the deepest liquidity for blue-chip pairs like SOL-USDC, but the price impact for mid-size trades can still be painful.

Orca introduced concentrated liquidity on Solana. Liquidity providers can set price ranges. A pool might concentrate all its capital between $20 and $30 for a SOL-USDC pair. Within that band, the effective depth is much higher than a constant-product pool with the same total value locked. Outside the band, the pool offers almost no liquidity. This design means tighter spreads for stable pairs but sudden slippage if price moves outside the concentrated zone. Jupiter accounts for this by checking where the current price sits relative to each Orca pool’s range.

Meteora adds dynamic fees. The fee percentage adjusts based on pool volatility and utilization. During calm markets, a Meteora pool might charge 0.01%. During volatile periods, the same pool could rise to 0.5%. The fee change is algorithmic, not manual. This creates an extra variable in Jupiter’s routing decision - a cheap route on one AMM might become expensive if Meteora’s fee has shifted since the last block.

How the routing algorithm works

Jupiter does not simply pick the pool with the best quoted price. It performs a multi-hop search. The algorithm considers direct swaps on a single venue, but also two-hop routes - swap token A for token B on Raydium, then token B for token C on Orca. Three-hop routes are rare but possible for obscure pairs.

The search space is large. Jupiter’s backend maintains a graph of every tradable pair on every supported AMM. When a user submits a swap, the algorithm runs a modified shortest-path search. It estimates the output for each possible route using each venue’s current reserves and fee parameters. The output estimates include slippage projections based on the trade size relative to each pool’s depth.

After finding the optimal route, Jupiter can split the trade across multiple paths simultaneously. A 50,000 USDC trade might send 30,000 through a Raydium pool, 15,000 through an Orca concentrated pool, and 5,000 through a Meteora dynamic-fee pool. Each leg executes in the same transaction. The user receives a single output token.

Why aggregation matters more on Solana

Ethereum’s liquidity is concentrated on Uniswap and Curve. Solana’s is spread across Raydium, Orca, Meteora, Lifinity, Phoenix, and dozens of smaller venues. No single AMM holds dominant share for most pairs. A trade routed through only Raydium might miss better pricing on Orca or Meteora.

The speed of Solana also changes the aggregation game. On Ethereum, a split trade across multiple venues requires multiple transactions or a complex multi-call contract. On Solana, all legs execute in one atomic transaction. Jupiter can split a trade into ten pieces across five venues and settle everything in under a second. This speed advantage means the algorithm can recalculate routes between blocks, reacting to pool changes that happen every 400 milliseconds.

Fragmentation is not just a nuisance. It is a structural feature of Solana’s permissionless design. Anyone can deploy a pool. Jupiter turns that chaos into a single interface. The user does not need to know whether their trade used Raydium’s constant-product math, Orca’s concentrated range, or Meteora’s dynamic fee. They see one swap, one output amount, one transaction.

The trade-off is trust. Jupiter must compute the route off-chain and submit the transaction. Users rely on Jupiter’s backend to return an honest quote. Jupiter publishes its routing code and allows third-party verification, but the default user experience is still a centralized server computing the best path. On a chain where every venue is open, the aggregator itself remains a black box for most users.

Back to solana