One transaction, many instructions
On Bitcoin a transaction moves value from inputs to outputs. On Ethereum it is a call from one address to another. Both are simple enough that a naive explorer produces something readable.
Solana is structurally different. A transaction carries a list of instructions, each naming a program to invoke and the accounts that program may read or write. A single swap might contain eight instructions across four programs: create a token account, approve a delegate, invoke the exchange program, which internally invokes two liquidity pools, then close the temporary account. All atomic, all one transaction.
Shown raw, that is a wall of base58 addresses and byte arrays — technically complete and practically useless. The entire value of a Solana explorer is in decoding: knowing which program is the SPL Token program, that this instruction is a transfer, that the mint has six decimals so the raw integer means what it means.
Solscan maintains that decoding layer across the major programs and keeps it current as new ones appear. That is unglamorous, continuous work and it is why it is the default.
Failed transactions are normal here
This surprises everyone arriving from another chain, so it is worth stating plainly: on Solana, failed transactions are recorded on chain, cost a fee, and are common.
During busy periods a meaningful share of submitted transactions fail. Slippage exceeded. An account changed state between simulation and execution. The compute budget was exhausted. Your wallet may say "transaction failed" and leave you to work out which.
The important reassurance is atomicity. A Solana transaction either completes entirely or does nothing at all. There is no partial state where your tokens left but never arrived. If it failed, the only thing that happened was the fee — which is small.
Solscan shows which instruction failed, which program returned the error, and the error code with a decoded meaning where it has one. For the common cases that turns an opaque failure into something actionable: custom program error 6001 on a swap is usually slippage, and compute budget exceeded means the transaction needed more compute units than it requested.
Where your tokens actually live
Everything on Solana is an account: wallets, token balances, program code and program state. Each has an owner — the program permitted to modify it — and a lamport balance that must meet the rent-exemption minimum.
Your wallet address does not hold your USDC. It owns a separate associated token account, which holds it. One wallet with five different tokens has five token accounts, each a distinct on-chain address with its own rent-exempt balance.
So an address page has to show two different things: the SOL balance held by the wallet itself, and the token balances held by accounts it owns. Solscan handles this clearly. A generic multi-chain explorer frequently does not, which is why a Solana balance can appear to be missing on one tool and present on another.
The rent mechanic follows from the same design. Accounts must hold a minimum SOL balance to persist, so creating a token account costs a small amount — returned when you close it. It is a deposit, not a charge, though it does mean a wallet with no SOL cannot receive a token it has never held.
Why the official explorer still matters
Every commercial Solana explorer reads from infrastructure its operator controls. The official explorer reads from whatever endpoint you tell it to.
Change a dropdown and you are on devnet. Enter a URL and you are on a private cluster, a paid RPC provider, or a validator running on your own machine. For development that is not a convenience, it is the difference between having an explorer and not having one — testing a program on localnet with Solscan is impossible, because your local transactions do not exist as far as it is concerned.
It also matters for verification. Solscan decodes aggressively, and a decoder that does not recognise a program presents its best guess rather than announcing uncertainty. The official explorer shows decoded instructions alongside the raw account list and instruction data, so when two tools disagree the raw form settles it.
And it has a privacy consequence: point it at your own RPC and no third party learns what you looked at. That is the same argument Otterscan makes on Ethereum, available here without abandoning the mainstream tool.
Slots, blocks and what "confirmed" means
Solana produces a slot roughly every 400 milliseconds, and not every slot contains a block. Explorers show both slot and block height, and the two are not the same number — which confuses people comparing figures across tools.
Commitment levels are the other thing worth understanding. A transaction can be processed (seen by the node you asked), confirmed (voted on by a supermajority) or finalized (buried under enough subsequent blocks to be irreversible in practice). Explorers and RPC calls default to different levels, which is why a transaction can appear on one tool and not yet on another.
For anything consequential, finalized is the level that matters. For a wallet showing you that a swap went through, confirmed is what you are seeing, and it is almost always sufficient.
The practical consequence for exchange deposits is that Solana's thresholds are expressed in commitment level rather than confirmation count, which is a different mental model from Bitcoin's. Our guide on checking confirmations covers how the equivalent question is answered on each chain.