Why Solana Transactions Fail: 5 Root Causes

Use this end-to-end guide to identify why Solana transactions fail, match common error messages to likely causes, and choose an appropriate fix.

Quick Answer: Why do Solana transactions fail?

Solana transactions fail for five distinct reasons, and each has a specific fix:

1. Blockhash expiry: the transaction's validity code expired before processing
2. Insufficient priority fee: validators dropped the transaction during congestion
3. Compute unit exhaustion: the transaction exceeded its processing budget
4. Slippage tolerance breach: the token price moved beyond your accepted threshold
5. RPC node failure: the server submitting your transaction was overloaded

Table of Contents

• Why Solana Transactions Fail: A Quick-Reference Overview
• The 5 Root Causes of Solana Transaction Failures
• Solana Error Message Decoder: What Each Error Actually Means
• How to Fix a Failed Solana Transaction: Step-by-Step Solutions
• Platform-Specific Failure Scenarios and Fixes
• Is Solana Down? How to Check Network Status Before Retrying
• Do You Still Pay Fees on a Failed Solana Transaction?
• Pre-Transaction Checklist: How to Prevent Solana Transaction Failures
• Frequently Asked Questions About Solana Transaction Failures
• Summary: Matching Your Error to the Right Fix

Why Solana Transactions Fail: A Quick-Reference Overview

A failed Solana transaction is frustrating, especially when a trade is moving against you. Solana transaction failures trace back to five root causes: blockhash expiry, insufficient priority fee, compute unit exhaustion, slippage tolerance breach, and RPC node failure. This guide covers failures across Phantom, Jupiter, Raydium, Orca, and Magic Eden so you can match your error to the right fix immediately.

Your funds are safe. A failed Solana transaction does not deduct tokens from your wallet. Your SOL and tokens remain exactly where they were. At most, you may lose a small base network fee, typically less than $0.01. Your principal is not gone.

On the Solana blockchain, DeFi transaction failures carry real financial stakes because prices move in milliseconds. Token swaps, NFT mints, and transfers can all fail for distinct reasons, and each reason has a different fix. The sections below give you everything needed to diagnose and fix failures on any Solana platform, and to prevent recurrence.

The 5 Root Causes of Solana Transaction Failures

Solana fails transactions differently than most blockchains because of three architectural properties: slot-based blockhash expiry, no transaction queue (Gulf Stream replaces the traditional queue), and a per-transaction computational budget. Understanding these properties explains why the fixes that work on other chains often don't apply here.

Solana's timekeeping mechanism, called Proof of History, divides time into precisely numbered slots by creating a cryptographic sequence of events without requiring validators to communicate timestamps. Proof of History works alongside Tower BFT, Solana's consensus mechanism, to create this slot structure. Every transaction references a recent slot to prove it was created recently. This slot-based architecture is what creates Solana's unique failure modes, particularly the blockhash expiry behavior covered below.

One framing distinction matters before diving in: some failures come from the Solana network itself (congestion, blockhash expiry), while others come from the smart contract, or program, running the application you're using. When a program rejects your transaction, a specific rule coded into that application wasn't satisfied. Slippage errors and liquidity errors are program-level rejections. Network failures require adjusting fees and resubmitting; program failures require adjusting transaction parameters such as slippage amount. The Solana Error Message Decoder section tags each error by type so you can triage correctly.

A sixth, less common failure mode: Solana requires every account to maintain a minimum SOL balance called the rent-exempt threshold to stay active on the network. When a transaction would push your wallet below this threshold, or would create a new token account without sufficient SOL to fund it, the transaction fails with an "insufficient funds" error that is actually about account maintenance, not just fees. Keep at least 0.05 SOL as a buffer above your transaction amount to avoid this.

Blockhash Expiry

Every Solana transaction carries a timestamp-like code called a blockhash, and if that code expires before your transaction is processed, Solana drops the transaction entirely.

Each blockhash references a recent slot from Proof of History's sequence and stays valid for approximately 150 slots, roughly 60 to 90 seconds. If validators don't process your transaction within that window, the blockhash becomes stale and the transaction is rejected. During network congestion, validators fall behind their processing queue, which means blockhashes effectively expire faster in real-world time as the gap between submission and processing grows.

Solana uses Gulf Stream instead of a traditional transaction queue, so a dropped transaction simply disappears rather than waiting for the next available slot. You must actively resubmit with a fresh transaction.

