A transaction submitted to the Solana network should confirm within seconds, but sometimes it fails, disappears from the mempool, or sits in a pending state for longer than expected. These failures are not random. They follow predictable patterns tied to network congestion, validator capacity, fee markets, and protocol-level retry mechanisms. Diagnosing why a transaction failed requires more than checking a wallet balance. It requires access to real-time transaction data, block information, and the ability to trace a transaction through its entire lifecycle from submission through confirmation or final failure.

Solscan provides exactly that capability. As the official and leading blockchain explorer for Solana, it offers real-time transaction tracking, detailed fee and confirmation data, block monitoring, and advanced search tools designed to answer the question: what happened to my transaction, and why? Understanding how to read Solscan’s output transforms a frustrating experience into a diagnostic one. Instead of guessing whether to resubmit, increase fees, or wait longer, users and developers can observe network state directly and make informed decisions.

How Solana’s transaction model differs from other blockchains

Solana processes transactions in parallel using its proof-of-history (PoH) time-stamping system and a leader-based block production model. Unlike Ethereum, where a single mempool receives all pending transactions and miners select which ones to include, Solana’s leaders are known in advance. Each leader receives transactions, orders them, and produces a block at a fixed interval. When a transaction is submitted, it enters the transaction pool waiting for the current or next leader to include it. If a leader goes offline, fails to produce a block, or receives too many transactions to fit in the allocated block space, transactions may be dropped or require resubmission.

This architecture means that network congestion on Solana is less about a visible fee auction and more about slot utilization. Each slot has a maximum size measured in compute units. If that space fills, subsequent transactions must wait for the next slot or be dropped entirely. The distinction matters: Solana does not queue transactions indefinitely. If a leader’s block is full and a transaction lacks priority fees, it may be discarded from the network without warning. Observing this behavior requires checking both the transaction signature and the slots during which it was submitted and potentially confirmed.

Solscan’s real-time transactions view displays this directly. A transaction record shows not only the signature and status, but also the block slot, timestamp, and fee paid. By examining multiple transactions submitted during the same time window, users can see which were included, which were dropped, and what fee or priority level differentiated them. This comparative view is crucial for understanding congestion because it reveals the actual capacity constraint rather than assuming the network was simply slow.

Reading transaction status and failure reasons in Solscan

When a user queries a transaction signature in Solscan, they receive one of four outcomes: confirmed, failed, dropped, or not found. Each tells a different story. A confirmed transaction appears in a block, consumed the specified compute units, and changed the on-chain state. The transaction details show the slot number, timestamp, and fee paid. If any instruction within the transaction failed, Solscan displays the error code and the instruction that caused it. Common failure reasons include insufficient compute budget, invalid program instruction, account not initialized, or insufficient balance for a transfer.

A failed transaction is one that reached a block and was executed, but an instruction returned an error. The transaction consumed fees and occupied block space even though the intended operation did not complete. Solscan distinguishes this clearly by showing “Failed” status with the specific error. Users sometimes misinterpret this as a network issue when it actually signals a logic error in the transaction itself: a typo in an account address, a contract condition that was not met, or an operation that the program correctly rejected. Retrying the same transaction will not help; the underlying instruction must be fixed.

A dropped transaction never reached a block. It was removed from the transaction pool either because its lifetime expired (the maximum age for a transaction signature is approximately 150 slots, or roughly 60 seconds under normal conditions), because a leader never selected it, or because it was explicitly dropped when the network became congested. Solscan may display “Dropped” status or simply show no record if the transaction was forgotten quickly. In this case, the transaction consumed no fees and caused no on-chain change. A dropped transaction can safely be resubmitted with the same or higher priority fees.

A not found status means Solscan has not yet observed the transaction on the network, or it is searching a time period before the transaction was submitted. For very recent transactions, this is normal; the explorer may lag a few seconds behind the network. For transactions submitted hours ago, “not found” typically means they were dropped and never recovered. Attempting to query the transaction much later by signature will continue to return no results unless the transaction was re-signed and resubmitted with a different signature.

Diagnosing network congestion using block and slot data

Network congestion manifests as high slot utilization and increased priority fees. Solscan displays block information for every confirmed block, including the slot number, leader who produced the block, the number of transactions included, and the total compute units consumed. By reviewing blocks across several consecutive slots, users can determine whether the network is congested or whether their specific transaction faced a different problem. If Block 300 contains 2,000 transactions and consumed 1.4 billion compute units (close to the 1.4 billion maximum), the next slot is likely to be similarly full. In that environment, a transaction with zero priority fees is at severe risk of being dropped.

Solscan’s real-time view makes this comparison straightforward. The explorer shows recent blocks in chronological order, and users can select a specific block to inspect which transactions it contains and their fees. A pattern of consistently full blocks over several seconds indicates network congestion. Users observing this pattern should either increase priority fees for resubmitted transactions or wait for congestion to decrease. Checking the block utilization trend is far more reliable than guessing based on a single failed transaction.

The slot timeline also reveals another critical piece of information: whether blocks are being produced at regular intervals or whether the network is experiencing slot skipping. In rare cases, a leader fails to produce a block in their assigned slot, causing the network to skip forward to the next leader. Solscan displays these gaps clearly. If a user’s transaction was submitted during a skipped slot, it will not be processed until the next active leader’s slot arrives. Observing multiple skipped slots in sequence suggests network stress, validator problems, or temporary consensus delays. Retrying with higher priority fees becomes more important in this scenario.

