Slippage tolerance exceeded

The actual swap output fell below your minimum acceptable amount. The token price moved between when you fetched the quote and when the transaction executed.

Common causes

1. Fast price movement. Volatile tokens can move significantly in the seconds between quoting and execution.
2. Slippage tolerance too tight. A 0.1% slippage on a volatile token is likely to fail. Most swaps need at least 0.5–1%.
3. Low liquidity pool. Tokens with thin liquidity have higher price impact, making the actual execution price deviate from the quoted price.
4. Front-running / sandwich attacks. MEV bots detect your pending swap and execute trades before and after it, moving the price against you.

How to fix

1. Increase slippage tolerance. Set a higher slippageBps in the Jupiter API call. Common values:

   • Stable pairs (USDC/USDT): 10–50 bps (0.1–0.5%)
   • Major tokens (SOL/USDC): 50–100 bps (0.5–1%)
   • Low-cap / volatile tokens: 100–500 bps (1–5%)

2. Refresh the quote. Always fetch a fresh quote immediately before building the swap transaction.

3. Use Jito bundles. Submit your swap via a Jito bundle with a tip to get atomic execution and reduce the MEV attack window.

4. Set dynamicSlippage. Jupiter’s API supports dynamic slippage mode that automatically adjusts based on current conditions.

FAQ

What is slippage in bps? Basis points. 100 bps = 1%. A slippageBps of 50 means you accept up to 0.5% worse than the quoted price.

Does higher slippage mean I lose more money? Not necessarily. Slippage tolerance is a maximum — you still get the best available price. A high tolerance only means you accept a larger deviation if prices move.

What is custom program error: 0x1771? Hex 0x1771 is decimal 6001, which maps to Jupiter’s SlippageToleranceExceeded error in its error enum.

How do I avoid sandwich attacks? Use Jito bundles for atomic execution, or add a tip to increase your transaction’s priority so it lands in the same slot as the quote.

Updated: 2026-10-21