Solana Slippage Settings: Picking the Right Value
Solana slippage settings explained by scenario: pool depth, volatility, sandwich risk. Jupiter, multi-swap, and the actual numbers operators use.
Set slippage too low and your transaction reverts on chain; you still pay the network fee for nothing. Set it too high and a sandwich bot watches the mempool, sees your generosity, takes the spread. "Auto" punts the call to a UI heuristic that does not know your trade size, your urgency, or the bot density on that venue. The "0.5% works for everything" line you copied from a Discord message is lazy outside one specific case. The actual value comes from three inputs: how big your trade is relative to the pool, how volatile the token has been recently, and how attractive your size looks to sandwich bots.
This walkthrough covers the mechanics, the numbers that fit each common scenario, and why one cap rarely covers every wallet equally on the Solana multi swap tool.
What slippage actually does
On Jupiter, Raydium, Orca, or Meteora, the slippage value appears as a percentage in the UI but encodes on chain as basis points (slippageBps). 100 bps equals 1 percent. 50 bps equals 0.5 percent. When the transaction lands, the program checks whether the user received at least expectedOut * (1 - slippage) tokens. If yes, swap succeeds. If no, the transaction reverts.
Important nuance: this check sits on chain, not in your wallet UI. Any price drift between the moment you got the quote and the moment execution lands counts against your budget.
// Slippage on Solana ships as basis points (bps)
// 100 bps = 1%, 50 bps = 0.5%
type SwapParams = {
inputMint: string;
outputMint: string;
amount: number; // raw u64 of input
slippageBps: number; // e.g. 50 for 0.5%
};
// Conceptual on-chain check at swap execution:
// require(actualOut >= expectedOut * (1 - slippageBps / 10000), 'slippage exceeded');
Too low: failed transaction
Set slippage to 10 bps on a fast-moving token. In the half second between quote and execution, price drifts 12 bps. The on-chain check fails, the transaction reverts. You still pay the network fee (around 0.000005 SOL). The real cost is not the fee; it is the missed move. If the price runs 8 percent in the next two minutes, waiting for the "correct" slippage value costs you the entry.
Too high: sandwich vulnerability
Open slippage to 5 percent and send a 50 SOL USDC buy. A mempool-watching bot sees your transaction land in the queue, buys ahead of you to push the price up, lets your trade fill at the inflated price, then sells immediately. The spread between those two trades is the bot's profit and your loss. Your transaction looks successful on chain because the fill stayed under your cap. That is exactly where the "why was my fill so bad" question gets answered.
Sandwich bots actively hunt large transactions with wide slippage. Sending a big order on a deep pair like SOL/USDC with a 5 percent cap broadcasts "come collect, profit is here." On deep pools, keep the cap tight; price impact is small, and there is no reason to leave the door wide open.
The Auto setting's blind spot
Jupiter's Auto (or Dynamic) mode estimates a slippage value from recent volatility on the token. On deep pools and stables, the estimate usually lands sensibly. On a freshly migrated memecoin, Auto often picks 5-15 percent even when your trade's real price impact is only 2 percent. That width makes you a quantitatively attractive sandwich target. Operators usually beat Auto because they know two things Auto does not: the size of their own trade, and the bot density on that specific venue.
Pool depth and price impact
Stop thinking of slippage as "how much loss am I willing to accept." The real question: "how much will my trade itself move the price on this pool?" If your trade is 1 percent of pool depth, price impact is small and the cap can stay tight. If your trade is 10 percent of pool depth, the AMM curve pushes price 10 percent or more from your own action alone; the cap has to cover that or the swap reverts.
UIs show "price impact" and "slippage tolerance" as separate values. Slippage should sit a touch above price impact: impact plus a small inter-block buffer. Before a large order, glancing at pool depth and holder distribution with the Solana token snapshot tool beats eyeballing the cap. You are swapping against the same LPs that the Solana liquidity add and remove tool interacts with; depth is the state of that LP at this slot.
Numbers by scenario
The values below are operator opinion, not protocol spec. Always check price impact alongside.
| Scenario | Suggested slippage | Why |
|---|---|---|
| Stable to stable (USDC ↔ USDT) | 0.1% - 0.3% | Deep pool, near-zero volatility. Anything more is waste. |
| SOL / USDC, small to mid size | 0.5% - 1% | Deep pool, higher volatility than stables. Sandwich pressure is real; keep the cap narrow. |
| SOL / mid-cap (e.g. JTO) | 1% - 2% | Reasonable liquidity, prices move. Stable cap will usually fail. |
| SOL / established meme (BONK, WIF) | 2% - 5% | High volatility, medium depth. Set the cap as price impact plus a buffer. |
| SOL / fresh post-Pump.fun meme | 5% - 15% | Very thin AMM, large moves per minute. Sandwich risk gets accepted; the alternative is a chain of reverts. |
For a single-wallet entry, the Solana single wallet swap tool exposes the slippage field directly; type the value in by hand and skip Auto. If your route includes a wSOL leg, the Solana wSOL wrapper tool handles the wrap before the swap so the path stays clean with one slippage check instead of two.
Read slippage and price impact together. Slippage = price impact + a small buffer works as a working rule. The buffer size scales with the venue: 10-20 bps suffices on deep SOL/USDC, while 200-500 bps may be needed on a fresh memecoin.
Multi-swap: one cap, many wallets
A launch with 200 wallets aiming at the same token. The Solana multi wallet swap orchestrator takes a single slippage cap and applies it to every wallet in the run. The trap: the pool moves between wallet 1's execution and wallet 200's execution. Set the cap tight enough that wallet 1 fills cleanly and wallet 200 reverts. Set it wide enough that wallet 200 makes it and wallet 1 hands free spread to a bot.
Practical move: design the cap around the worst-case wallet at the end of the run and accept that early wallets pay a small premium. Side option: split the run into 2-3 batches and reset the cap per batch using the fresh pool state. If you already use the Solana wallet generator tool to group wallets into batches, lining up the slippage cap with the same batch boundary makes the most sense.
The "0.5% works for everything" anti-pattern
"0.5% works every time" floats around Discord constantly. The single scenario where it actually holds: average-size SOL/USDC swap, deep pool, Jito-bundled or MEV-protected route. Outside that, the rule fails almost everywhere. On a memecoin, 0.5% reverts. On a 100K USDC buy, 0.5% is an open sandwich invitation; your trade's price impact alone may exceed 0.5%. On a multi-wallet run, 0.5% reverts half the late wallets.
Three questions to ask before each trade: how much of the pool am I taking, what is the sandwich profile on this venue, how many wallets are running. Set the value off those answers. For more operator notes, browse the j.tools guides category posts and the Solana tagged posts page.
Slippage is not a single correct number; it is a decision recomputed per trade. The day you glue yourself to a single default is the day you spend either in the waiting room or behind a bot's queue.