The errors you'll see: Blockhash not found or Transaction expired.

The fix: wait a few seconds, then initiate the transaction again from your wallet or DEX interface. Do not try to resend the same transaction object. See Fix 3: Resubmit With a Fresh Blockhash for complete steps.

For Developers: Gulf Stream's no-queue architecture means retry logic must fetch a fresh blockhash on every attempt using connection.getLatestBlockhash(). Never reuse a blockhash across retry attempts. Use confirmed or finalized commitment levels rather than processed for production retry logic. See Solana's blockhash documentation for the full specification.

Insufficient Priority Fee

Solana's validators, the computers that process your transactions, choose which ones to handle first based on an optional tip called a priority fee.

Solana has a two-part fee structure. The base transaction fee is fixed and small (approximately 5,000 lamports per signature, where one lamport is one billionth of a SOL). The priority fee is optional and measured in micro-lamports per compute unit. During low-traffic periods, transactions without priority fees process fine. During high-demand periods such as popular NFT mints, token airdrops, or volatile market conditions, validators process transactions with higher priority fees first. Transactions with zero or minimal fees get dropped rather than queued.

This is the most common cause of repeated failures during busy periods. If your transaction fails multiple times in a row with no clear error, an insufficient priority fee is the likely culprit. See Fix 1: Increase Your Priority Fee for platform-specific steps.

Compute Unit Exhaustion

Every Solana transaction has a processing budget measured in compute units, and if a transaction runs out of budget before it finishes, Solana cancels it mid-execution.

Compute units work like a fuel tank for your transaction. Simple SOL transfers use a small amount. Complex DeFi swaps that route through multiple liquidity pools, or NFT mints that trigger on-chain royalty logic, use much more. If the transaction runs out of fuel partway through, Solana cancels it and the on-chain state reverts.

The default compute unit budget is 200,000 compute units per instruction, with a maximum of 1.4 million compute units per transaction. Complex multi-hop swaps on Jupiter frequently approach or exceed this budget without optimization.

Before sending your transaction, wallets such as Phantom run a pre-flight check called a transaction simulation. The simulation executes the transaction against the current blockchain state without broadcasting it. If the simulation predicts the transaction will fail, Phantom blocks submission and shows Transaction simulation failed. Most simulation failures indicate a real problem. Occasionally, the simulation uses slightly stale data and fails even when the live transaction would succeed, in which case refreshing the page and resubmitting once is appropriate.

The errors you'll see: Compute budget exceeded, Program failed to complete, or Transaction simulation failed.

The fix: most modern DEX interfaces (Jupiter, Raydium) auto-set compute unit limits. If seeing this error, use the DEX's built-in retry button or try a simpler swap route. See Fix 5: Increase the Compute Unit Limit for details.

For Developers: Set ComputeBudgetProgram.setComputeUnitLimit() and ComputeBudgetProgram.setComputeUnitPrice() as the first two instructions in the transaction, before any program instructions. Simulate first using simulateTransaction() to measure actual compute unit consumption, then set the limit to actual consumption x 1.1 as a 10% buffer. See Solana's compute budget documentation for implementation details.

Slippage Tolerance Breach

Slippage tolerance is the maximum price movement you accept between the moment a decentralized exchange (DEX, a platform where you swap tokens directly from your wallet) quotes you a price and the moment your transaction actually executes.

When you request a swap, the DEX locks in a price quote. If the token's price moves more than your slippage tolerance before the transaction reaches a validator, the smart contract, or program, running the DEX cancels the swap to protect you from receiving a worse price than expected. This is a protective failure: your funds are not lost, and the swap did not execute.

Slippage failures are most common on volatile tokens, low-liquidity pairs, and during periods of high network congestion when the gap between quote and execution grows. If a liquidity pool has very low reserves, even a 5% slippage tolerance may not be enough: the pool simply cannot accommodate your trade size at any reasonable price. In that case, try reducing your swap amount or switching to a different trading pair.

Jupiter, Raydium, and Orca all allow you to adjust slippage tolerance in their settings. See Fix 2: Adjust Slippage Tolerance for step-by-step instructions per platform.

RPC Node Failure or Congestion

Every Solana wallet connects to a server called an RPC node to broadcast your transactions to the network, and when that server is overloaded, your transaction may never reach the validators.

