If you're building anything on Solana that does swaps, you'll be using a DEX aggregator. The aggregator turns "I want to swap X for Y" into the best route across multiple DEXes, automatically handling routing complexity that would otherwise be your problem. Jupiter is the dominant choice, but it's not the only one, and the question of which to use depends on what you're optimising for.
This piece covers the Solana DEX aggregator landscape: who's competitive, what each does well, and how the aggregator choice affects your application's behaviour.
A note on naming before we dive in: people search for this functionality under a lot of names — solanaswap, jupiterswap, swap jupiter, plain "dex sol" — and they're all variations on the same theme. There's no single product called "Solanaswap"; the term is shorthand for "swap something on Solana," which in practice means going through an aggregator like Jupiter. We'll use the proper product names throughout, but if you arrived here searching for solanaswap or jupiterswap specifically, this is the right page.
What DEX Aggregators Do
The basics: an aggregator searches across many DEXes and routing paths to find the best output for your swap. The components:
- Quote API — given a pair and amount, return the best route with expected output
- Routing engine — searches the space of possible paths
- DEX integrations — pre-built connections to all the major Solana DEXes
- Transaction construction — builds a ready-to-sign transaction for the chosen route
The aggregator handles the complexity. Your application just specifies "swap X for Y" and gets a transaction back.
Aggregators Worth Knowing About
Jupiter. The dominant aggregator. Strong routing, wide DEX coverage, mature API. The default choice for most builders.
1inch. Originally Ethereum-first, now multi-chain including Solana. Less Solana-mature than Jupiter but still credible.
Direct DEX integration. Not technically an aggregator, but worth mentioning: for some specific use cases, going direct to a DEX (Raydium, Orca) can be faster than going through an aggregator. Trade-off is you handle routing yourself.
OpenBook (formerly Serum). Order-book DEX rather than AMM. Different model; relevant for traders who want order books.
For 95% of use cases, Jupiter is the right answer. The exceptions involve specific high-frequency or specialised needs.
Why Jupiter Dominates Solana
Jupiter's strengths:
Comprehensive DEX coverage. They integrate with most Solana DEXes — Raydium, Orca, Meteora, Lifinity, Phoenix, many others. Other aggregators usually have narrower coverage.
Strong routing quality. Their search algorithms find competitive routes including multi-hop paths that simpler aggregators miss.
Mature API. Quote and swap APIs are stable, well-documented, easy to integrate.
Versioned transactions / ALTs. They use modern Solana transaction features that allow more accounts per transaction.
Continuous improvement. Active team that keeps adding features and integrations.
For most Solana applications doing swaps, Jupiter is the path of least resistance and usually the best result.
When You Might Skip Jupiter
A few cases where direct integration beats aggregation:
Predictable single-pair swaps. If you always swap SOL → USDC on Raydium, going direct skips Jupiter's routing layer. Saves a few hundred ms.
Custom routing logic. If you have a theory about routes Jupiter is missing, you can implement custom routing. Rare but exists.
Specific DEX features. Some features (concentrated liquidity LP management on Orca, options on PsyOptions) need direct integration. Aggregators don't expose them.
Latency-extreme applications. Sub-100ms reactive bots need direct integration. Jupiter API call adds latency.
For most applications, none of these apply. Use Jupiter.
How Your RPC Affects Jupiter Swaps
Common misconception: "I'm using Jupiter; the swap quality is what Jupiter gives me." This is wrong.
Jupiter constructs the transaction. You submit it through your RPC. The RPC affects:
- Whether the transaction lands quickly — faster RPC = better fills (price didn't move)
- Whether you get sandwiched — Anti-MEV RPC = tighter fills than expected; non-MEV-protected RPC = sandwich tax
- Whether the transaction lands during congestion — SWQoS-aware RPC = inclusion under load
A good Jupiter route submitted through a bad RPC gives you bad fills. Pair Jupiter with a write-optimised RPC.
Routing Quality Comparison
For comparing aggregators directly, you want to:
- Pick a representative set of swap pairs
- Get quotes from each aggregator for the same pair and amount
- Compare expected outputs
The differences are usually small for major pairs (where everyone routes through the same big pools). The differences are larger for niche pairs (where coverage varies).
Jupiter typically wins on coverage; for major pairs, other aggregators are competitive on routing quality.
DEX Coverage Comparison
Jupiter's integrated DEXes (partial list, varies over time):
- Raydium (AMM v4 and CLMM)
- Orca (Whirlpool concentrated liquidity)
- Meteora (DLMM, Dynamic AMM, Stable Pools)
- Lifinity (proactive AMM)
- Phoenix (order book)
- Saber (stablecoin)
- Many others
Smaller aggregators usually cover the top 3-5 DEXes well; cover the long tail less well.
For long-tail tokens, Jupiter usually has better routes. For top-pair major swaps, all credible aggregators are similar.
Integration Cost
Jupiter API integration. Maybe 30-60 minutes from "I've never used it" to "I have a working swap." Quote → swap → submit. Documentation is good.
Direct DEX integration. Hours to days depending on the DEX. You handle routing, account management, instruction construction.
Custom aggregator (rolling your own). Days to weeks. Usually not worth it unless you have very specific needs.
For most builders, Jupiter wins on integration cost alone.
What to Do This Week
If you're integrating an aggregator:
- Use Jupiter unless you have a specific reason not to. Default for 95% of cases.
- Pair with an Anti-MEV write RPC. Jupiter's good routing is wasted if you get sandwiched.
- Set
dynamicComputeUnitLimit: true. Jupiter routes can need varied CU. - Use
dynamicSlippage: true. Lets Jupiter pick slippage based on route characteristics. - Test the integration end-to-end. Quote → swap → sign → submit → confirm. Verify each step.
- Build per-signature telemetry. Track which swaps land, what slippage was set, what the fill was vs expected.
Try BoltTx for Jupiter Submission
Jupiter for routing, BoltTx for submission:
import { Connection, VersionedTransaction } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
// Get Jupiter swap transaction (see Jupiter's docs)
// ...
const tx = VersionedTransaction.deserialize(swapTransactionBuf);
tx.sign([wallet]);
const signature = await connection.sendTransaction(tx, {
skipPreflight: true,
maxRetries: 0,
});
Native Anti-MEV routing means Jupiter's routes don't lose to sandwich attacks during submission. Free tier signup — pair with whatever read provider you prefer.
FAQ
Should I always use Jupiter? For most cases, yes. Exceptions are specific high-frequency or specialised needs.
Does Jupiter charge fees? The Jupiter API itself is free. You pay swap fees on the actual DEXes plus your priority fees / tips.
What about 1inch on Solana? Less Solana-mature than Jupiter. Reasonable for cross-chain teams using 1inch generally; for Solana-first apps, Jupiter is still better.
Can I cache Jupiter quotes? Yes for non-time-sensitive use. For latency-sensitive bots, fetch fresh.
What's dynamicSlippage and should I use it?
Yes — it lets Jupiter pick slippage tolerance based on the route, often better than your fixed value.