Slippage, price impact, and failed swaps
These three labels often appear beside the same swap button, but they describe different events. Knowing which one you are seeing tells you whether to resize, re-quote, improve submission, or walk away.
The short answer
Price impact
The deterioration caused by your own order moving through available liquidity. It is visible in the quote before you sign.
Slippage
The difference created when market or route state changes between the quote and execution.
Slippage tolerance
The boundary you authorize for that change. It is a protection setting—not a fee, forecast, or promise of a better fill.
High price impact calls for a smaller order or deeper route. High execution movement calls for a fresh quote, faster or more reliable landing, a smaller order, or patience. Simply raising tolerance addresses neither cause; it only permits the transaction to succeed at a worse boundary.
How the protection becomes an onchain limit
In an exact-input swap, you fix how much you will spend. The transaction should carry a minimum acceptable output. If execution would return less, the call fails instead of completing beyond the boundary. In an exact-output swap, you fix what you want to receive and cap the maximum input.
Exact input
Spend 1 SOL → receive at least X TOKEN
The input is fixed; the minimum output is the protection.
Exact output
Receive 1,000 TOKEN → spend at most X SOL
The output is fixed; the maximum input is the protection.
A deadline or transaction-validity window adds a time boundary. It prevents an old payload from executing indefinitely, but it does not guarantee timely inclusion. Read from quote to fill for the full lifecycle.
Why impact and slippage require different fixes
Suppose the pool already quotes a 7% worse average price for your order than its pre-trade spot price. That 7% is primarily a depth problem visible before signing. If the route then moves another 1% before execution, that additional difference is slippage. An 8% tolerance might let the transaction pass, but it did nothing to improve the original 7% execution cost.
This distinction is especially important in new meme markets. A thin pool can display a rapidly rising spot price while offering very little capacity near it. Increasing tolerance to force an exit through that pool can realize far less than the interface's mark. Use the AMM pricing guide to read the curve that creates the impact.
Fixed tolerance and dynamic estimation
A fixed setting applies the same percentage regardless of token, size, route, or market conditions. That is simple and predictable, but a setting suitable for a deep stable pair may be unrealistic for a volatile new token—or dangerously wide when reused later.
Jupiter's current Meta-Aggregator flow can estimate slippage at order time using route and market conditions, including token characteristics, trade size relative to liquidity, and recent execution behavior. The estimate still expresses a trade-off between protection and successful landing. Automation does not turn the threshold into a guarantee or remove the need to review price impact.
A failed swap can still cost money
On Solana, the transaction fee is charged when the network processes a transaction even if execution fails. The state changes from the failed instruction sequence do not become a partial swap, but the fee and any applicable submission cost are not the same thing as “nothing happened.”
On EVM networks, a reverted swap consumes gas for work performed before the revert. The token exchange and other reverted state changes do not persist, but the native balance still falls by the gas paid. An earlier approval can also remain active because it was a separate successful transaction.
This is why the journal needs failed transactions. Excluding them overstates performance, hides submission problems, and can leave live authorities outside the trade record. The fee breakdown separates network fees from pool fees, tips, platform fees, and price impact.
Respond to the signal you actually have
Before changing the tolerance
Refresh the quote
Confirm whether the expected output, path, price impact, or minimum has changed. Never debug an expired market snapshot.
Reduce the order
If price impact falls sharply at smaller size, liquidity depth—not tolerance—is the limiting factor.
Compare the final wallet outcome
Check alternate routes after pool, platform, and network costs. A route with a better headline rate can still have a worse protected result.
Separate landing from pricing
Expired, dropped, nonce, compute, gas, balance, and allowance errors need transaction fixes. Widening slippage will not solve them.
Set a maximum loss before retrying
Repeated retries add fees and decision pressure. Decide the worst acceptable output and total retry cost before sending again.
If failures coincide with fast pool activity, continue with MEV and transaction ordering to separate network ordering from the price boundary you authorized.
What to record after the attempt
- The quote time, route, expected output, estimated price impact, and protected minimum or maximum.
- The signature and submission time, transaction identifier, expiry, and any landing fee or tip.
- Success or failure, the reported error, actual input and output deltas, and all network and platform costs.
- If retried, each attempt as its own transaction. Do not merge several failures and one fill into a single cost-free trade.
Primary sources
Count every attempt
A failed swap is still part of the trade record.
Paste a public address to reconstruct successful swaps, failures, fees, and remaining balances without connecting a wallet.
Open the journal