Jupiter vs 1inch: How Solana and EVM Swap Routing Differ

{"excerpt":"Jupiter vs 1inch routing compared: how Metis and Pathfinder split orders across Solana and EVM pools, and what it costs you in fees and slippage.","tags":["Jupiter","1inch","DEX Routing","Solana","EVM"],"cover":"nodes","content":"A swap on Jupiter and a swap on 1inch look identical from the outside — you paste a token pair, get a quote, sign a transaction. Underneath, the two routers are solving fundamentally different optimization problems because Solana and EVM chains hand them different constraints. That difference shows up directly in your execution price, and most integrators never look past the quote endpoint to understand why.\n\n## How Metis builds a route\n\nJupiter's routing engine, Metis, runs a modified version of a graph-search algorithm over Solana's DEX liquidity — Orca whirlpools, Raydium CLMM and CPMM pools, Phoenix order books, OpenBook, and a long tail of smaller venues. Because Solana transactions are cheap and account access is explicit, Metis can afford to split a single order across 3-5 hops and multiple pools in one atomic transaction without the split itself becoming the dominant cost. A $50k USDC-to-SOL swap routinely gets sliced into four or five legs: maybe 40% through a Raydium CLMM pool, 35% through an Orca whirlpool, and the remainder through Phoenix for the tighter spread on the last chunk. The account-loading model on Solana means adding a fourth or fifth hop costs you compute units, not a linear increase in gas the way it would on an EVM chain.\n\nThe tradeoff is that Metis has to account for Solana-specific execution risk that doesn't exist on EVM: transaction landing. A route computed against current pool state can go stale in the time it takes to reach a leader, especially during congestion, which is why Jupiter's quote responses carry a priceImpactPct and short quote validity window, and why slippage tolerance on Solana swaps tends to run tighter in calm markets but needs more headroom during volatility. If you're building anything that depends on consistent block timing to price these routes correctly, the validator-level differences matter more than people assume — see our breakdown of Jito vs Firedancer validator latency for what's actually driving that variance.\n\n## How Pathfinder builds a route\n\n1inch's Pathfinder solves a related but more expensive problem: it has to price in gas explicitly, per hop, per chain, because EVM gas isn't a rounding error the way Solana compute units are. Pathfinder models each candidate route as a directed graph across DEXs — Uniswap V2/V3, Curve, Balancer, Sushi — and prunes paths where the marginal price improvement from an extra hop doesn't clear the added gas cost at current base fee. That's the whole reason Pathfinder exists as a distinct algorithm from a naive best-single-pool router: on Ethereum mainnet, splitting a $50k swap across four pools at 40-60 gwei can burn $30-80 in gas just from the additional swap calls, so the algorithm has to net that against slippage savings before it ever suggests the split.\n\nThis is also why 1inch's advantage is more visible on L1 Ethereum during low-gas windows and less visible — sometimes irrelevant — on L2s like Arbitrum or Base, where gas is cheap enough that aggressive splitting rarely costs more than it saves. On low-gas L2s, 1inch and a simple single-DEX router converge in execution quality far more often than on mainnet.

// Jupiter quote — note the multi-leg routePlan even for a mid-size order
GET /v6/quote?inputMint=USDC&outputMint=SOL&amount=50000000000
{
  "outAmount": "331245123",
  "priceImpactPct": "0.041",
  "routePlan": [
    { "swapInfo": { "label": "Raydium CLMM" }, "percent": 40 },
    { "swapInfo": { "label": "Orca Whirlpool" }, "percent": 35 },
    { "swapInfo": { "label": "Phoenix" }, "percent": 25 }
  ]
}

// 1inch quote — gas-aware, single dominant path unless splitting clears gas cost
GET /v5.2/1/quote?src=USDC&dst=WETH&amount=50000000000
{
  "toAmount": "18452301122334455",
  "gas": 187500,
  "protocols": [[[{ "name": "UNISWAP_V3", "part": 100 }]]]
}

Comparison table

Dimension	Jupiter (Metis)	1inch (Pathfinder)
Chain environment	Solana only	15+ EVM chains
Split depth	Often 3-5+ pools per order	1-3 pools, gas-gated
Dominant cost variable	Compute units, transaction landing risk	Gas price, per-hop gas overhead
Route staleness risk	Real, ties to block/leader timing	Low, mempool-based, MEV risk instead
Best case for splitting	Mid-large orders on volatile pairs	Low-gas windows or L2s
Failure mode	Landed tx with stale price / high slippage	Reverted tx from front-running or gas spike
Aggregation source	DEX + order book (Phoenix, OpenBook)	DEX only, no native order books

Fees and slippage in practice

Neither router charges a platform fee by default at the protocol layer, but both let integrators tack on a referral fee via the API, and both are vulnerable to different flavors of value leakage. On Jupiter, the leak is usually slippage from stale quotes on fast-moving pairs — a quote that's 400ms old during a volatility spike can be meaningfully off, so production systems should requote right before signing, not cache aggressively. On 1inch, the leak is MEV: unless you're routing through Fusion (1inch's intent-based, MEV-protected flow) or a private RPC, a visible mempool transaction on a good split route is a sandwich attack waiting to happen.

If you're running size regularly, the router choice matters less than the infrastructure around it. Real-time pool state, low-latency quote refresh, and fallback routing when one aggregator's API degrades are what actually protect execution quality — that's the kind of plumbing we build under infrastructure and data services, and it's the same reasoning that makes Yellowstone gRPC a better fit than polling websocket RPC once you're routing meaningful volume on Solana.

Which to pick when

If you're building or trading on Solana, use Jupiter — there's no serious competing aggregator with comparable liquidity coverage, and Metis's willingness to split deep across pools generally beats manual routing for anything above a few thousand dollars. If you're on Ethereum mainnet during normal gas conditions, 1inch's gas-aware pruning genuinely outperforms naive routers on net execution price, especially on order sizes where a bad split would eat the savings. On L2s, the gap narrows enough that router choice becomes secondary to RPC latency and slippage settings.

For a market-making or automated trading system that touches both environments, don't hardcode one aggregator — quote both where the chain allows it, treat the result as one signal among several, and build monitoring that flags when a route's realized price deviates from quote by more than your tolerance. We wire exactly that kind of cross-venue routing logic and monitoring into Solana market-making systems and the trading dashboards that sit on top of them, and if you're curious how liquidity provisioning looks on the perp side rather than spot swaps, the mechanics in how the Hyperliquid HLP vault works are a useful contrast.

Aggregator APIs change their splitting behavior and fee schedules without much warning, so whatever you integrate today needs someone watching it — that's what our support and maintenance retainers are actually for if you'd rather not find out about a routing regression from a support ticket."}