Use Jupiter on Solana: Swaps, Limit Orders and DCA

Jupiter is Solana's dominant DEX aggregator. This guide covers how its routing actually works, the difference between Ultra and Manual mode, what each product really costs, and the specific ways a Jupiter trade goes wrong.

What Jupiter actually is

Jupiter is not an exchange with its own order book or its own liquidity pools. It is a router: you tell it what you want to sell and what you want to buy, and it searches Solana's liquidity — AMMs, concentrated-liquidity pools, request-for-quote market makers — for the best execution, then packages the result into a single Solana transaction that you sign once.

That single-signature model is the most important structural difference from Ethereum DEXs, and it changes the whole risk profile. On Ethereum you first grant an ERC-20 allowance and then swap, leaving a standing permission behind. On Solana a swap is authorised and executed in one atomic transaction; there is no lingering allowance to forget about. The corresponding Solana-specific hazards are different — expiring blockhashes, priority-fee auctions, and token-account rent — and this guide covers those instead.

Jupiter has also grown well beyond swapping. The current product surface includes spot swaps, trigger (limit) orders, recurring orders (DCA), perpetuals, a lending market, prediction markets, token and price data APIs, and a spend/card layer. Most people only need the first three.

How the routing works: Juno, Metis, JupiterZ and Beam

Jupiter's execution stack is worth understanding because it explains why the same swap can behave very differently under different settings.

• Metis is Jupiter's on-chain routing engine — a self-learning router that splits an order across multiple pools and hops to minimise price impact.
• JupiterZ is Jupiter's request-for-quote layer, pulling firm quotes from 20+ professional market makers rather than from AMM curves.
• Juno is the meta-aggregator that sits above both. Jupiter's docs describe it as aggregating "across multiple liquidity sources, including Jupiter's proprietary routing engines: improved versions of Metis and JupiterZ," alongside external sources such as DFlow and OKX. Juno picks whichever produces the best net outcome.
• RTSE — the Real-Time Slippage Estimator — sets slippage for you. It is the third generation of Jupiter's automatic slippage system and, per the docs, uses "token categories, historical and real-time slippage data" while monitoring failure rates live, balancing trade success against price protection.
• Beam is Jupiter's own transaction-broadcast engine, sending trades through its own validator infrastructure. Jupiter reports it "lands in 0–1 block (~50–400ms)" against "1–3 blocks (~400ms–1.2s)" for previous broadcast methods.

The practical upshot: when you use Ultra mode you are not just getting a route, you are getting Jupiter's slippage estimation, priority-fee selection, MEV-protected broadcasting and landing infrastructure as a bundle. When you use Manual mode you are opting out of all of it.

What you'll need (prerequisites)

• A self-custodial Solana wallet — Phantom, Solflare or Backpack, or a hardware wallet with Solana support such as Ledger.
• SOL for network fees, priority fees and token-account rent. Roughly 0.05 SOL is a comfortable working buffer; a few cents' worth is not, because opening a token account for a new asset costs rent-exempt SOL that is locked (though refundable if you later close the account).
• The token you intend to sell, already in that wallet.
• The mint address of any token you are buying that is not a household name. Ticker collisions on Solana are constant and deliberate.

Step-by-step: a spot swap

1. Step 1: Reach the real Jupiter

   Type the domain rather than clicking a search result, and bookmark it. Solana's fee environment makes drainer sites cheap to operate at scale, and Jupiter is one of the most-cloned front ends in crypto. If a site asks you to "sync", "validate" or "claim" before it will let you swap, it is not Jupiter.

2. Step 2: Connect a Solana wallet

   Choose your wallet and approve the connection. Connecting is a read-only handshake — no transaction, no signature that moves funds. Because Solana has no persistent allowance model, connecting a wallet to a malicious site is less immediately dangerous than on Ethereum; the danger arrives at the signing step, where a drainer will ask you to sign a transaction that transfers your balances outright.

3. Step 3: Pick your mode — Ultra or Manual

   This is the single most consequential setting on the page. Per Jupiter's own comparison: Ultra Mode gives you slippage set "Auto (via Real-Time Slippage Estimator)", automatic transaction broadcasting, priority fees set automatically "to ensure high success without overpaying", MEV protection Jupiter describes as "best in class", and gasless swaps for most tokens. Manual Mode gives you custom slippage, custom broadcasting, custom priority fees and the ability to exclude specific AMMs from your route — but explicitly no MEV protection and no gasless swaps. Unless you have a concrete reason to hand-tune, Ultra is the correct default for almost everyone.

