Why your Solana swaps keep failing
Failed swaps still pay their fees and book no volume, and the failure rate differs by an order of magnitude depending on which pool you routed through. Here is what each error actually means, what the measured rates look like, and what to change first.
A failed swap is not free
Start with the part people skip. When a Solana transaction fails, the network still charges the 5,000 lamport base fee and any priority fee attached to it. The swap does not happen, no volume is booked, no token moves, and the money is gone.
On its own that is trivial. Across a campaign it is not. A fleet sending a thousand transactions into a venue that rejects a third of them has paid for a thousand attempts and received roughly six hundred and seventy swaps. If you budgeted on transaction count rather than on confirmed swaps, you are short by a third and the screener will show it.
This is why the first question to ask about a stalled campaign is not "did it run" but "what percentage confirmed".
The seven errors behind almost every failure
Solana surfaces failures as program errors, and the same handful account for the overwhelming majority of them.
| What you see | What actually happened | Fix |
|---|---|---|
| Slippage tolerance exceeded | Price moved between quote and execution by more than your allowance | Widen tolerance, or send smaller swaps into thin pools |
| Blockhash not found | The transaction was signed too long ago and its blockhash expired | Refresh the blockhash and resend, do not queue signed transactions |
| Transaction not confirmed in 30 seconds | It was dropped before inclusion, usually a priority fee too low for the moment | Raise the compute unit price, retry with a new blockhash |
| Insufficient funds for rent | The wallet cannot cover the swap plus fees plus the token account deposit | Fund with headroom above the swap amount |
| Account not initialized | The associated token account for the mint does not exist yet | Create the token account in the same transaction |
| Exceeded compute unit budget | The route needed more compute than the transaction requested | Raise the compute unit limit, or simplify the route |
| Pool state changed | The pool moved between simulation and landing, common on curves | Shorter quote-to-send window, or a venue with deeper liquidity |
Read that column on the right again. Only two of the seven are settings you can turn up. The rest are consequences of timing and of where you chose to trade.
Failure rates are not the same everywhere
The assumption behind most volume tooling is that a swap is a swap. It is not. We sample finalized blocks every week and count, per venue, how many transactions carried an execution error. The spread is not subtle.
In a recent sample of roughly nine thousand transactions, the network-wide failure rate sat around thirteen percent, while the busiest launchpad bonding curve rejected well over eighty percent of the transactions that touched it and an established concentrated-liquidity pool rejected under five. Same network, same minute, an order of magnitude apart. The current figures, the block range they came from and the method are all published on the measured data page, and the raw snapshot is downloadable as JSON so you can check the arithmetic rather than trust it.
Why curves fail so much is not mysterious once you see the mechanism. A bonding curve has a single state that every buyer moves. Dozens of bots quote against the same state within the same slot, all of them setting tight slippage because the curve is priced in fractions, and only the ones that land first get the price they quoted. Everyone else fails. It is not a bug in your setup; it is what happens when a shared piece of state is contended.
Slippage is a budget, not a safety setting
Most people treat slippage as protection and set it as low as possible. On a contested pool that guarantees failure, and failure has a price.
The honest way to think about it: tight slippage protects you from a bad fill but exposes you to paying fees for no fill. Loose slippage guarantees a fill but lets the price move against you. Neither is free. What you actually want is a tolerance sized to the pool's depth and the swap's size, which means it should not be one global number applied to every venue in a campaign.
- Deep pool, small swap. Tight tolerance is fine and costs nothing.
- Thin pool, same swap. The swap itself moves the price, so tolerance has to cover your own impact before it covers anyone else's.
- Bonding curve during a busy minute. Tolerance has to cover every other transaction that lands ahead of you in the same slot.
The lever most people miss is the other one: cutting swap size reduces the impact you need to tolerate in the first place. More wallets sending smaller swaps produce the same volume with a materially lower failure rate, which the sizing method covers from the budget side.
Under-paying priority fees is the expensive choice
The instinct is to set the compute unit price low and save money. The arithmetic argues the other way.
A priority fee is a fraction of a thousandth of a SOL in normal conditions. A failed swap costs the base fee, the priority fee you did pay, and the swap that never happened. If shaving the priority fee turns a five percent failure rate into a twenty percent one, you have saved a rounding error and lost fifteen percent of your campaign.
The measured distribution is worth internalising here: in our sample about seven in ten transactions paid no priority fee at all, while the ninety-ninth percentile paid several orders of magnitude more. That is not a flat toll, it is a long tail. Pricing at the median means being outbid during exactly the minutes that matter; pricing at the p99 means overpaying on a quiet afternoon for nothing.
The diagnostic order that actually works
- Pull one failed transaction in an explorer. The error is named in the logs. Everything below is guessing until you have done this.
- Check whether failures cluster by venue. If one pool accounts for most of them, the problem is routing, not configuration.
- Check whether they cluster in time. A burst of failures in one window is a congestion or fee problem. A steady rate is a slippage or sizing problem.
- Compare swap size against pool depth. If a single swap moves the pool more than your tolerance, no fee will save it.
- Only then change a setting. Change one at a time, or you will not know which one worked.
What this means before you spend anything
The uncomfortable conclusion is that failure rate is mostly decided before a campaign starts, by which pools it will route through. A campaign concentrated on a single contested venue will fail a large share of its transactions no matter how carefully it is tuned. The same budget spread across several pools weighted by depth confirms far more of what it sends, and produces the additional benefit of not looking like a single wallet cluster hammering one pool.
That is why the console reads which venues actually hold a pool for your mint before it prices anything, rather than asking you to pick. It also means the honest answer to "what failure rate should I expect" is a question back: which pools does your token have, and how deep are they? You can see both, along with the estimated swap count and the exact SOL figure, in the console on the home page before committing to anything.
One last practical note. If you are running your own script rather than a service, the single highest-leverage change is usually not a setting at all: stop signing transactions in advance. Blockhashes expire in roughly a minute, and a queue of pre-signed transactions guarantees a wave of failures the moment the queue backs up. Sign late, send immediately, retry with a fresh blockhash. The Solana transaction documentation is explicit about the lifetime and is worth reading once in full.
Frequently asked questions
01Do failed Solana transactions still cost money?
Yes. The 5,000 lamport base fee and any priority fee are charged whether the transaction succeeds or fails, because the validator did the work of processing it. Only the swap itself does not happen. A campaign with a high failure rate is therefore paying full price for partial delivery, which is why failure rate belongs in the budget rather than in the troubleshooting notes.
02What slippage should I set for a Solana volume campaign?
There is no single correct number, because the right tolerance depends on pool depth and swap size together. A small swap into a deep pool tolerates a tight setting; the same swap into a thin pool has to tolerate its own price impact before anything else. Reducing swap size is usually a better lever than widening tolerance, since it lowers the impact you need to allow for.
03Why do Pump.fun bonding curve transactions fail so often?
A curve has a single shared state that every buyer moves. When many participants quote against the same state inside the same slot, only the transactions that land first get the price they quoted and the rest exceed their slippage. Our weekly block sampling has repeatedly measured curve failure rates far above what established AMM pools show, which is a routing consideration rather than a configuration problem.
04Does raising the priority fee fix failed swaps?
It fixes the subset caused by not being included in time, which shows up as transactions dropped or not confirmed. It does nothing for slippage failures, expired blockhashes or insufficient funds. Raising the fee is cheap relative to a lost swap, so it is usually the right first move, but it is not a universal fix and it will not rescue a campaign routed into a pool too thin for its swap size.
05How do I find out which error caused a failure?
Open the transaction in any Solana explorer and read the program logs. The failing instruction and its error are named there. Everything else, including this page, is pattern matching until you have looked at one real failure from your own campaign.
06Can a high failure rate hurt more than the wasted fees?
It distorts everything you measure afterwards. Volume comes in below target, trade count is lower than the wallet count suggests, and the campaign looks weaker than the budget implies. Teams then conclude the tool did not work when the real story is that a third of the transactions never landed.
Keep reading
See the venues before you route into them
The console reads which pools actually hold your token, then shows the estimated swap count and the exact SOL fee before anything runs.
Open the volume console