Picture the RPC node as a post office. Your wallet (such as Phantom or Backpack) writes the transaction, but the RPC node is the intermediary that delivers it to the Solana validator network. Solana's free public RPC endpoint is shared by millions of users and becomes heavily rate-limited during high-demand events such as NFT launches and token airdrops. Transactions submitted through an overloaded public RPC node are frequently dropped before they even reach validators.

Signs that RPC is the problem: you see Unable to confirm transaction, or your transactions fail repeatedly even after increasing fees and slippage to appropriate levels. The fix is to switch to a dedicated RPC endpoint. Dedicated RPC providers such as Helius and QuickNode generally offer higher reliability than the public Solana mainnet RPC during congestion. See Fix 4: Switch Your RPC Endpoint for wallet-specific steps.

For Developers: Implement RPC failover by maintaining a prioritized list of backup RPC endpoints and falling back automatically when the primary returns errors or connection timeouts. Use WebSocket connections via signatureSubscribe for transaction confirmation monitoring rather than polling, as WebSocket connections are more efficient for high-frequency transaction monitoring.

Solana Error Message Decoder: What Each Error Actually Means

Find your error message in Phantom's activity log, or paste your transaction signature into Solana Explorer or Solana FM to see the exact error code. A failed transaction shows a red error status and the specific error string.

How to Fix a Failed Solana Transaction: Step-by-Step Solutions

The five fixes below address each root cause directly. Start with the Quick Fix Checklist for immediate triage, then follow the subsection matching your specific error.

Quick Fix Checklist:

1. Check Solana network status at status.solana.com
2. Increase your priority fee to Fast or Turbo in your wallet or DEX settings
3. Raise your slippage tolerance incrementally (0.5% at a time)
4. Resubmit the transaction from scratch (do not resend the same transaction object)
5. Switch to a dedicated RPC endpoint if failures persist

Fix 1: Increase Your Priority Fee

Increasing your priority fee is the most effective fix during network congestion, and every major platform lets you do it in a few taps.

On Jupiter:

1. Open the swap interface at jup.ag
2. Click the settings gear icon in the top-right of the swap panel
3. Select Transaction Priority (or Priority Fee)
4. Choose Fast, Turbo, or enter a custom value
5. Resubmit your swap

On Phantom:

1. Open Phantom wallet settings
2. Navigate to Settings then Transactions
3. Select Transaction Speed and choose a higher tier
4. Return to your DEX and resubmit

On Raydium: Click the settings icon within the swap interface and adjust the Priority Fee slider before resubmitting.

Use this tier framework to choose the right fee level. Fee levels vary with network demand, so use your wallet's auto-estimate or the Helius Priority Fee API for current recommendations rather than fixed amounts.

For Developers: Add ComputeBudgetProgram.setComputeUnitPrice() as the first instruction in your transaction to set the priority fee programmatically. Poll getRecentPrioritizationFees() on your RPC connection to get current network fee data rather than using static multipliers. Dynamic fee estimation improves success rates during congestion.

Fix 2: Adjust Slippage Tolerance

Slippage tolerance errors have a clear fix: increase your tolerance incrementally in the DEX settings before resubmitting.

On Jupiter:

1. Click the settings gear icon in the swap interface
2. Select Slippage Tolerance
3. Enter a custom percentage (increase by 0.5% increments, e.g., from 0.5% to 1%, then to 2%)
4. Resubmit the swap
5. (Interface may vary by version)

On Raydium:

1. Click the settings icon within the swap panel
2. Adjust the slippage tolerance percentage
3. Resubmit

On Orca:

1. Click the settings gear icon
2. Set a custom slippage percentage
3. Resubmit

Important Warning: Setting slippage tolerance above 3-5% on low-liquidity token pairs exposes you to MEV sandwich attacks, where automated bots detect your high-slippage transaction and front-run it to extract value at your expense. Increase slippage incrementally and only as much as needed. If a token keeps failing even at 5% slippage, the liquidity pool may lack sufficient reserves for your trade size. Reduce your swap amount or try a different trading pair.

Jupiter's dynamic slippage feature, when available, auto-calculates the optimal tolerance per trade based on current pool conditions.

Fix 3: Resubmit With a Fresh Blockhash

Blockhash-expired transactions cannot be resent as-is because Solana's Gulf Stream protocol drops them permanently once the blockhash window closes.

For consumer wallets (Phantom, Backpack, Solflare):

1. Wait 5-10 seconds after the failure
2. Return to the DEX or wallet interface
3. Initiate the transaction again from scratch as a new transaction
4. Do not attempt to resend the same transaction object from your history

