Jupiter swap errors 6001 and 6024: diagnosis and fixes

In Jupiter’s swap-program reference, 6001 means SlippageToleranceExceeded and 6024 means InsufficientFunds. That reference sits in superseded Metis Swap V1 documentation. These codes remain useful when logs identify that program, but they are not universal Swap V2 response codes. Another program invoked along a route can use the same number with a different meaning.

Keep the signature or transaction ID if present, full message, time, token mint addresses, amount and wallet used. Check the explorer for success, failure or absence from the chain. A simulation rejection before sending is not a confirmed failed transaction. Without a signature, preserve the interface message or API response instead of assuming an onchain transaction exists.

SlippageToleranceExceeded means execution did not meet the configured swap tolerance. Price can move while you review or sign, route liquidity can change, or the amount may be too large for current conditions. Refresh the quote and compare expected output, minimum received and price impact. Slippage tolerance and estimated price impact are different concepts.

For example, a hypothetical quote expects 100 units with a minimum of 99.50. If the route can only deliver 99.20, rejection preserves your limit; blindly widening it permits an outcome previously rejected. A smaller amount or waiting may produce another quote without guaranteeing improvement. Only widen tolerance after understanding and accepting the new minimum, rather than merely silencing the error.

• Check the previous attempt failed before creating another.
• Refresh the route and read minimum received again.
• Verify both token mint addresses.
• Assess size and impact, particularly in small pools.
• Sign a valid fresh quote rather than leaving it pending indefinitely.

InsufficientFunds can concern the input token, transaction charges or funding a token account. Check the spendable balance of the exact mint in the signing wallet. USDC does not automatically fund a USDT sale, and SOL in another account or network does not fund the Solana wallet executing this swap. An aggregated portfolio screen can conceal that distinction.

Rent is not a maker/taker trading fee: it can involve funds required to maintain a token account. A new account is not created on every swap, and the requirement is not a universal fixed charge. Keep the SOL buffer indicated by the transaction when you are its payer. The Phantom guide explains network, address and spendable-balance checks.

Swap V2 /order obtains pricing and prepares a transaction. An empty transaction alongside errorCode can mean a valid price exists without a transaction ready to sign. Interpret router and errorCode together: code 2 on aggregator routes indicates insufficient SOL for gas, whereas on JupiterZ it can mean a missing associated token account. Reading the code without its router can produce the wrong diagnosis.

The managed flow uses RTSE to estimate slippage at order time and /execute for transaction delivery. /build returns instructions for customised flows with their own parameters. Do not copy V1’s dynamicSlippage recommendation as a universal V2 fix. Nor is every /execute failure slippage: expiry, incomplete signatures and landing failures have distinct causes. The interface can manage these steps; wallet-history diagnosis does not require building an API integration.

V2 supports gas sponsorship on eligible trades, including some JupiterZ routes or a separate payer. This does not make every swap free or justify spending all SOL without checking the transaction. The actual payer, router and eligibility determine the case. Platform charges and final output remain separate budget items.

• Open the previous transaction and inspect its final status.
• If successful, inspect balance changes instead of buying again because of a delayed message.
• If failed, identify program, instruction and message; separate slippage from funding.
• Obtain a fresh quote and address the diagnosed issue.
• After signing, keep the new reference and verify the outcome.

Submitted and processed transactions can incur network charges even if the swap fails; rejection before sending is different. For example, trying to sell 100 USDC with only 99.80 of the correct mint is not fixed by adding SOL. Conversely, holding all 100 USDC while lacking unsponsored gas is not necessarily fixed by reducing the USDC amount without funding the required payer.

Keep the signature, Solana network, input and output mints, amount, time and full message. For an integration, include router, endpoint and code while removing API keys and private data. Never provide a recovery phrase, private key or signatures requested by someone promising to repair the wallet. A transaction ID helps examine the attempt; it does not authorise fund movements.

The Jupiter review separates swap aggregation from Perps, which need not share the same workflow. Continue with using a DEX and calculating costs for routing and funding concepts. If funds never reached the wallet, use exchange-to-wallet withdrawals before diagnosing a swap that cannot yet be funded.