Solana Slippage Settings and Why Swaps Fail

The standard advice when a swap fails is to raise slippage. It works often enough to become a habit, and it hides the case where slippage was never the problem.

A swap that fails on slippage and a swap that fails from arriving late look identical from the outside: you did not get your fill. The fixes are opposite.

What Slippage Tolerance Actually Is

Slippage tolerance is not a preference. It is a minimum output amount encoded into the instruction, and the program enforces it on chain.

// This is what "1% slippage" becomes.
const minimumOut = expectedOut * (1 - 0.01);

When the transaction executes, the program computes the real output from current pool state. ★If it is below minimumOut, the program aborts and the transaction reverts.★

That has three consequences worth stating plainly:

The check happens at execution time, not at submission time. The price you quoted against is already history by the time your transaction runs.

A slippage failure is a landed transaction. It reached the chain, executed, and reverted. You paid the base fee.

Raising tolerance widens what you will accept, not how fast you arrive. It is a different axis from timing.

The Diagnostic That Separates Them

Before touching the slippage number, find out which failure you have:

const status = await connection.getSignatureStatus(sig);

if (!status.value) {
  // ★Never landed. Slippage is irrelevant here.★
  // Look at fee, retry behaviour, blockhash expiry.
} else if (status.value.err) {
  // ★Landed and reverted. Now read the error.★
  const tx = await connection.getTransaction(sig, {
    maxSupportedTransactionVersion: 0,
  });
  console.log(tx?.meta?.logMessages?.slice(-10));
}

★If status.value is null, raising slippage changes nothing.★ The transaction never executed, so the minimum-output check never ran. Turning tolerance up in this case does exactly one thing: it makes your fills worse on the transactions that do land.

This is the most common misdiagnosis in the space, and it is expensive in a quiet way — you keep the real problem and pay for it on every successful trade.

If your reverts are genuinely slippage and the rest are arriving late, a free BoltTx key is one line to test the timing half.

Reading the Revert

Slippage failures announce themselves in the logs, and the wording is program-specific:

Program log: Error: slippage tolerance exceeded
Program log: exceeds desired slippage limit
custom program error: 0x1771

★Anchor programs number custom errors from 6000★, so 0x1771 is 6001 — the second error in that program's enum. The number alone means nothing without the program's IDL, but it does tell you the failure was a deliberate program check rather than a runtime problem.

Worth distinguishing from these, which are not slippage:

• insufficient funds — balance or ATA problem
• exceeded CUs meant to be used — compute limit too low
• Blockhash not found — expired before execution
• AccountNotFound — an account in your instruction does not exist yet

Choosing a Number

There is no universally correct tolerance, but there is a correct method: derive it from the pool, not from habit.

// Price impact is a property of your size against this pool.
const impact = (spotOut - expectedOut) / spotOut;

// Tolerance covers impact plus movement while you are in flight.
const tolerance = Math.abs(impact) + volatilityBuffer;

Rough ranges by situation:

★The last row is a real decision, not a setting.★ When you need out, a bad fill beats no fill. When you are entering, a bad fill is just a bad trade — there is no urgency argument for it.

Routing Changes Your Failure Mode

Aggregators split a swap across pools to get a better price. That is a genuine improvement to the number, and it changes what can go wrong.

More accounts. Each pool brings its vaults and authorities, at 32 bytes per account key. A multi-hop route can approach the 1232-byte transaction limit.

More compute. Each hop costs compute units, so a route that quotes well may need a higher limit than you set.

More ways to revert. Any hop failing its own check reverts the whole transaction, because it is atomic.

A staler quote. More hops means more pools whose state can move between quote and execution.

// ★Fewer hops is sometimes the better trade.★
const quote = await getQuote({
  inputMint, outputMint, amount,
  maxAccounts: 32,          // bound the transaction size
  onlyDirectRoutes: false,  // set true when reliability outranks price
});

★onlyDirectRoutes: true is underused.★ When you are racing, a direct route that lands beats a split route that reverts. The price improvement from splitting is small; the cost of missing entirely is the whole trade.

Slippage on New Launches

Launch sniping is where the usual reasoning breaks down.

Price moves enormously in the first seconds, so tight tolerance guarantees a revert. But wide tolerance on a thin pool means your own order moves the price against you, and you fill at a level you would not have chosen.

★And there is a second reader of your tolerance.★ Setting a wide minimum-output on a public path tells anyone watching exactly how much room they have to trade ahead of you and still leave your transaction valid. Wide tolerance is only safe on a path where the transaction is not observable before it lands.