The wallet automatically fetches a fresh blockhash when you initiate a new transaction. You are creating a new transaction, not retrying the old one. The distinction matters: the old transaction is permanently gone.

For Developers: Implement retry logic that fetches a fresh blockhash using connection.getLatestBlockhash() on every attempt. Never reuse a blockhash across retries. Use exponential backoff intervals (1 second, 2 seconds, 4 seconds) between attempts and cap retries at 5 attempts before surfacing an error to the user. Use confirmed commitment level for blockhash fetching in production rather than processed, which is less reliable during congestion.

Fix 4: Switch Your RPC Endpoint

If transactions keep failing after adjusting fees and slippage, your RPC node may be the silent culprit.

Solana's public free RPC (api.mainnet-beta.solana.com) is heavily rate-limited and frequently overloaded during peak periods. Dedicated RPC providers such as Helius and QuickNode generally offer higher reliability than the public Solana mainnet RPC during congestion. Both offer free tiers suitable for most consumer use.

On Phantom:

1. Open Phantom settings
2. Navigate to Settings then Developer Settings
3. Select Change RPC Endpoint
4. Enter your dedicated RPC URL from Helius, QuickNode, or your preferred provider
5. (Interface may vary by wallet version)

On Solflare:

1. Open Solflare settings
2. Navigate to Network
3. Select Custom RPC and enter your endpoint URL

For Developers: Implement RPC failover by maintaining a prioritized list of RPC endpoints. Detect failures by monitoring for HTTP 429 (rate limit) or connection timeout responses and automatically fall back to backup providers. Triton One is another dedicated RPC provider worth evaluating alongside Helius and QuickNode for production environments.

Fix 5: Increase the Compute Unit Limit

Compute unit limit errors are usually handled automatically by modern DEX interfaces, but if you see a simulation failure citing compute units, the approach differs by user type.

For consumers: Most current versions of Jupiter and Raydium auto-set compute unit limits based on the swap route. If you see Transaction simulation failed or Program failed to complete, use the DEX's built-in retry button rather than manually adjusting. If failures persist, try a simpler swap route: instead of a complex multi-hop route through several pools, try swapping to SOL first, then to your target token in a second transaction.

For Developers: Use ComputeBudgetProgram.setComputeUnitLimit() to set the compute unit budget explicitly. The recommended pattern: simulate the transaction first using simulateTransaction() to measure actual compute unit consumption, then set the limit to actual consumption x 1.1 (a 10% buffer). Setting the limit too low causes InstructionError failures mid-execution. Setting it too high wastes priority fee budget but does not cause failures.

Platform-Specific Failure Scenarios and Fixes

Each major Solana platform has distinct failure patterns and different settings paths. Use the comparison table to navigate to the right setting quickly, then read the subsection for your platform.

Jupiter Swap Failures

Jupiter swap failures most commonly trace to two causes: a slippage tolerance that is too tight for the current price action, or an insufficient priority fee on a congested day.

Jupiter is a DEX aggregator that routes swaps across multiple liquidity sources to find the best price. Multi-hop routes chain swaps through two or more pools to reach your target token. These routes consume more compute units and expose you to slippage across multiple price points simultaneously, making Jupiter swaps more susceptible to failures during volatility than a single-pool swap on Raydium or Orca.

For slippage failures on Jupiter, see the Slippage Tolerance Breach root cause explanation and apply Fix 2: Adjust Slippage Tolerance. For priority fee failures, use Jupiter's built-in Fast or Turbo fee selector and apply Fix 1: Increase Your Priority Fee.

If a complex multi-hop route keeps failing, try enabling Direct Route Only in Jupiter's settings to force a single-pool swap. This reduces compute unit consumption and slippage exposure at the cost of potentially a slightly worse price.

One additional Jupiter-specific issue: Jupiter uses versioned transactions, which require wallet support. Older wallet versions may not support versioned transactions, causing failures unrelated to fees or slippage. Confirm your Phantom or Backpack wallet is on the latest version.

Raydium and Orca AMM Failures

Raydium and Orca AMM failures typically stem from thin liquidity pools, where even a moderate slippage tolerance cannot accommodate the trade size.

Raydium operates as an automated market maker (AMM) with traditional liquidity pools. Orca uses concentrated liquidity pools (Orca Whirlpools), where liquidity providers concentrate their capital within specific price ranges. Both are primary liquidity sources for Jupiter aggregator routes.