4. Step 4: Select tokens by mint address, not by ticker

   Paste the mint address for anything unfamiliar and cross-check it against a second source. Jupiter surfaces verification status and an organic-score signal alongside search results — use them, but treat them as a filter rather than an endorsement. Anyone can create a token called USDC. Our guides on checking token liquidity and detecting rug pulls cover the checks worth doing before you buy anything obscure.

5. Step 5: Enter the amount and read the quote properly

   Look at three numbers, not one. The output amount is what you expect to receive. Price impact is how much your own order moves the market — this is a real cost and it is not a fee, so it never appears in any fee table. Minimum received is the worst case the transaction will accept before it fails. If price impact is more than a fraction of a percent on a size you consider normal, the token's liquidity is thin and you should reduce the size.

6. Step 6: Set slippage — or, preferably, don't

   In Ultra mode, RTSE sets slippage dynamically from token category, historical and live slippage data, and real-time failure rates. Leaving it alone is usually better than guessing, because the estimator sees market conditions you cannot. If you switch to Manual and set slippage yourself, understand what you are authorising: slippage tolerance is a ceiling on how much worse than quoted the execution may be, and a high tolerance on Solana is an open invitation to sandwich bots. A 20% tolerance to "make the trade go through" is how people lose 20%.

7. Step 7: Sign, and read what you are signing

   Modern Solana wallets simulate the transaction and show the net balance change. Read it. The transaction should debit exactly the input token and credit the output token — nothing else. If the simulation shows additional token transfers, an unexpected account being set as an authority, or a warning that simulation failed, reject it.

8. Step 8: Verify on a block explorer

   Open the signature on Solscan or the Solana Explorer and confirm the balance changes match. Save the signature. Note that Solana transactions either succeed or fail — there is no "pending forever" state — so if you see nothing after a short wait, the transaction expired rather than being stuck.

Limit orders (Trigger) and recurring orders (DCA)

Jupiter's non-market order types are keeper-executed: you create an order, funds are held in a vault, and independent keepers execute it when your condition is met.

Trigger / limit orders. Jupiter runs two generations of this product and they behave differently. V1 triggers on the pool rate between two tokens and guarantees the output amount — when the price hits your level, a keeper executes and the bought tokens, minus fees, land in your wallet. V2 triggers instead on a token's USD price or market cap, and executes the fill through Ultra, which means it prioritises minimal slippage over a guaranteed amount — so the final output can differ from the estimate. V2 expiry options are documented as "10 minutes, 1 hour, 1 day, 3 days, 7 days (the default), 30 days, or a custom date." Note that default expiry: an order you forget about will expire in a week. Jupiter's API docs list a minimum of $10 equivalent for price orders.

Recurring orders (DCA). Two flavours: time-based, which executes at fixed intervals, and price-based, which executes when market conditions are met. Minimums per the docs are at least $10 per round with a minimum of two rounds. Slippage is not something you set once — "the keeper sets slippage per round from live market conditions at fill time." That is generally a good thing, but it means each round can execute at a slightly different effective cost, and a scheduled buy into a token that has become illiquid will execute at whatever the market offers.

Both order types share one non-obvious property: your funds sit in a program-owned vault until filled or cancelled. Cancelling returns them, but they are not in your wallet in the meantime and they are exposed to the order program's smart-contract risk for the duration.

Fees, and how each one is charged

Jupiter's fee structure is genuinely unusual in that the manual path is free and the managed path costs a few basis points. From the official docs:

• Manual Mode swaps: 0% Jupiter commission. The docs are explicit — "Manual swaps (Manual Mode) do not incur any Jupiter commission. You only pay Solana network fees and, if applicable, Jito tips."
• Ultra Mode swaps carry a fee that varies by token category. The published table: 0 bps for Jupiter-related routes (SOL or stables into JUP, JLP or jupSOL) and for pegged assets (LST-to-LST, stable-to-stable); 2 bps for SOL-to-stable; 5 bps for LST-to-stable; 10 bps for everything else; and 50 bps for new tokens within 24 hours of launch. Jupiter summarises the default band as "5 to 10 bps of the swap amount." Fees are taken in a preferred mint following a priority order of SOL, stablecoins, LSTs, bluechips, then other tokens.
• Limit orders: V1 charges "a flat 0.1% fee… to all Limit V1 orders", assessed only when the order actually executes. V2 charges a base fee of 0.03% on stablecoin pairs or 0.1% on other pairs, plus the Ultra routing fee of 0–0.5% since fills route through Ultra.
• Recurring / DCA: 0.1%, per Jupiter's developer documentation.
• Perpetuals: a base fee of "0.06% of trade size" charged on both opening and closing, plus a price-impact fee (a linear component that scales with trade size and an additive component when open-interest imbalance exceeds a threshold, both capped per asset), plus an hourly borrow fee calculated as "(Total Tokens Locked / Total Tokens in Pool) * Hourly Borrow Rate * Position Size (USD)" that compounds continuously while the position is open.
• Solana network fees are a fraction of a cent per signature, but priority fees during congestion and Jito tips for MEV-protected broadcasting are real and variable. Ultra sets these for you; in Manual mode, underpaying means your transaction expires and overpaying is money gone.
• Token account rent. The first time you receive any SPL token, Solana creates an associated token account funded with rent-exempt SOL. It is refundable when you close the account, but it is not free at the moment you trade.