Some practical points:

Size down instead of widening. Half the size at half the impact usually beats double the tolerance.

Use the pool state, not the quote. On a launch, a quote from a second ago describes a different pool.

Expect reverts and budget for them. On new launches a meaningful share of attempts revert. That is the cost of being early, and it is why the base fee matters more than usual.

What Landing Looks Like

Real transactions through our delivery nodes: median confirmation 336ms — under one slot.

★Every slot between submission and execution is time for the price to move against your minimum-output.★ Landing faster is not a substitute for correct tolerance, but it does mean your tolerance has less to absorb.

Where BoltTx Fits

We do not quote, route, or choose your slippage. Those are your decisions and your code.

We handle the hop after signing. Submissions go through our own delivery nodes in four regions with stake-weighted routing and no public mempool exposure, so a transaction — and the minimum-output inside it — is not observable in transit before it lands.

You sign locally. We never hold funds, never sign, and never modify transaction contents, which includes never adjusting your slippage. The tip travels inside the transaction, paid on chain from your own wallet, and reverts with the transaction if it fails, because that is how Solana handles atomic transactions. You pay only on transactions that reach the chain.

Get a free API key. No monthly fee:

const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");

FAQ

What does slippage tolerance mean on Solana? It becomes a minimum output amount encoded in the swap instruction. The program computes the real output at execution time and reverts if it falls below that minimum, so it is enforced on chain rather than by your client.

Why does my Solana swap keep failing on slippage? Either your tolerance is too tight for the pool depth and your trade size, or the price genuinely moved between quote and execution. Check the slot distance from submission to landing — a long gap gives the price more time to move.

Should I just raise slippage until swaps succeed? Only after confirming the transaction actually landed. If it never landed, the minimum-output check never ran and raising tolerance only worsens fills on the trades that do succeed.

How do I tell a slippage failure from a transaction that never landed? getSignatureStatus. A null result means it never executed, so slippage is irrelevant. A result with err set means it landed and reverted — then read the logs to find which check failed.

What does custom program error 0x1771 mean? It is error 6001 in an Anchor program, since Anchor numbers custom errors from 6000. In many swap programs that range covers slippage checks, but you need the program IDL to be certain.

Does a failed swap cost money on Solana? If it landed and reverted, yes — you paid the base fee for the execution. If it never landed, it consumed no fee, but it also consumed your opportunity.

What slippage should I use for pump.fun tokens? Higher than for established pairs, because early liquidity is thin and price moves fast. Reducing your size is usually better than widening tolerance further, since your own order is part of the impact.

Does higher slippage make my transaction land faster? No. Tolerance affects whether the program accepts the result, not how quickly your transaction reaches a block producer. Landing speed comes from fees, routing, and retry behaviour.

Should I use direct routes or split routes? Split routes usually quote better. Direct routes are smaller, use less compute, and have fewer ways to revert. When you are racing, reliability generally outranks a small price improvement.

Why does my multi-hop swap exceed the transaction size limit? Each pool adds account keys at 32 bytes each, and Solana caps transactions at 1232 bytes. Bound maxAccounts in your quote request, or use address lookup tables to compress the references.

Can slippage settings protect me from being traded ahead of? Partially. Tight tolerance limits how much room someone has to move the price and still leave your transaction valid. But a wide tolerance on a publicly observable path advertises exactly how much room there is.

Why did my swap revert when the quote looked fine? The quote described pool state at quote time. Between then and execution, other transactions changed that state. On volatile pairs a quote from a few slots ago describes a different pool.

How much compute does a multi-hop swap need? More than a single hop, and it scales with the number of pools. Simulate the actual route you plan to send and set your compute unit limit from the measured figure with a margin.

Is a reverted swap the same as a failed transaction? It is one kind of failed transaction. Reverted means it landed and a program check rejected it. Never landing is a different failure with a different cause and a different fix.

Should slippage differ for entries and exits? Usually yes. When exiting, a poor fill is better than no fill and higher tolerance is defensible. When entering, there is no urgency argument, so a wide tolerance is just accepting a worse price.

How do I set slippage programmatically? Derive it from price impact for your size against the current pool, plus a buffer for movement while in flight. A fixed number applied to every pool is either too tight on thin liquidity or too loose on deep pools.

Related Reading

• Solana Transaction Simulation
• Solana Transaction Error Codes
• Solana Versioned Transactions
• Solana Token Launch Sniping
• Solana Transaction Landing