Check the price impact percentage shown before confirming any swap on Raydium or Orca. If price impact exceeds 2-3%, your trade size is too large for the available pool liquidity. Increasing slippage tolerance will not resolve this: if a liquidity pool has insufficient reserves, the trade cannot execute at a reasonable price regardless of your tolerance setting.

Two practical solutions: reduce your swap amount to bring price impact below 2%, or split one large swap into multiple smaller transactions submitted sequentially. Smaller swaps cause less price impact per execution and are less likely to breach slippage thresholds.

Magic Eden NFT Mint Failures

NFT mint failures on Magic Eden happen because hundreds or thousands of wallets submit transactions simultaneously, overwhelming both the RPC layer and the validator queue during high-demand launches.

When a popular NFT collection opens its mint window, automated bots and many human users submit transactions at the exact same second. This creates an extreme short-term congestion event where blockhashes expire rapidly, public RPC nodes drop connections, and validators prioritize only the highest-fee transactions. Standard wallet settings designed for routine trading are inadequate for this environment.

3-step protocol for high-demand NFT mints:

1. Before the mint window opens: Set your priority fee to Turbo or the maximum available level in Phantom (Settings → Transactions → Transaction Speed). Do this before the mint starts, not during.
2. Switch your RPC endpoint: Change Phantom's RPC to a dedicated provider such as Helius or QuickNode at least 10 minutes before the mint. Their infrastructure handles concurrent load better than the public RPC during congestion events.
3. Pre-approve and be ready: Have the mint page loaded and your wallet already connected and approved. Submit your transaction immediately when the mint window opens, not after you see others succeed.

Your principal is safe if a mint transaction fails. SOL used for the NFT purchase price is returned automatically. Only the small base network fee (approximately 0.000005 SOL) is consumed.

Some projects use allow-list mechanisms, Candy Guards, or phase-gated minting via Candy Machine programs. If your transaction fails even with maximum fees and a dedicated RPC, check whether you qualify for the current mint phase. A custom program error from the Candy Guard program often means you're not on the allowlist or the public phase hasn't opened yet.

Is Solana Down? How to Check Network Status Before Retrying

Most Solana transaction failures are not caused by a network outage. They result from network congestion, user-side settings, or an overloaded RPC node.

True Solana network outages, where the chain halts completely and requires validator coordination to restart, are rare events distinct from routine congestion. During congestion, the network continues processing transactions but deprioritizes those without adequate priority fees. During an actual outage, no transactions process at all until validators restore consensus.

3-step checklist to distinguish congestion from outage:

1. Check Solana's official network status page for active incident reports. If no incident is listed, you're almost certainly dealing with congestion or a settings issue, not a network failure.
2. Check Solana Beach for real-time TPS (transactions per second) and average confirmation times. Unusually high failure rates alongside normal TPS indicate congestion. Flat TPS close to zero indicates an outage.
3. Check r/solana or Solana's Discord for community reports. If many users report the same failures at the same time, it's network-wide congestion.

If the network is congested (not down): Wait 5-15 minutes. Fee levels drop naturally as congestion clears. Then resubmit with a higher priority fee, which places your transaction ahead of others still waiting.

If the network is actually down: Do not keep resubmitting. Repeated resubmissions during an outage accomplish nothing and waste fee SOL. Wait for the Solana status page to show a resolution before transacting again.

Do You Still Pay Fees on a Failed Solana Transaction?

Yes, a small base network fee is charged even when a Solana transaction fails, but your tokens, swapped assets, and principal remain completely untouched in your wallet.

Solana's validators expend computational resources evaluating a transaction even when they reject it. The base fee (approximately 5,000 lamports, or roughly $0.001 at most SOL price levels) compensates validators for that processing work. Priority fees, if included, are also consumed on failed transactions that reached on-chain processing.

What is NOT charged on a failed transaction: Your token balances, your swap amount, your NFT purchase price. None of these are deducted. The swap did not execute, the mint did not complete, and the transfer did not send.

One nuance: if a transaction was dropped before reaching on-chain processing (for example, because your RPC node failed to forward it), it may leave no on-chain record and charge no fee at all. A transaction that reached the validator network and failed on-chain will show the fee charged.

To verify exactly what was charged: Copy your transaction signature from Phantom's activity history, paste it into Solana Explorer or Solana FM, and check the Fee field. A failed transaction shows a red error status. The fee field shows the exact SOL consumed.