Transaction retry logic and priority fee strategy

When a transaction is dropped, users face a practical choice: resubmit with the same fee, increase the fee, or wait. Solscan’s transaction data provides the information needed to make this decision intelligently. First, confirm that the transaction was actually dropped by searching for its signature and verifying the status. Second, check the block utilization during the time window when the transaction was submitted. Third, examine other transactions submitted at the same time to see what fees they paid and whether they were confirmed or dropped.

If multiple transactions with varying fees were dropped during the same period, the issue may be network congestion rather than an insufficient fee. Increasing the fee modestly and resubmitting may help. If other transactions with similar or lower fees were confirmed during the same time window, the dropped transaction’s fee was likely too low. Resubmitting with a higher priority fee—typically double or triple the previous amount—increases the likelihood of inclusion in the next available slot. Solscan’s historical data enables this comparison; users can observe exactly what fees were paid by transactions that succeeded nearby in time.

A critical mistake is to resubmit repeatedly without waiting. Each resubmission adds a new transaction to the network’s pool. If the network drops one copy, it may drop all copies. Users should allow at least one full slot duration (roughly 400 milliseconds) to pass before determining that a transaction was dropped, then make one deliberate resubmission with an adjusted fee rather than spamming the network. Solscan’s ability to track multiple related transactions by viewing the same wallet or searching by sender makes this discipline visible; users can see their own retry history and adjust strategy based on outcome.

Wallet analysis and address history on Solscan

Beyond individual transaction diagnosis, Solscan’s wallet explorer provides a complete history of an address’s activity, including all transfers, token balances, NFT holdings, and transaction fees paid over time. This information is invaluable for understanding patterns of transaction failure. If a user’s wallet shows that recent transactions succeeded but older ones failed, they can pinpoint when network conditions improved or when their fee strategy changed. If a wallet shows multiple failed transactions with the same error code, it suggests a recurring problem with a specific program or account setup rather than temporary congestion.

The wallet view also displays token holdings and recent transaction history, enabling users to verify that funds actually arrived after a transaction appeared to succeed. Sometimes a transaction confirms in a block but an instruction within it fails, causing the intended transfer to not occur despite the fee being deducted. Solscan’s clear distinction between transaction confirmation and transaction success prevents this confusion. Users can see that a transaction was confirmed (it appears in block 300) but failed (the transfer instruction returned an error). The fees were consumed; the transfer was not.

For developers and advanced users, Solscan’s API and developer tools extend this capability programmatically. Rather than manually checking each transaction, developers can query address transaction history, filter by status, and identify patterns of failure at scale. This enables automated fee adjustment algorithms, retry logic tuning, and identification of which programs or operations are causing the most failures during congested periods. The data available through Solscan serves as the foundation for this kind of analysis.

Comparing Solscan’s real-time data to alternative strategies

Without a blockchain explorer like Solscan, users diagnosing transaction failures resort to guesswork: retrying with random fee increases, waiting indefinitely hoping the transaction will eventually confirm, or assuming the wallet software was buggy. Each strategy is inefficient and sometimes harmful. Retrying with random fee increases may waste SOL on unnecessary fees. Waiting indefinitely can miss time-sensitive opportunities. Assuming software failure may cause users to stop using a reliable wallet because they lack visibility into the actual problem.

Solscan provides the alternative: direct observation. By checking block information, slot timing, and comparable transactions, users ground their decisions in data. They can determine whether the problem is their transaction’s fee, network congestion, a skipped slot, or a logic error in the transaction itself. This transforms troubleshooting from an art into a diagnostic process. The value of this capability becomes especially clear during high-traffic periods when dozens of transactions may be failing simultaneously. Having a tool to distinguish which failures are temporary network effects and which are permanent logic errors is essential.

The speed of Solscan’s indexing and display also matters. Because the explorer updates in real time as new blocks are produced, users can monitor the exact moment their transaction confirms or fails rather than waiting for delayed notifications from a wallet. This responsiveness enables faster decision-making: if a transaction is dropped, users know within seconds rather than discovering it hours later. The opportunity to resubmit with optimized fees exists only in that narrow window; Solscan’s real-time view keeps that window visible.

Best practices for monitoring and optimizing transaction success

Experienced Solana users maintain a workflow that integrates Solscan monitoring into their transaction submission process. Before submitting a high-value or time-sensitive transaction, they check the current block utilization on Solscan. If several recent blocks are full and priority fees are elevated, they increase the priority fee on their transaction before sending. After submission, they immediately search for the transaction signature in Solscan rather than waiting for a wallet notification. Within seconds or a few slots, the status becomes clear: confirmed, failed, or dropped.

If the transaction is dropped, they examine the block utilization during the submission window and compare their transaction’s fee to others that succeeded during the same period. They then resubmit with an adjusted fee based on data rather than intuition. If the transaction is confirmed but failed, they read the error message to understand what went wrong. If it is confirmed and succeeded, they verify the on-chain state change by checking the recipient’s address balance in Solscan to confirm funds arrived. This end-to-end verification catches problems that wallet notifications might miss.

For recurring transactions or time-sensitive operations, developers use Solscan’s historical data to establish baseline fee levels and congestion patterns. They observe what fees typical transactions pay during different times of day or network conditions, then set their automatic fee strategy to account for predictable congestion. They also monitor their own wallet for patterns of failure and success, identifying which operations or counterparties consistently encounter problems. This data-driven approach replaces reactive troubleshooting with proactive optimization.