The custom RPC setting is the entire argument
Every other Solana explorer reads from infrastructure its operator controls. This one 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. The explorer is a front end over Solana's JSON-RPC, and the RPC is a parameter rather than a constant.
For development this 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 — your local transactions do not exist as far as it is concerned. Here they appear immediately.
It also has a privacy consequence worth noting. Point it at your own RPC and no third party learns what you looked at. That is the same argument Otterscan makes for Ethereum, available here without abandoning the mainstream tool.
Showing the raw data alongside the decoding
Solscan decodes aggressively, which is usually what you want and occasionally hides something. A decoder that does not recognise a program presents its best guess rather than announcing uncertainty, and a confident wrong reading is worse than an honest unreadable one.
The official explorer shows decoded instructions where it can and the raw account list and instruction data where it cannot — and it shows the raw form alongside, not instead. When you are developing a program, that raw view is what you check your serialisation against.
It is also the tie-breaker when two explorers disagree about a transaction. The raw instruction data is the ground truth; everything else is interpretation. Being able to see it settles arguments that otherwise go in circles.
The account model, shown correctly
Everything on Solana is an account: wallets, token balances, program code, and program state. Each account has an owner, which is the program permitted to modify it, and a lamport balance that must meet the rent-exemption minimum.
The official explorer presents this structure directly. An account page shows the owner program, the data size, the rent-exempt status and the raw data. That is a more faithful rendering of Solana than a balance-and-transactions layout, which is what several third-party explorers impose.
It makes the recurring confusion legible too. Your wallet does not hold your USDC — an associated token account, owned by the SPL Token program, does, and your wallet owns that account. Seeing the ownership chain laid out explains the model in a way that a list of balances never will.
The RPC underneath
Because this is a thin front end, the API question is really about Solana's own JSON-RPC. The public mainnet endpoint works without a key — we confirmed it — and returns slot, epoch, account and transaction data:
curl -X POST https://api.mainnet-beta.solana.com \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}'It is heavily throttled and explicitly not for production. For a status widget or occasional lookup it is free and needs nothing, which is why the live figures on this site use it.
For anything serious you want a dedicated RPC provider, and then this explorer pointed at the same endpoint gives you a visual view of exactly the data your application sees. That alignment — same source, same results — removes a whole category of debugging confusion.
Which to use
Use the official explorer for development, for devnet and localnet, for verifying a decoded reading against raw data, and when you would rather not tell a third party what you are looking at.
Use Solscan for everyday reading — the decoding is richer, token and NFT handling is considerably better, and for working out why a swap failed it will get you there faster.
Most Solana developers end up with both open, which is the sensible outcome rather than a failure of either.
What our reference tests showed
We ran the official explorer against the same Solana items we used for Solscan: a plain SOL transfer, an SPL token transfer, a failed swap, an NFT mint, and a transaction on a local validator that no hosted explorer can see.
The first four rendered correctly with less decoding than Solscan, exactly as expected. The failed swap named the failing instruction and returned the program error code without translating it into plain language — enough to diagnose if you know the program, less helpful if you do not.
The fifth item is the one that matters. Pointing the explorer at a local validator took one field change, and transactions that existed nowhere else appeared immediately. We repeated the exercise against devnet with the same result. No other Solana explorer we tested can do this at all.
We also used it as the tie-breaker in a case where two explorers presented the same transaction differently, and the raw instruction data settled it in under a minute. That is a small thing until the moment you need it, and then it is the only thing that helps.