The first question: did it land at all
Before diagnosing anything, split the failure into one of two categories. A transaction that reached a block and reverted is a different problem from one that never reached a block. They look similar in an interface and have nothing in common underneath.
| Landed and reverted | Never landed | |
|---|---|---|
| Visible on an explorer | Yes, with a failure status | No signature to look up |
| Fees charged | Yes | Usually not |
| Typical causes | Slippage, compute, funds | Expired blockhash, bundle lost, late |
| What to change | Sizing or settings | Submission or detection |
Slippage tripped against a moving curve
This is the most common failure in sniping and the most misread. Your transaction specifies a minimum amount you will accept. Between the moment it was built and the moment it executed, other buys moved the curve, and the amount you would now receive fell below that minimum. The program refuses, and you pay for the attempt.
It is not a bug and it is not the bot being slow. It is the protection working. The uncomfortable part is that the protection fires precisely on the launches you most wanted, because those are the ones where the curve is moving fastest.
What actually changes it
- Smaller position relative to pool depth. Your own order is part of what moves the curve against you.
- Wider tolerance, accepting a worse price deliberately rather than failing. This is a cost decision, not a safety setting.
- Private submission, so your intent is not visible to the people moving the curve ahead of you.
- Choosing less contested launches, where the curve moves less between build and execution.
Notice that widening tolerance is only one of four options, and the other three are usually better. Raising slippage until fills succeed converts a failure rate into a worse average price, which is not the same as solving it.
Blockhash expired before inclusion
Every Solana transaction carries a recent blockhash and is only valid for a limited window after it. If the transaction is built, then waits too long before reaching a leader, the hash ages out and the transaction becomes uninvitable. It never lands, and there is usually no signature to inspect.
This failure means time was spent somewhere between building and submitting. That is a routing or infrastructure problem, not a settings problem, and no amount of slippage adjustment touches it.
| Where the delay was | Symptom | What helps |
|---|---|---|
| Screening ran too long | Consistent expiry on busy launches | A bounded screening budget |
| Submission path congested | Sporadic expiry under load | A different submission route |
| Transaction rebuilt repeatedly | Expiry after visible retries | Fewer, earlier retries |
| Detection was late | Expiry plus missing the entry entirely | In-slot detection instead of polling |
Compute budget exhausted
A transaction declares how much compute it may use. If execution needs more than was requested, it halts and reverts. This is charged, because the work was performed up to the point it stopped.
It shows up on routes that turn out longer than expected: a swap that gets routed through more hops than anticipated, or a token with transfer extensions that cost more to move than a plain one.
Bundle not taken
If you submitted through a block engine and the bundle was not included, nothing lands. Bundles compete for inclusion, and losing that competition is a normal outcome rather than an error condition.
The distinguishing sign is that nothing appears on chain at all and no partial state was created. That is the atomicity working as designed: all or nothing meant nothing.
- A tip set at zero on a contested launch will usually lose. That is the tip doing its job as a price.
- A tip raised on quiet launches wins competitions that had no other entrants, which is money spent on nothing.
- Repeated bundle losses on the same kind of launch means your tip is below the level that market clears at, not that bundles are broken.
Insufficient funds, including the fee
The straightforward one, with a detail that catches people. A wallet holding exactly the amount you intend to spend does not have enough, because the fee is charged on top and rent-exempt minimums have to be respected for accounts being created.
Sniping a new token frequently requires creating a token account for it, and that account has to be funded. A wallet swept to the last lamport after a profitable exit will fail its next entry for reasons that have nothing to do with the strategy.
You were simply late
The last case is the one nobody wants and it deserves honesty. Sometimes nothing failed. The transaction was fine, the settings were fine, and the entry you were aiming at had already gone by the time you arrived.
The signature of this case is that the trade would have succeeded at a price you no longer wanted, or that your bot never attempted because the opportunity had passed its own criteria. No error, no failed transaction, no charge. Just an absence.
The only real fix is upstream, in detection. If launches are being learned about slots after they happened, every downstream setting is being tuned around a handicap that settings cannot remove.
The upstream and downstream of a failed snipe
- How fast is a sniper botWhere the delay sits across four stages
- Jito bundles explainedWhat the tip buys and when the bundle loses
- What a sniper bot costsFailed attempts are a cost line, not an accident
- Are sniper bots profitableWhy fill rate is the denominator that decides everything
Questions people ask
These come up in the ticket queue often enough to answer once, properly. If yours is not here, send it over and it probably ends up on this page.
Most commonly because slippage tripped: the curve moved between building the transaction and executing it, so the minimum you specified could no longer be met. The other five causes are an expired blockhash, an exhausted compute budget, a bundle that was not taken, insufficient funds including the fee, and simply being late.
Key takeaways
- Split every failure first into landed-and-reverted versus never-landed; that eliminates half the possibilities.
- Slippage tripping against a moving curve is the most common cause and it is the protection working.
- An expired blockhash means time was lost between build and submission, not that settings were wrong.
- Compute exhaustion usually means a longer route or a token with transfer extensions.
- A lost bundle produces no on-chain trace at all, which is atomicity behaving correctly.
- Keep a fee buffer outside position sizing, because a swept wallet fails its next entry.