These are the numbers the documentation states today. Fee parameters change, and the Ultra fee in particular is category-dependent — always read the fee line the interface shows you for your specific pair before confirming.

Security and pitfalls

• Ticker impersonation is the number-one loss vector. Solana token creation is nearly free, so fake versions of every popular token exist. Always paste the mint address.
• Slippage tolerance is an attack surface. Manual mode has no MEV protection by Jupiter's own description. A wide manual slippage setting on a low-liquidity pair lets a sandwich bot extract most of that tolerance. If you find yourself widening slippage repeatedly, the correct response is a smaller order, not a wider tolerance.
• Blind signing on hardware wallets. Solana transactions are often too complex for a hardware wallet screen to render meaningfully. If your device shows an opaque hash, you are trusting the software wallet's simulation entirely — so make sure that simulation is being shown and that you read it.
• Address poisoning. Attackers spray dust transfers from addresses that resemble your own to pollute your transaction history, hoping you will copy the wrong one later. See how to detect address poisoning.
• Unknown tokens appearing in your wallet. Airdropped spam tokens on Solana frequently route to a phishing site when you try to sell them. Ignore them; do not interact.
• Perps and leverage. Jupiter's perpetual exchange is a serious product with real liquidation risk, and the hourly compounding borrow fee makes holding positions expensive over time. It is not an extension of swapping; treat it as a separate discipline.
• Aggregator does not mean audited counterparty. Jupiter routes into third-party pools and market makers. Good routing cannot rescue you from buying a token that was designed to be unsellable.

Troubleshooting

• "Transaction expired" or nothing happened. Solana transactions are only valid for a limited blockhash window. If it expires, no funds moved and nothing is stuck. Retry, and let Ultra set the priority fee — or raise it manually if you are in Manual mode during congestion.
• "Slippage tolerance exceeded". The market moved past your ceiling between quote and execution. Retry rather than immediately widening slippage; if it fails repeatedly on the same pair, the pool is too thin for your size.
• Swap succeeded but I received less than quoted. Compare the quoted minimum received against what arrived. If it is above the minimum, the system worked as designed and the difference is price impact plus slippage, not a bug. V2 limit orders in particular do not guarantee an exact output amount.
• "Insufficient SOL" despite holding SOL. You need SOL for the fee and for any new token account's rent. If you are swapping all of your SOL, leave a buffer behind.
• My limit order never filled. Check whether it expired — the V2 default is 7 days. Also check whether the trigger condition is priced in USD or as a pool rate, because the two versions use different reference prices.
• My DCA round was skipped or filled at a bad price. Keepers set slippage per round at fill time and a round can fail if liquidity is inadequate at that moment. Review the order history in the interface rather than assuming the schedule ran cleanly.
• Funds are locked in an order I want back. Cancel the order in the interface; that closes the vault position and returns the deposited funds to your wallet.
• The token won't sell at all. That is a rug-pull signature, not a Jupiter problem. Jupiter cannot route through a transfer function that blocks you.

When not to use this route

• You want to trade on another chain. Jupiter is Solana-native. For an Ethereum or L2 swap, use an EVM aggregator; for cross-chain, use a bridge first — see bridging to Base as a worked example.
• You want to hand-tune the route across specific pools. Manual mode allows AMM exclusion, but if your strategy depends on granular venue control you are better off interacting with the individual DEX directly.
• You need guaranteed execution at a guaranteed size. On-chain orders can fail. If you are moving institutional size, an OTC desk or an RFQ counterparty gives you a firm fill; an aggregated on-chain route does not.
• You are buying a token minted minutes ago. The 50 bps new-token Ultra fee is the smallest of your problems. Fresh launches carry the entire spectrum of honeypot, mint-authority and liquidity-pull risk.
• You want yield, not a trade. A swap is not a yield strategy. If you want to earn on stablecoins, look at lending markets or savings products — for example our guides on providing liquidity on Curve or depositing into Ethena USDe.
• You're moving a trivial amount for the first time. Opening token accounts and paying rent for a $5 trade is not worth it. Consolidate.

FAQ