Pre-Transaction Checklist: How to Prevent Solana Transaction Failures

Running through this checklist before submitting any Solana transaction eliminates the most common failure causes before they happen.

1. Check network status at status.solana.com. If an active incident is listed, wait for resolution before transacting.
2. Set your priority fee to at least Fast during active trading hours or any period of elevated market activity. See the priority fee tier table for guidance on which tier fits your situation.
3. Verify slippage tolerance is appropriate for the token pair. Volatile or low-liquidity tokens need higher tolerance (1-3%). Stable pairs (USDC/USDT) need only 0.1-0.5%. Review the Slippage Tolerance Breach section for full guidance.
4. Confirm your SOL balance covers fees plus a 0.05 SOL buffer above the transaction amount. This buffer accounts for base fees, priority fees, and rent-exempt thresholds for any new token accounts the transaction creates.
5. Use a dedicated RPC endpoint for high-value or time-sensitive transactions. Providers such as Helius or QuickNode offer free tiers and outperform the public RPC during congestion. Configure this in Phantom under Settings → Developer Settings → Change RPC Endpoint.
6. For NFT mints: Set your fee to Turbo, switch to a dedicated RPC, and pre-approve your wallet connection before the launch window opens. Do not wait until the mint starts to configure settings.
7. For large swaps: Check the price impact percentage before confirming. If price impact exceeds 2-3%, split the trade into multiple smaller transactions or reduce the amount. High price impact indicates insufficient liquidity for your trade size.
8. Trust the DEX's built-in fee optimization when available. Jupiter, Raydium, and Orca provide built-in fee recommendations calibrated to current network conditions. Their auto-estimate is more accurate than manual guesses for most situations.

For Developers: Add a ninth item: implement simulation-based compute unit estimation and dynamic priority fee polling rather than static values. Fee markets change rapidly; static fee multipliers that work during calm periods may be inadequate during congestion spikes. Poll getRecentPrioritizationFees() before each transaction to calibrate your priority fee to current market conditions.

Frequently Asked Questions: Why Solana Transactions Fail

Why do Solana transactions fail during NFT mints?

NFT mint failures happen because high-demand launches send thousands of transactions simultaneously, creating extreme short-term network congestion. Validators prioritize the highest-fee transactions, and blockhashes expire rapidly as the queue grows. Bots competing for the same NFT supply make this worse. Set your priority fee to Turbo and switch to a dedicated RPC endpoint before the mint window opens. See the Magic Eden NFT Mint Failures section for a complete 3-step protocol.

Do I still pay a fee if my Solana transaction fails?

Yes, a small base transaction fee is charged on failed transactions that reached the validator network, but your principal is safe. The base fee is approximately 5,000 lamports (roughly $0.001), which compensates validators for processing the transaction. Your tokens, swap amounts, and NFT purchase price are not deducted. See the fee section for how to verify the exact fee charged on Solana Explorer.

How do I resend a failed Solana transaction?

Initiate the transaction again from scratch through your wallet or DEX interface. Do not attempt to rebroadcast the same transaction object from your history. Solana uses Gulf Stream instead of a traditional transaction queue, meaning a dropped or expired transaction is permanently gone and must be replaced with a new one carrying a fresh blockhash. Wait a few seconds between attempts, and increase your priority fee before resubmitting. See Fix 3: Resubmit With a Fresh Blockhash.

What does "transaction simulation failed" mean on Phantom?

Phantom runs a pre-flight test called a simulation before sending your transaction to the network. The simulation executes the transaction against the current blockchain state without actually submitting it. If this test predicts failure, Phantom blocks submission and shows Transaction simulation failed. Most simulation failures indicate a real problem such as slippage exceeded, insufficient funds, or compute unit exhaustion. Check the error context shown in Phantom, adjust the relevant setting, and resubmit. See the Compute Unit Exhaustion section and the error decoder table for specific causes.

Can I cancel a pending Solana transaction?

Pending Solana transactions cannot be cancelled. Solana uses Gulf Stream instead of a traditional transaction queue, so there is no queue to remove your transaction from. A pending transaction either confirms when a validator processes it, or expires when its blockhash becomes stale (approximately 60-90 seconds). If a transaction appears stuck, wait for it to expire, then resubmit with adjusted settings.

What is a good priority fee for Solana right now?

