On this page
- Start with the transaction signature and the right network
- What do processed, confirmed and finalized mean?
- Check execution success separately
- Match the transfer, not just the status label
- Why does a lookup return null or no record?
- Why can a successful transfer still be missing from a service balance?
- Frequently asked questions
- Sources and scope
To verify a Solana transaction, look up its transaction signature on the correct network, read its confirmation status, and check whether execution succeeded. Then match the transfer details to the asset, amount and recipient you expected. A transaction can be finalized without being a successful transfer, and a successful transfer does not by itself prove that a service has credited your account.
The useful question is therefore more specific than “Has it gone through?” You may need to establish whether a record exists, how firmly it is confirmed, what it actually did, or why a receiving account has not changed. Each requires a different check.
Start with the transaction signature and the right network
Find the transaction reference attached to the existing transfer in the sending wallet or service. On Solana, the transaction ID, or txid, is the transaction’s first signature. A withdrawal request number supplied by a service is not automatically that on-chain reference. Solana’s signature-status documentation identifies which signature is used for lookup.
Use a Solana explorer to inspect the public record. Solana’s cluster documentation explains that explorers can select different networks. Check that the selected cluster matches the transaction you are investigating: Mainnet is the production network, while Devnet and Testnet serve testing purposes. A record on a test network does not establish a production transfer.
Copying the complete signature avoids confusing it with a wallet address or a token identifier. If you have only an internal request number, check whether the sending service has provided a transaction signature yet. The existence of a request is a different fact from a transaction appearing on-chain.
What do processed, confirmed and finalized mean?
These terms describe commitment: how firmly the network has confirmed the block containing the transaction. Solana’s RPC overview distinguishes three levels:
- Processed: the node has processed the block, but that view can still be rolled back.
- Confirmed: a supermajority of active stake has voted directly on the block. This is a stake threshold, not simply a count of validators.
- Finalized: the network recognizes the block as finalized with maximum lockout, its strongest confirmation state.
A processed record is therefore less settled than a finalized one. But these labels do not answer whether the transaction’s instructions succeeded. Nor do they promise a particular number of seconds until a service credits a balance.
When comparing two lookups, also check what confirmation level each requested. A tool looking for finalized data can show a different result from one looking for confirmed data at the same moment.
Check execution success separately
A returned transaction record has another question to answer: did execution succeed or fail?
In a returned signature-status object, err: null indicates success, while an error value indicates failure. Transaction details obtained through getTransaction place that information in meta.err. First make sure the transaction and its metadata were actually returned; a missing record is not the same as a record containing a null error. These distinctions appear in Solana’s signature-status reference and transaction reference.
| Illustrative lookup result | What it tells you | What remains to check |
|---|---|---|
Status object: processed, err: null | Execution succeeded in the node’s processed view. | The view can still be rolled back; check the later confirmation state. |
Status object: confirmed, err: null | Execution succeeded and the block is confirmed. | It is not yet the finalized state. Match the actual transfer details. |
Status object: finalized, an error value | The finalized record reports failed execution. | Read the error; finality has not turned failure into a successful transfer. |
Status object: finalized, err: null | Execution succeeded at the strongest confirmation level. | Check asset, recipient and amount; verify service credit separately. |
| No transaction or status object returned | This lookup has not established the transaction’s outcome. | Check the signature, cluster, requested commitment and available history. |
For example, a finalized record with an execution error is evidence of a recorded failure. Reading only “finalized” and assuming the intended recipient received the intended asset would miss the result that matters.
Match the transfer, not just the status label
Once you have a successful record, check whether it describes a native SOL transfer or an SPL token transfer. The fields you need to match differ:
- Asset: for native SOL, verify that the action transfers SOL. For an SPL token transfer, identify the token mint rather than relying only on a displayed name such as USDC.
- Recipient: for native SOL, inspect the receiving account. For an SPL token transfer, inspect the destination token account and its owner where available. A token account and the wallet that owns it are distinct; do not assume every address shown must equal the wallet address you recognize.
- Amount: compare the relevant transfer amount with what you intended. Keep SOL and lamport units consistent when reading native SOL amounts; for tokens, use the decimals for the relevant mint.
- Context: check whether the transaction contains several transfers or other actions that need separate interpretation.
Solana’s transaction reference distinguishes native balances reported in lamports from token-balance fields. Its verification guide explains mint checks for tokens and the limits of comparing balances before and after execution. A balance difference shows a net change. It does not necessarily reveal each transfer in a transaction with multiple actions. The JSON reference describes token-balance fields, including the mint and, when recorded, the token-account owner.
This is also where the receiving service’s instructions matter. An issuer’s token identifier is not your personal deposit address. For that distinction, see USDC on Ethereum versus Solana. A technically successful transfer can still differ from the asset or destination a service asked you to use.
Why does a lookup return null or no record?
“No record” needs investigation, not an automatic verdict of failure or refund.
getSignatureStatuses normally searches a recent status cache. Its searchTransactionHistory option expands the search to the node’s ledger history; it is not a promise that every node can return every historical transaction. A null entry leaves the outcome unresolved by that lookup. Check the full signature and cluster, as well as the history available to the tool. Source: Solana signature-status reference.
getTransaction can return null when the transaction is not found or is not confirmed at the requested commitment. A stricter lookup can therefore fail to return details that are not yet available at that level. Source: Solana transaction reference.
The location of a null value matters:
- A null transaction result or status entry: no transaction or status object was returned there.
meta: null: the transaction’s metadata is unavailable; you have not read an execution result from it.err: nullinside an actual status or metadata object: execution succeeded.confirmations: nullinside a signature-status object: the transaction is rooted and finalized; this is not an error indicator.- A missing or null
confirmationStatus: no explicit stage is supplied in that field.
Likewise, an unavailable blockTime is a missing timestamp, not proof of failed execution. Read the field’s meaning rather than treating every null as “nothing happened.”
Why can a successful transfer still be missing from a service balance?
An on-chain record establishes what happened on the selected blockchain. It does not show every step in a service’s internal deposit processing or prove that the service accepts the representation you sent.
If the intended transfer is successful but the receiving account has not been credited, compare the record with that service’s current receiving instructions and status information. Keep the transaction signature, network, asset, amount and relevant service reference together when asking its support team to investigate. Those details make the unresolved question clearer than a screenshot of “success” alone.
Do not assume that sending again will resolve an unclear first transfer. Establish what the first record shows before deciding what, if anything, to do next. A confirmation label supplies neither a universal credit deadline nor a recovery or refund promise.
For the broader distinction between funding an account, holding a position and receiving withdrawn funds, see how to trade prediction markets. Blockchain finality is also separate from a prediction market’s event resolution: one concerns the chain record, the other the contract’s outcome rules.
Frequently asked questions
Is a transaction signature proof that payment succeeded?
No. It identifies the transaction to look up. You still need a record on the correct cluster, its execution result and the transfer details. A service request reference may not be an on-chain signature at all.
Does finalized mean the intended transfer succeeded?
Not by itself. Finalized describes the network’s confirmation state. Check the error field in an actual returned status or metadata object, then match the asset, recipient and amount.
Does null mean my transaction failed?
Not necessarily. A null result can mean the lookup did not find a record at the requested commitment or within the available history. That differs from an actual record reporting an execution error.
Why can the recipient token account differ from the wallet address?
Solana’s token data distinguishes the account holding a token balance from that account’s owner. Check both in context rather than treating any different address as proof of a wrong recipient. A complex transaction may require its individual transfers to be examined.
Does on-chain success guarantee a credited service balance?
No. It does not by itself establish the service’s acceptance of the asset, its internal processing state or the balance available to you. Use the successful transfer record together with the receiver’s applicable instructions and account information.
Explore market questions
Review market questions, rules and applicable service conditions separately from checking a blockchain transfer.
Sources and scope
Explains Solana transaction records using official RPC, cluster and payment-verification documentation. The status table is illustrative; it does not show live transactions or establish a receiving service’s processing time.
HypaForecast publishes educational guides and operates a prediction-market service. This guide does not establish a supported funding route or eligibility to use a service.
Share this guide