The widget above is already set to devnet. Paste a devnet signature, wallet or program address and it reads straight from api.devnet.solana.com; switch the network selector to testnet or mainnet when you need a different cluster. The rest of this page explains how a Solana devnet explorer works in Solana Explorer and Solscan, how to point an explorer at a local validator, how the faucet behaves in September 2026, and the handful of mix-ups that cause nearly every “transaction not found” message during development.
What are Solana clusters, and why does the explorer care?
A cluster is an independent Solana network with its own ledger, validators and RPC nodes. Solana runs three public clusters: Mainnet Beta (real SOL), Devnet (app testing) and Testnet (validator and release testing). A transaction or account on one cluster does not exist on the others, so an explorer has to know which cluster to query.
The official clusters reference lists one public RPC endpoint per cluster:
- Mainnet Beta:
https://api.mainnet-beta.solana.com - Devnet:
https://api.devnet.solana.com - Testnet:
https://api.testnet.solana.com
All three share the same published limits: 100 requests per 10 seconds per IP, 40 requests per 10 seconds for a single RPC method, and 40 concurrent connections. They are meant for testing and light use, not for production apps. In our own September 2026 tests, the devnet and testnet endpoints answered browser requests reliably, while the mainnet endpoint returned HTTP 403 from our test IP. That is why the Solscanner lookup tool rotates across other keyless nodes for mainnet (details on our Solana explorer API page) but uses the official endpoints for devnet and testnet.
Devnet or testnet: which one should you use?
Use devnet unless you have a specific reason not to. Devnet mirrors the software mainnet runs, has a faucet, and is where wallets, SDKs and tutorials default when they say “test”. Testnet is where validator operators and core engineers trial new releases before mainnet. In the week of 22 September 2026, for example, the Alpenglow consensus upgrade was activated on testnet while its mainnet date was still unannounced. That makes testnet useful for watching network upgrades, and less predictable for app work.
Both test clusters can be reset, and test SOL has no market value. Never treat a devnet balance as money, and never paste a mainnet private key into a tool just because it “only” targets devnet.
How to open the Solana explorer on devnet in 5 steps
The short version: add a cluster parameter to the URL. The longer version is below, and it doubles as a checklist when a signature refuses to show up.
- Confirm which cluster you used. Run
solana config get, check your wallet's network setting, or read the RPC URL in your code. That cluster is the only place the explorer can find your transaction. - Open the explorer on devnet. Add
?cluster=devnetor?cluster=testnetto a Solana Explorer or Solscan URL, or pick Devnet in the lookup widget's network selector above. - Paste the signature or address. A transaction signature is typically 87–88 base58 characters; an account address is 32–44. The page then loads from that cluster's RPC node.
- Point the explorer at localhost. For a local
solana-test-validator, choose Custom RPC in Solana Explorer and enterhttp://localhost:8899. - Fund a test wallet. Request test SOL at faucet.solana.com or with
solana airdrop. You need it for fees and rent before any test transaction can land.
Once the page loads, reading a devnet transaction is identical to mainnet: status, fee, compute units, instructions and balance changes. Our transaction explorer guide walks through each field.
Devnet explorer URLs for Solana Explorer and Solscan
Both major explorers accept a cluster query parameter, so a devnet explorer URL is simply the normal URL with that parameter appended. This is also the easiest way to share a devnet link with a teammate, because the cluster travels inside the link.
| Explorer | Devnet | Testnet | Local / custom |
|---|---|---|---|
| Solana Explorer | ?cluster=devnet | ?cluster=testnet | Custom RPC in cluster menu |
| Solscan | ?cluster=devnet | ?cluster=testnet | Not the main use case |
| Solscanner lookup | Network selector | Network selector | No |
Concrete patterns you can bookmark:
https://explorer.solana.com/tx/<signature>?cluster=devnethttps://explorer.solana.com/address/<address>?cluster=testnethttps://solscan.io/tx/<signature>?cluster=devnethttps://explorer.solana.com/?cluster=custom&customUrl=http://localhost:8899
The official Solana Explorer from the Solana Foundation is the most complete option for test clusters. Its source code on GitHub defines four cluster choices (Mainnet Beta, Testnet, Devnet and Custom RPC), and features such as the IDL tab, Anchor account decoding and instruction simulation work on devnet too. Solscan at solscan.io is fine for quick devnet lookups, although some of its analytics dashboards and token labels are mainnet-first. Not every explorer covers test clusters at all, so if you use a different tool, check its docs before relying on it for devnet.
Using a custom RPC or localhost with solana-test-validator
Solana Explorer can read from any RPC URL you give it, including a validator running on your own laptop. Start solana-test-validator (its JSON-RPC listens on port 8899 by default), then choose Custom RPC in the cluster menu and enter http://localhost:8899. Because the explorer runs in your browser, the request goes from your machine to your machine, and no data leaves your computer.
This is the fastest feedback loop for program development. Deploy with Anchor or the Solana CLI, send a test instruction, and open the signature in the explorer to see decoded logs, compute units and account changes. When you reset the local ledger, the explorer shows nothing again, which is expected.
The Solana developer guides now also point to Surfpool, a local validator that pulls the mainnet accounts and programs your transactions depend on and ships its own web studio. If you use it, the same idea applies: point your explorer at the local RPC URL it prints on startup.
You can also paste a private or paid RPC endpoint into Custom RPC. That helps when the public devnet endpoint is rate-limiting you during a heavy test run. The program explorer guide covers what to check once your program is deployed.
Getting test SOL: faucet and airdrop notes for 2026
You need test SOL for fees and rent even on devnet. The web faucet at faucet.solana.com serves devnet and testnet. At the time of writing, it allows a maximum of two requests every eight hours without signing in, and a GitHub login raises that limit (the faucet validates GitHub accounts, and some do not pass).
The command-line route is:
solana config set --url devnet
solana airdrop 2
solana balance
solana airdrop calls the RPC requestAirdrop method on the public endpoint, which is often rate-limited when many developers hit it at once. If it fails, use the web faucet, wait and retry, or run a local validator where you can airdrop yourself as much as you like.
Remember the fee math is the same as mainnet: 5,000 lamports per signature as the base fee, plus any priority fee, and rent-exempt deposits for new accounts. A test wallet with a fraction of a SOL goes a long way, but program deployments need more because the program account holds its bytecode.
Scam warning: nobody can sell you devnet SOL that turns into real SOL, and no faucet needs your seed phrase. Sites that promise “mainnet airdrops” in exchange for connecting a wallet or paying a fee are phishing. Test SOL only exists on test clusters.
Why your devnet transaction shows “not found”
In most cases the explorer is simply looking at the wrong cluster. Before you debug your code, confirm that the explorer’s cluster matches the RPC URL you sent the transaction to. Here are the confusions we see most often, roughly in order of frequency.
The explorer defaulted to mainnet. Solana Explorer and Solscan open on Mainnet Beta. If you paste a devnet signature without ?cluster=devnet, you get a “not found” page even though the transaction is perfectly fine. Wallet apps make this worse: the “view on explorer” link sometimes drops the cluster parameter.
Your wallet and your code disagree. Your browser wallet may be on devnet while your script uses a mainnet RPC URL, or the other way round. The wallet signs, the script sends, and the transaction lands on a cluster you did not expect.
The transaction never landed. A Solana transaction references a recent blockhash that stays valid for 150 slots, as the transactions docs explain. At the current ~250–300 ms slot time, that is well under a minute. If your client did not wait for confirmation, or the network dropped the transaction, there is nothing to find on any cluster. A simulated transaction is never on-chain either.
Commitment mismatch. If your code waited only for processed, a block can still be rolled back. Explorers generally query at confirmed or finalized, so a very fresh signature may take a few seconds to appear.
Address confusion across clusters. Program IDs can be the same on several clusters: the pump.fun program, for example, lives at the same address on mainnet and devnet. Token mints usually are not. Devnet USDC has a different mint from mainnet USDC, so a “missing” token balance often means you used the mainnet mint in a devnet test. Our token explorer guide explains how to verify a mint.
Which Solana dev explorer is best for test clusters?
For devnet and localhost work, Solana Explorer is the strongest choice because it supports custom RPC URLs and decodes Anchor programs. Solscan is a good second tab for quick devnet lookups. For mainnet-only analytics, see our ranked list of the best Solana explorers.
A practical setup many developers use:
- Solana Explorer on Custom RPC for the local validator during the build phase.
- Solana Explorer or Solscan with
?cluster=devnetfor shared test deployments and QA links. - The Solscanner lookup tool for a quick, no-frills check of a devnet balance or signature, especially when you want to flip between devnet, testnet and mainnet with one selector.
If you are new to explorers in general, our beginner guide to reading a Solana explorer explains accounts, signatures and slots before you start testing.
Devnet explorer habits that save debugging time
A few habits prevent most test-cluster headaches. First, always log the full explorer URL, with the cluster parameter, next to every signature your scripts print. Second, keep one environment variable for the RPC URL and derive both the wallet connection and the explorer link from it, so they can never disagree. Third, when you share a devnet bug report, include the cluster, the signature and the commitment level you waited for.
Finally, treat devnet as disposable. Keep deployment scripts that can recreate your test accounts and mints from scratch, because both test clusters can be reset and faucet limits make large re-funding slow. When everything works, the same explorer habits carry over to mainnet unchanged; you only drop the ?cluster= parameter.
By the Solscanner research deskUpdated · Review methodology