A Solana transaction explorer turns a raw signature into a readable page: did it succeed, who signed it, what it cost and which tokens moved. Every explorer, from Solscan to the official Solana Explorer to our own lookup tool, reads the same on-chain record through the getTransaction RPC method, so once you know what each field means you can read any of them. Below you will find a six-step routine, a field-by-field breakdown of a transaction page, a worked example using a real SPL token transfer and a troubleshooting section for transactions that fail, go missing or get dropped.
How to check a Solana transaction in six steps
The fastest way to check a transaction is to copy its signature, paste it into an explorer on the right cluster and read the status line first. Everything else on the page explains why that status is what it is.
- Copy the transaction signature. Your wallet's activity screen or the dApp's confirmation toast will have a "view on explorer" link or a copy button. The signature is base58 text, typically 87 or 88 characters.
- Paste it into an explorer. Use the Solscanner lookup tool, Solscan or Solana Explorer, and check that the Mainnet cluster is selected rather than Devnet.
- Check status and finality. Success or failed is the headline. Next to it, look for processed, confirmed or finalized.
- Read fee, compute and signers. These tell you who paid, how much, and how heavy the transaction was.
- Inspect instructions and balances. The instruction list and token balance changes show what actually moved between which accounts.
- Use logs to explain failures. If something went wrong, the program logs name the instruction and the error.
That routine answers most “did my transfer arrive?” questions in under a minute. The rest of this guide covers what you see at each step, so you can read the page instead of guessing.
What each field on a Solana explorer transaction page means
A Solana explorer transaction page has the same core fields everywhere: signature, result, commitment, slot, block time, fee, compute units, signers, recent blockhash, version, instructions, balance changes and logs. Layouts differ, but the underlying data comes from one RPC response.
Signature. A transaction signature is the 64-byte Ed25519 signature of the first signer, encoded in base58. It doubles as the transaction’s unique ID. If a transaction has several signers, it carries several signatures, but explorers index it by the first one.
Status. Either success or an error such as InstructionError with the index of the failing instruction. A failed transaction is still recorded on chain and still pays its fee.
Commitment (processed, confirmed, finalized). These are the three finality levels. Processed means the node you asked has seen the transaction in a block, but that block has not been voted on yet. Confirmed means a supermajority of stake has voted on the block. Finalized means the block has reached maximum lockout and cannot be rolled back. Treat processed as “probably”, confirmed as “almost certainly” and finalized as “done”. Alpenglow, which is on testnet in September 2026 with no mainnet date announced, aims to cut finality to around 150 ms, so these labels may collapse in future.
Slot and block time. The slot is the leader’s time window in which the transaction landed. Slots now run at roughly 250–300 ms after SIMD-0525 cut them from 400 ms in August and September 2026. Block time is the estimated Unix timestamp of that block, shown in your local time zone by most explorers.
Fee and priority fee. The base fee is 5,000 lamports per signature (0.000005 SOL); 50% is burned and 50% goes to the validator. An optional priority fee is added on top: compute-unit price times compute-unit limit, divided by 1,000,000, and it goes entirely to the validator. The full formula is in the Solana fees documentation. Some explorers split the two; others show only the total.
Compute units. Compute units consumed measure execution cost. The default budget is 200,000 CU per instruction and the hard cap is 1,400,000 CU per transaction. Seeing a transaction use close to its requested limit is a hint that it failed for running out of compute.
Signers and fee payer. The first signer is the fee payer. Other signers authorised specific instructions, for example the owner of a token account being debited.
Recent blockhash. Every transaction references a recent blockhash that is valid for 150 slots. It stops replays and sets a deadline: if the transaction is not included before the blockhash expires, it can never land.
Versioned transactions and address lookup tables
A versioned transaction (shown as “v0” or “Version 0”) can reference an address lookup table, an on-chain account that stores a list of addresses. Instead of writing every 32-byte address into the message, the transaction points at entries in the table. That is how large swaps fit inside the 1,232-byte limit. Explorers mark these accounts as “loaded from lookup table” in the account list; a “legacy” label simply means the older format without tables. The transactions documentation covers the message layout.
Note: a transaction can list at most 64 accounts. If you see an account list longer than you expected, most of it was probably loaded from an address lookup table rather than written into the message itself.
Instructions, inner instructions and token balance changes
Instructions are the actual operations: each one names a program and the accounts it touches. Inner instructions are calls that one program made to another during execution, and token balance changes summarise the net result.
A plain SOL transfer has one System Program instruction. A token transfer calls the SPL Token program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) or Token-2022 (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb). A swap through an aggregator might show one top-level instruction and a dozen inner instructions as the router calls several DEX pools, each of which calls the token program. When you want to know what really happened, inner instructions are where you look. For pools and routers, our DeFi explorer guide explains how to follow liquidity across programs.
The token balances section is the plain-English summary: pre-balance, post-balance and the difference for every token account touched. It is the section to screenshot when someone asks for proof of payment. Token accounts are separate from wallets, so the rows show token account addresses with their owner next to them; the wallet explorer guide explains associated token accounts in more detail, and the token explorer guide covers mints and decimals.
Reading program logs
Program logs are the text messages programs print while they run. They are the single most useful field when a transaction fails, because the error is usually spelled out in the last few lines.
Logs read top to bottom as a call stack: “Program X invoke [1]”, messages, “Program X consumed N of M compute units”, “Program X success”. A failed run ends with “failed:” and an error such as insufficient funds, slippage tolerance exceeded or a custom error code. Custom codes are program-specific; decode them with the program’s IDL, which Solana Explorer and Orb display for verified programs.
A Solana transaction explorer example: a real SPL token transfer
Here is a real mainnet transaction you can open yourself. It is a simple SPL token transfer, which makes it a clean example for learning the layout.
WdQE153MoVzxf54wemBxUPXo88x6FDC4VDX2B2zKR9tF2j42QyaM1ub4R8ww7iY2fPcJ3b9F15eMcxCyVu9Sn4X
Paste that signature into our lookup tool and you will see these values:
| Field | Value | What it tells you |
|---|---|---|
| Status | Success | All instructions executed |
| Slot | 449,561,050 | Where it landed on chain |
| Fee | 5,000 lamports | Base fee only, one signature |
| Priority fee | 0 lamports | No fee bid on top |
| Compute units | 13,594 | Light token-program work |
| Signer | ATAPZ…edYj5 | Fee payer and authority |
Read it the way you would read a receipt. The fee is exactly 5,000 lamports, which equals one signature at the base rate, so the sender paid no priority fee and there is exactly one signer: ATAPZxbrc7BAiunpoQPeGiPUbQgx5mGTNgyZgMPedYj5. That account both paid the fee and authorised the debit from its token account. The 13,594 compute units are a small fraction of the 200,000 CU default budget, which is typical for a single token-program transfer. In the instruction list you will see the token program’s transfer, and in token balance changes one account goes down and another goes up by the same amount. Open the same signature on Solscan or Solana Explorer and the numbers match, because all three read one ledger.
How to check a transaction on Solscan and other explorers
Solscan, Solana Explorer and Orb all accept a signature in the main search box, and each presents the same fields with different emphasis. Choosing one is mostly about how you like to read.
Solscan puts an overview card at the top and moves token transfers into a dedicated tab, which is why many people searching “Solscan how to check transaction” end up there. Our Solscan review covers its tabs in detail. Solana Explorer, run by the Solana Foundation, shows raw instruction data, compute-unit profiling and a simulation option, which developers like. Orb by Helius adds AI-written plain-language summaries of what a transaction did. If you want a side-by-side verdict, see the best Solana explorers ranking. For Jito bundles, where several transactions land together with a tip, the Jito bundle explorer guide is the better starting point.
Transaction not found, failed or dropped: how to fix it
“Not found” usually means the transaction never landed, “failed” means it landed but an instruction errored, and “dropped” means it expired before any leader included it. Each has a different fix.
Transaction not found
First rule out the easy mistakes. Check that you copied the whole signature, since a missing final character gives a valid-looking but unknown string. Check the cluster: a devnet signature will never appear on mainnet, and the devnet explorer guide lists the right URLs. Then wait a few seconds and search again, because a node that is lagging may not have indexed the block yet. If it is still missing after the blockhash window has passed (150 slots, well under a minute at current slot times), the transaction was not included.
Transaction failed
A failed transaction appears on chain with an error, and the fee is charged. Scroll to the logs and read the last “failed” line. Common causes are slippage on swaps, too little SOL left for rent, a token account that does not exist yet, or exceeding the compute limit. Fix the cause and send a new transaction. Retrying the same signed message will not help.
Transaction dropped
A dropped transaction was sent to the network but no leader included it before its recent blockhash expired. It has no signature record at all, so no fee was charged and nothing moved. Congestion and a zero priority fee are the usual reasons. Your wallet can resend with a fresh blockhash and a small priority fee. If an explorer seems to be failing rather than the transaction, our explorer down page lists alternatives, and the getTransaction reference shows what the underlying RPC call returns.
Why a Solana transaction explorer beats wallet history alone
A wallet’s activity list is a summary written by the wallet app; a Solana transaction explorer shows the on-chain source of truth. When the two disagree, trust the explorer.
Wallets hide inner instructions, round balances, and sometimes mislabel swaps as sends. They also cannot help when a counterparty insists they paid you. With the signature in hand, anyone can verify status, finality and the exact token movement in seconds, with no account and no trust in either party. That is the whole point of a public ledger, and it takes about thirty seconds once you know which fields to read. If you are new to explorers in general, start with what a Solana explorer is and come back here for the details.
By the Solscanner research deskUpdated · Review methodology