How to read a Solana explorer: accounts, transfers and swaps

Open the right record on the right network

An explorer is a web interface to network data. Search can accept several kinds of identifiers, and the resulting page depends on what you entered. A transaction signature opens an operation; an account address opens a record of state. A mint is an account address describing a token issuance.

Choose mainnet, devnet or testnet before interpreting the result. The same address can be queried on different clusters with different state. A missing result in the wrong cluster is a search-context error.

Begin from a transfer in your wallet's activity list and use its explorer link, or copy the full signature into your preferred explorer. Record the cluster and signature together. A cropped screenshot that hides both is difficult for someone else to investigate.

Different explorers organise information differently. The underlying questions remain stable: did execution succeed, what programs ran, which accounts changed and what did it cost? Use those questions rather than relying on a particular page layout.

Read execution and finality as separate answers

A transaction's execution result states whether its instructions completed. RPC metadata represents success with a null execution error; an error identifies a failed result. An explorer may express that through labels, icons or a detailed error panel.

Commitment or finality describes the network's accepted history under its current protocol. A transaction can be final and failed. That means the failure is recorded in the accepted result; it does not mean the requested token transfer succeeded.

Current Foundation migration guidance says confirmed and finalized describe the same state on Alpenglow-migrated clusters and recommends finalized for new code. Avoid using an older explorer tutorial's fixed slot countdown as a current finality rule.

Also distinguish block time, slot and the time your browser obtained the record. They describe different aspects of the observation. Current Solana streaming can have multiple candidate banks in a slot, so a slot number alone is insufficient as a universal identity for every candidate observation.

Follow the programs that performed the action

The instruction list shows which programs the transaction asked to run. A simple SOL payment can call the System Program. A token payment calls the relevant token program. An application instruction can make inner calls to other programs during execution.

For a swap, find the application's outer instruction, then inspect the token transfers and any account setup or cleanup around it. A human label such as Swap is a decoded description; the actual program ID, accounts and instruction data define the request.

Logs help locate execution progress and errors. An early message saying that one instruction ran does not establish that the whole transaction completed. A later instruction can fail and roll back application changes.

If an explorer cannot decode an unfamiliar program, retain its address and raw context. You can still inspect execution, account changes and published program documentation. An unlabelled instruction is a decoding limitation, not proof of a failed or malicious transaction.

Finality and execution answer different questions

Reconcile a payment and a swap

For a teaching SOL payment, Alice sends 0.25 SOL and pays an example fee of 0.000005 SOL. The sender's balance decreases by 0.250005 SOL, while the destination gains 0.25 SOL. If a page shows only the sender's total decrease, it can look larger than the agreed payment.

For a teaching token swap, suppose an account spends 10 USDC and receives 0.05 SOL, with these chosen amounts used only to explain the record. Identify the input and output mints and compare relevant token balances. Then separately inspect native SOL movement.

SOL movement can include a network fee, account funding and the return of lamports when a temporary account closes. A swap involving wrapped SOL may create, use and close a native token account. The final native balance therefore needs the whole instruction context.

When token-account indices refer to the transaction's account list, ensure the reader resolves the complete list, including address lookup data for formats that use it. Matching one token change to a shortened wallet label can hide a different account's movement.

The final test is reconciliation: the changes should explain the intended action and its costs. This is stronger evidence than a single green badge.

Read an account page according to its type

An account page can show lamports, data size, owning program and whether it is executable. The owner field identifies the program responsible for its data rules. It is different from a user authority recorded inside token or application data.

For a token account, look for the mint, quantity and authority. For a mint, look for decimals, supply and applicable controls. For a program, inspect executable and loader information and any relevant upgrade authority.

An account page usually shows current state alongside selected history. The current authority does not establish who held the role before a past transaction. Historical questions need data from the relevant observation or transaction.

Continue with owner versus authority when these fields look contradictory. They describe different layers of permission.

Use three short investigation patterns

A straightforward payment: identify the transfer instruction, check successful execution and compare the destination's change with the agreed amount. Keep the network fee separate.

A composed swap: identify the trading program and mints, follow inner transfers and reconcile token and SOL changes, including account cleanup. Compare actual output with the accepted bound and quote under the same units.

A failed transaction: read the error, locate its instruction and relevant logs, then inspect the recorded fee. Do not add up provisional log messages as though all application changes survived.

For a useful investigation note, save the explorer URL or signature, cluster, asset identities and the fields supporting your conclusion. If a receiving service has another crediting stage, keep that record alongside the network result.

Common questions