Fees
Why Solana Transactions Fail: Common Errors and Fixes
Why Solana transactions fail: expired blockhash, low priority fee, slippage error 0x1771, rent and fee shortfalls, compute limits, and how to read the logs.
Key takeaways
- A Solana transaction can fail in two ways: it expires without ever landing in a block, which costs nothing, or it lands and fails during execution, which still costs the fee.
- Failed Solana transactions that land pay the base fee and the full priority fee because validators deduct the fee before executing the instructions.
- Custom program error 0x1771 is error 6001 in Jupiter v6 and means the swap exceeded the slippage tolerance set by the user.
- A Solana transaction signed with a recent blockhash is only valid for about 150 blocks, roughly 60 to 90 seconds.
- Solana custom program error codes only have meaning inside the program that raised them, so the first step is finding which program failed in the logs.
The short answer#
Solana transactions fail for one of two reasons: they never make it into a block before their blockhash expires, or they land and a program rejects them during execution. The first costs nothing. The second still costs the base fee and the priority fee. Nearly every failure a trader sees is one of eight causes, and the transaction logs say which.
What is the difference between a dropped and a failed Solana transaction?#
A dropped Solana transaction never reached a block, while a failed transaction was included in a block and then errored. They look similar in a wallet, which may show "failed" or "timed out" for both, but they are different events.
A dropped or expired transaction has no on-chain record. Searching its signature in an explorer returns nothing. No fee was charged, and it is safe to try again once it has definitely expired.
A failed transaction has a signature you can look up, a slot, a fee and an error. Everything it tried to do was rolled back, but the fee was kept.
The practical test: paste the signature into an explorer or the Transaction Decoder. Not found after two minutes means dropped. Found with an error means failed.
Why do failed Solana transactions still pay fees?#
Failed Solana transactions pay fees because the fee is deducted from the fee payer before any instruction runs. By the time a program returns an error, the validator has already verified the signatures, loaded the accounts and executed part of the transaction. Charging regardless of outcome also stops spam: if failures were free, flooding the network with transactions designed to fail would cost nothing.
What you lose is the base fee of 5,000 lamports per signature plus the full priority fee, which is charged on the compute-unit limit requested, not the work completed. What you do not lose is anything else. Rent for an account that was going to be created, the tokens in a swap, the SOL in a transfer: all of it is rolled back. The fee mechanics are covered in Solana transaction fees explained.
What are the most common reasons a Solana transaction fails?#
The most common reasons are an expired blockhash, an uncompetitive priority fee, slippage, a SOL shortfall for rent or fees, the compute limit, account state problems, and transaction size.
Blockhash expired or dropped before landing#
A Solana transaction is only valid for about 150 blocks after the blockhash it references, roughly 60 to 90 seconds. Every transaction embeds a recent blockhash as a timestamp and anti-replay measure. If the network is busy, the RPC node forwards it poorly, or you leave the wallet prompt open for too long before approving, the window closes. The errors read "Blockhash not found" or "block height exceeded". Nothing executed. Rebuild and sign again.
Priority fee too low during congestion#
A transaction with a low priority fee can be outbid for the accounts it needs until its blockhash expires. Solana's fee market is local to the accounts a transaction writes to, so a quiet network overall does not help if you are trading the busiest pool of the hour. The symptom is a transaction that sits pending and then expires, rather than an error. The free Priority Fee tracker shows recent fee percentiles and lets you paste the specific pool or token accounts to see what others are paying for those.
Slippage exceeded (0x1771 on Jupiter)#
Slippage exceeded means the price moved past the minimum output you accepted between quote and execution. On Jupiter it appears as custom program error: 0x1771, which is 6001 in decimal, the Jupiter v6 slippage tolerance exceeded error. It is the most common landed failure for traders, and it is the program protecting you. Thin liquidity, fast-moving tokens and Token-2022 mints with transfer fees all make it more likely. A fresh quote, a smaller size or a wider tolerance are the options, with the obvious trade-off that wide slippage invites worse fills.
Not enough SOL for rent on a new account#
A transaction fails with "insufficient funds for rent" when it would leave an account below its rent-exempt minimum. The usual case is buying a token for the first time with almost no SOL left: the new token account needs 0.00203928 SOL and the wallet cannot cover it. The other case is sending out nearly all your SOL so the remainder is above zero but below the 0.00089088 SOL minimum for a wallet account. The rent calculator gives the deposit for any account size, and what is Solana rent explains why the minimum exists.
Insufficient funds for the fee#
If the fee payer cannot cover the fee, the transaction is rejected before it runs, usually at simulation in the wallet. A wallet with no SOL at all produces the odd message "Attempt to debit an account but found no record of a prior credit". A wallet that holds its value in wrapped SOL rather than native SOL can hit this too, since fees are only paid in native SOL; unwrapping wSOL fixes that and the tool is free. Related but different is custom program error: 0x1, which in both the System program and the SPL Token program means the source account lacked the amount being transferred.
Compute budget exceeded#
A transaction fails with "exceeded CUs meter" or "Computational budget exceeded" when it runs out of the compute units it requested. Each transaction has a compute-unit limit, either set explicitly or defaulted to 200,000 per instruction, up to a maximum of 1.4 million. Complex swap routes through several pools are the usual culprit. Apps normally simulate and set the limit for you, so as a user the fix is to retry, or pick a simpler route. Developers should simulate, then set the limit with a margin.
Account already in use or frozen#
Account state errors mean an account was not in the condition an instruction required. custom program error: 0x0 from the System program means the address being created already exists. 0x11 from the SPL Token program means the token account is frozen: the token's freeze authority has frozen your account and you cannot transfer or sell until it is thawed. That is a property of the token, not a network fault, and it is one reason to check authorities before buying, as described in mint authority vs freeze authority.
Transaction too large#
A Solana transaction cannot exceed 1,232 bytes once serialized, including signatures, account addresses and instruction data. Each account address takes 32 bytes, so a transaction touching many accounts hits the limit quickly. The error reads "Transaction too large" with the actual size against 1,232. Users see it on very long swap routes or bulk actions. The fixes belong to the app: split the work across several transactions, or use versioned transactions with address lookup tables, which replace 32-byte addresses with 1-byte indexes.
Error text, meaning and fix#
The table maps the messages you are most likely to see to their cause.
| Error text | What it means | Fix |
|---|---|---|
| Blockhash not found / block height exceeded | The transaction expired before landing; no fee charged | Sign again with a fresh blockhash, approve promptly |
| Pending, then expired, no error | Outbid for the accounts it writes to | Raise the priority fee; check live fees first |
| custom program error: 0x1771 (Jupiter) | Slippage tolerance exceeded | Re-quote, reduce size, or widen slippage |
| insufficient funds for rent | An account would fall below its rent-exempt minimum | Keep about 0.003 SOL spare; send slightly less |
| Attempt to debit an account but found no record of a prior credit | The fee payer holds no SOL | Fund the wallet with native SOL |
| custom program error: 0x1 (System or SPL Token) | The source account does not hold the amount being sent | Check the balance and decimals |
| exceeded CUs meter / Computational budget exceeded | Ran out of compute units | Retry, use a simpler route, or raise the compute-unit limit |
| custom program error: 0x0 (System program) | The account being created already exists | Usually safe to continue without the create step |
| custom program error: 0x11 (SPL Token) | The token account is frozen | Only the token's freeze authority can thaw it |
| Transaction too large: N > 1232 | Serialized size over the 1,232-byte limit | Split into several transactions or use lookup tables |
One caution: a custom program error number only has meaning inside the program that raised it. 0x1 from the SPL Token program and 0x1 from some other program are unrelated, so always identify the program first.
How do you read a failed Solana transaction's logs?#
Reading a failed transaction's logs means finding the last program that reported a failure and translating its error code. The free Transaction Decoder does most of this for you; it is read-only, needs no wallet and works on any mainnet signature.
- Copy the signature from your wallet's activity list, or copy the Solscan, Solana Explorer or SolanaFM link.
- Paste it into the Transaction Decoder. If nothing is found after a couple of minutes, the transaction was dropped and cost nothing.
- Read the summary: status, fee paid, compute units consumed and the error. Compute units consumed close to the limit point to a compute budget failure.
- Check the balance changes. On a failed transaction the only change should be the fee leaving the fee payer.
- Open the instructions and find the one marked as failed, then look at its inner instructions. The program that failed is often an inner one, for example the SPL Token program inside a swap.
- Open the logs and read upward from the bottom. Lines follow the pattern "Program X invoke", "Program log: ...", "Program X failed: custom program error: 0x...". The "failed" line names the program that raised the error.
- Translate the code for that program. The decoder does this for the codes it knows in the System, SPL Token, Token-2022 and Jupiter programs. For anything else, convert the hex to decimal and look it up in that program's published error list; Anchor programs number their custom errors from 6000.
The limit of any decoder is that it can only explain transactions that landed. For a dropped transaction there are no logs to read, and the cause is nearly always timing or priority fee. For program error lists, the Solana docs and the Jupiter docs are the references.
Bottom line#
A Solana transaction that never landed cost you nothing, and one that landed and failed cost you only the fee. Find out which you have by looking up the signature, then read the logs from the bottom to find the program and the error code. Most failures are slippage, an expired blockhash or a wallet running short of SOL for rent, and all three have simple fixes. Keeping a small SOL buffer and checking live priority fees before a busy trade prevents most of them. I built the decoder because reading raw logs on an explorer was slower than it needed to be; more on that on the about page.
Questions & answers
Why did my Solana transaction fail but still charge a fee?
Solana validators deduct the fee from the fee payer before running the transaction's instructions. If an instruction then fails, every state change is rolled back, but the fee stays paid, because the validator already verified the signatures and spent compute on the attempt. You lose the base fee of 0.000005 SOL per signature and the priority fee, not the amount you were trying to swap or send.
What does custom program error 0x1771 mean?
0x1771 is hexadecimal for 6001, which in the Jupiter v6 aggregator program is the slippage tolerance exceeded error. The price moved between the moment you were quoted and the moment the swap executed, so the output would have been lower than the minimum you accepted, and the program stopped. Retry with a fresh quote, a smaller trade size, or a wider slippage setting if the token is volatile and you accept the risk.
What does blockhash not found or block height exceeded mean?
Every Solana transaction includes a recent blockhash, which is valid for about 150 blocks, roughly 60 to 90 seconds. If the transaction has not been included in a block by then, it expires and can never land. Nothing was executed and no fee was charged. The fix is to rebuild and sign the transaction with a fresh blockhash, usually with a higher priority fee if the network is busy.
How do I see why a Solana transaction failed?
Copy the transaction signature from your wallet's activity list and open it in an explorer or a decoder. Look at the status and error line first, then the program logs. The last program that logged a failure is the one that raised the error, and it is often an inner program rather than the one your app called. Match the error code against that program's error list.
What does insufficient funds for rent mean on Solana?
The transaction would have left an account holding some SOL but less than its rent-exempt minimum, which Solana does not allow. It usually means your wallet lacks the roughly 0.002 SOL needed to fund a new token account, or that you tried to send nearly all your SOL and the remainder fell below the minimum. Add a little SOL or send a slightly smaller amount.
Does a higher priority fee guarantee my Solana transaction lands?
No. A higher priority fee improves your position among transactions competing for the same accounts, but it cannot fix a transaction that would fail anyway, such as a swap past its slippage limit. It also cannot help if your app's RPC node does not forward the transaction well. It raises the odds of inclusion before the blockhash expires and does nothing more.
Continue reading
Solana Transaction Fees Explained: Base, Priority and Rent
A Solana transaction has a tiny fixed base fee, an optional priority fee, and sometimes a rent deposit that is not a fee at all. Here is how each one is calculated and what common actions cost in SOL.
What is Solana rent? The refundable deposit on every account
Solana rent is not a recurring charge. It is a one-time deposit, sized by how many bytes an account stores, that keeps the account on chain and comes back in full when the account is closed.
Token-2022 explained for traders: extensions that matter
Token-2022 lets a Solana token carry optional extensions, and a few of them give the issuer powers the classic token program never allowed. This is what each extension does, which ones should stop a trade, and how to check a mint.