Fee levels vary with network demand, so no fixed amount is reliably current. Use your wallet's auto-estimate feature or the Helius Priority Fee API for real-time recommendations. As a framework: Auto or Normal works during calm market conditions; Fast (2-5x the baseline) works during moderate congestion; Turbo or Custom (10x+ baseline) is appropriate for high-demand NFT mints or during volatile market spikes. See the priority fee tier table.

How do I check if my Solana transaction actually went through?

Copy the transaction signature from your wallet's transaction history (Phantom shows this in the activity tab). Paste the signature into Solana Explorer or Solana FM. A successful transaction shows a green confirmation status. A failed transaction shows a red error status with the specific error code. If no transaction appears, it was dropped before reaching the network and left no on-chain record.

Why does my Solana transaction keep failing even after I retry?

Resubmitting without changing settings fails for the same reason every time. Identify the root cause first using the error message decoder table. If the error is slippage-related, increase your tolerance before resubmitting. If you see no error but repeated drops, increase your priority fee. If failures persist across multiple fee levels, your RPC node may be the bottleneck: switch to a dedicated RPC endpoint such as Helius or QuickNode.

What is a blockhash in Solana?

A blockhash is a unique code embedded in every Solana transaction that proves the transaction was created recently. Solana uses Proof of History to divide time into numbered slots, and each blockhash references a recent slot. Blockhashes expire after approximately 150 slots, roughly 60-90 seconds. If your transaction is not processed within that window, it is dropped. See the Blockhash Expiry section for the full explanation and fix.

What are compute units on Solana?

Compute units are Solana's measure of how much processing power a transaction uses. Every transaction receives a default budget, and if the transaction's operations exceed that budget before completing, Solana cancels it mid-execution. Simple transfers use very few compute units. Complex DeFi swaps routing through multiple liquidity pools consume much more. See the Compute Unit Exhaustion section for the full explanation.

What is a priority fee on Solana?

A priority fee is an optional tip you pay Solana's validators to move your transaction to the front of the processing queue during congestion. It is measured in micro-lamports per compute unit and set separately from the base transaction fee. Validators process higher-fee transactions first when demand exceeds capacity. See the Insufficient Priority Fee section for a full explanation and the fix instructions for platform-specific steps.

How long before a Solana transaction expires?

A Solana transaction expires after approximately 150 slots, which takes roughly 60 to 90 seconds under normal network conditions. During heavy congestion, this window can feel shorter in practice because validators fall behind their processing schedule. Once expired, the transaction is permanently dropped and must be resubmitted as a new transaction with a fresh blockhash. Under normal conditions, successful Solana transactions confirm in approximately 400 milliseconds to 2 seconds.

Is my money safe if a Solana transaction fails?

Your principal is safe. The tokens or SOL you were trying to send, swap, or use for a mint remain in your wallet when a transaction fails. A small base fee (approximately $0.001) may have been charged to compensate validators for processing the attempt, but this is the only amount that changes. Your token balances, swap amounts, and NFT purchase prices are not deducted on a failed transaction.

Why does Solana drop transactions?

Solana drops transactions because it uses Gulf Stream instead of a traditional transaction queue. Unlike other blockchains where unconfirmed transactions wait in a queue until a validator picks them up, Gulf Stream forwards transactions directly to the expected next validator. Transactions that are not processed immediately are dropped rather than queued. During congestion, validators choose which transactions to process based on priority fees, and those without adequate fees are dropped.

What is slippage tolerance on Solana DEXes?

Slippage tolerance is a user-set parameter on decentralized exchanges (DEXes) that defines the maximum acceptable price difference between the quoted swap price and the actual execution price. If the market moves more than your tolerance percentage between quote and execution, the smart contract cancels the swap to protect you from a bad trade. Too low a tolerance causes frequent failures during volatility. Too high a tolerance on low-liquidity pairs creates vulnerability to MEV sandwich attacks. See the Slippage Tolerance Breach section for a full explanation.

Explore SOL on Bybit

Use the Solana price page to review current SOL market data, or access the SOL/USDT spot market if spot trading matches your objectives. Bybit trading activity is not the same as submitting a Solana on-chain transaction; network fees may still apply when depositing or withdrawing SOL on the Solana network.

Summary: Matching Your Error to the Right Fix

The table below maps every failure cause to its fix at a glance, so you can return here during a future failure without reading the full guide.

Your principal remains safe after any failed Solana transaction. Only the small base fee is consumed. To avoid future failures, run through the Pre-Transaction Checklist before every high-stakes transaction.