Solscan Solscan transactions reveal execution results, fees, and balance changes.
Updated on
Solscan transactions show whether a Solana transaction succeeded, what network fee it incurred, and how it changed account balances. Search using the transaction signature, then compare the recorded accounts and assets with the intended transfer. A returned signature alone does not prove that the network confirmed a transaction.
In this guide
A sender's SOL decrease can include a transfer, a network fee, and an account storage deposit.
Submission and the First Network Record
A transaction signature identifies a signed transaction before the network necessarily processes or confirms it. The sending application can obtain this identifier before submission. Solana's
sendTransaction
method relays the signed transaction unchanged and returns its first signature when the RPC node accepts it. RPC means remote procedure call, the interface that applications use to communicate with a network node.
The submission response acknowledges receipt by that node. The response does not guarantee network processing or confirmation, so a wallet's submission message and an explorer's confirmed transaction record establish different things.
Execution Result and Confirmation Depth
Execution status describes instruction success, while confirmation depth describes the network's commitment to the containing block. Processed is the newest view from a node, and the network can still roll it back. Confirmed means a supermajority of active stake has voted directly on the block. Finalized is the network's strongest confirmation state, with the containing block reaching maximum lockout. These labels describe network agreement about a recorded outcome, including an outcome in which execution failed.
A failed transaction can also appear in a finalized block. Read the execution result separately when deciding whether a transfer succeeded.
Network Fees and Other SOL Movements
Transaction fees pay for network processing, while the transfer amount describes assets moving between accounts. Solscan presents fee information separately from the SOL and token balance changes. Comparing these fields prevents a balance decrease from becoming an inflated estimate of processing cost.
Solana fees have a base component and an optional prioritization component. The base component covers signature verification, and the priority component affects transaction scheduling. The fee payer covers the network charge in SOL, including when the transaction concerns a token with a different denomination.
A Solana transaction that reaches execution still incurs its network fee if an instruction fails.
Account creation can also move SOL into the refundable minimum balance needed to store account data. This storage deposit depends on the account's data size, and the balance is recoverable when the account closes. When account creation accompanies another action, that deposit explains a separate use of SOL from the network fee.
Does a Successful Transaction Mean the Intended Recipient Was Paid?
A successful transaction establishes that its instructions executed, while the recorded destination determines which account received a transfer. Success alone cannot establish that the sender selected the right destination or asset. Compare the transfer details with the payment that was intended. Token identity needs particular attention because different tokens can share a name or symbol. The mint address distinguishes the asset involved in a token transfer. A matching symbol alongside an unexpected mint does not establish payment in the intended token, even when the transaction itself succeeded.
A Transfer Check With a Missing Signature
Matching transaction details can establish a SOL transfer despite a reported missing wallet entry. This hypothetical case starts without the transaction signature.
Assume the sender knows the intended amount and destination and pays the network fee. The recipient reports no visible receipt. The sender searches the sending address's activity for a candidate that matches the destination and intended SOL movement. The recorded time helps distinguish nearby activity. The sender then takes the candidate's signature into the individual transaction record, where the execution details can resolve the uncertainty.
Assume that the matching record shows successful execution and finalized confirmation. Its balance changes show the intended SOL credit at the recipient and the network fee charged to the sender. Reading the fee separately explains why the sender's decrease exceeds the recipient's credit in this simple transfer.
The record establishes that this payment reached the intended on-chain account, despite the reported missing wallet entry. It does not explain that display discrepancy. Without a matching record, the payment would remain unverified; the missing wallet entry alone would not establish that another payment was necessary.
Absent Records and Recent Blockhash Expiry
A missing search result leaves several possibilities open, including a mismatched network or an unconfirmed submission. Solana clusters maintain separate records. The originating application and the lookup must concern the same cluster before the absence of a result can help explain the submission.
For transactions that use a recent blockhash, that blockhash can expire before the transaction lands. Initial receipt by an RPC node does not extend its validity. Waiting for an arbitrary interval cannot establish success, and a missing explorer result alone does not explain which submission condition prevented confirmation.
Program Calls and Failure Logs
Program instructions and logs explain the execution path that a short transaction summary cannot fully describe. Solscan exposes instructions, inner instructions, program logs, and compute-unit information. The program ID identifies the deployed program involved in a call, giving an error message its relevant execution context.
Transfer instructions within a transaction succeed together or their changes revert. A program can report a successful step before a later instruction fails. An isolated success message in the logs therefore cannot establish that an earlier attempted transfer persisted. Read that message alongside the overall result and the recorded balance changes.
Compute units measure the computational work that the runtime performs during execution. Their count can help explain resource consumption, while the fee field answers the cost question. A consumed-unit count alone does not establish how much SOL the fee payer spent.
Transaction Details for a Transfer Query
A useful transfer query identifies the specific transaction and the movement under discussion. Keep the signature with the relevant sending and receiving addresses, asset identifier, amount, result, and recorded time. Those details let another person examine the same activity without guessing which entry in an account history matters.
An account overview supplies broader holdings and activity context, which can help relate a transaction to surrounding movements. Its current balance answers a different question from the balance change during one transaction. Later activity can change today's holdings without changing what the earlier transaction recorded.
Sharing an entire wallet view can expose holdings unrelated to the disputed transfer. Public blockchain data already makes those addresses searchable, and attaching personal details can connect that activity to an identity. A narrowly framed transaction query reduces unnecessary disclosure while preserving the details needed to discuss the transfer.
SOL and Lamport Units
Fee and balance comparisons need matching units before their numbers can describe the same movement. Solana records native balances in lamports, while Solscan can display a transaction fee in SOL. Divide a lamport amount by the number of lamports per SOL before comparing it with a SOL amount. The fixed conversion is 1 SOL = 1,000,000,000 lamports.
Solscan transactions: frequently asked questions
Does a Solana Transaction With Several Signers Have Several Transaction IDs?
A Solana transaction uses its first signature as the transaction ID, even when several accounts sign it. Other signatures authorize the same transaction; they do not identify separate payments within it. The identifier returned by the submission method is that first signature. A signer count therefore describes authorization requirements rather than the number of transfers or transaction records.
How Can an Older Transaction Be Missing From an RPC Status Lookup?
An RPC status request can miss an older transaction when it searches only the recent signature cache. Solana's getSignatureStatuses method uses that limited search unless the request enables searchTransactionHistory. A missing result from the cache does not establish that the transaction never existed. This limitation concerns that RPC method's search scope; it does not establish a retention limit for Solscan.
Is a Preflight Simulation Error the Same as an on-chain Transaction Failure?
A preflight simulation error concerns a test before submission, while an on-chain failure concerns actual network execution. Solana's submission method checks signatures and simulates the transaction during preflight unless the caller disables those checks. A simulation failure can stop that submission. The rule that network fees remain charged after an execution failure does not turn an unsuccessful simulation into an on-chain fee record.
Can a Larger Priority Fee Guarantee Confirmation?
A larger priority fee can improve scheduling priority without guaranteeing confirmation. The transaction must still satisfy the network's processing requirements. A transaction that uses a recent blockhash can also expire before it lands. The priority fee describes a scheduling input, while the transaction's execution result and confirmation status describe what actually happened.
Will Resubmitting an Identical Signed Transaction Create a New Transaction ID?
Resubmitting the identical, fully signed transaction preserves its transaction ID. Solana's sendTransaction method relays the supplied transaction without changing it, and the identifying signature already exists inside the transaction. If a wallet replaces the transaction's contents and obtains a different first signature, that signature identifies a different transaction.
What Does the Raw Tab Add to a Decoded Transaction Summary?
The Raw tab exposes the transaction's original instructions and bytes before decoding. A decoded summary makes the actions easier to read, while raw data supports closer inspection of the submitted representation. These views concern the same transaction. Raw data alone does not replace its execution result or balance changes when the question is whether a particular transfer completed.