✳ SOLANA ACADEMYCourse overview

Basic · LESSON 03 OF 06

3. Networks and transaction explorers

By the end, you can check a transaction on the correct cluster.

A transaction investigation binds the cluster and signature to separate status and detail requests, checks resulting account state, then limits the conclusion to the provider evidence.
3. Networks and transaction explorers workflow. A transaction investigation binds the cluster and signature to separate status and detail requests, checks resulting account state, then limits the conclusion to the provider evidence.

Read the workflow

Begin with the selected cluster and exact transaction signature. Query getSignatureStatuses for status, slot, confirmation level, and execution error; the default search covers a recent cache, while older lookup may request retained history. Separately call getTransaction at a stated commitment and inspect its transaction and metadata. Check the account or token state relevant to the claim. Either RPC method may return null independently. A null result does not prove that the transaction never existed. A rate limit or provider error is scoped to that request; record its source, options, cluster, and observation time before cross-checking.

  1. CLUSTER + SIGNATURE
  2. getSignatureStatuses
  3. getTransaction + ACCOUNT STATE
  4. SCOPED CONCLUSION

FIELD NOTE 01

Choose the environment before searching

Solana has separate clusters with different purposes and state. Mainnet is the production network, where SOL and issued assets have real value. Devnet is the public application-development environment; it provides test SOL and its ledger may reset. Testnet is used to exercise releases and validator performance, and may run software newer than Mainnet. A local validator is a separate development environment on your computer. The same public key can exist on each cluster without referring to the same account state. Select the intended cluster in both the explorer and the RPC tool before you search. Treat a cluster name as part of every address, signature, screenshot, and lab result.

FIELD NOTE 02

Start with a repeatable identifier

For a transaction claim, capture its exact base-58 signature and the cluster where it was submitted. Add the explorer or RPC provider, observation time, and requested commitment. A screenshot of a green status is not enough if another person cannot repeat the lookup. Do not infer a cluster from an address or from a familiar token name. If two explorers disagree, first compare their selected cluster, signature, commitment, and observed slot; one page may simply be behind. Keep observations from separate providers instead of silently choosing the one that supports your expectation.

FIELD NOTE 03

Ask the status question separately

getSignatureStatuses asks what a node currently knows about a transaction signature. Its default search covers a recent status cache, not the node’s complete retained history. For an older signature, set searchTransactionHistory to true if the provider supports and retains that history. Read the returned slot, confirmationStatus, and err together. A null entry means that the requested search returned no status from that RPC. It does not establish that no validator ever processed the signature, and it does not tell you whether the intended account change occurred. Record the method and its options beside the result.

FIELD NOTE 04

Then request the transaction details

getTransaction is a different lookup with its own commitment request. A returned object includes the transaction, slot, and metadata when available. Check meta.err for execution outcome and meta.fee for the fee recorded for that transaction; a nonzero fee is not proof of success. Compare the expected program instructions with the actual message, then inspect the relevant post-transaction account or token state. For versioned transactions, supply a maxSupportedTransactionVersion accepted by your reader; an unsupported-version RPC error is a capability problem, not evidence that the transaction is missing. Preserve the exact request options so someone else can reproduce the observation.

FIELD NOTE 05

Interpret the response without overclaiming

A null getTransaction result means that this RPC did not return a transaction at the requested commitment. It can reflect the wrong cluster or signature, a transaction that is not yet confirmed at that commitment, or limits in the provider’s retained ledger. It is a narrower result than “the transaction never happened.” An HTTP 429 is different: the endpoint is rate-limiting the request, so no transaction conclusion follows. A JSON-RPC error such as an unsupported transaction version is also not a null result. Resolve the request or provider problem first, then repeat with a suitable source. Solana documents that public RPC endpoints are not intended for production applications. They are useful for learning, but are rate-limited and are not production service guarantees.

FIELD NOTE 06

Build a claim from independent observations

Suppose a learner reports a Devnet transfer. The signature-status result can show that a node observed the signature and its confirmation level. The transaction response can show the execution error, fee, and message. A subsequent account read can test whether the intended recipient state changed. Those observations answer different questions; do not substitute one for another. If the transaction is still awaiting the requested commitment, report it as pending at that observation time. If meta.err contains an error, report execution failure and any recorded fee separately. If the status and transaction lookups both return null, report only that this provider did not return results for those requests and cross-check before making a broader claim.

FIELD NOTE 07

Complete the evidence worksheet

For each practice lookup, record: claim being checked; cluster; exact signature; provider or explorer; method and options; observation time; returned slot and commitment; status err; transaction meta.err and fee; and the specific account or token fields that support the conclusion. Mark each item as observed, not returned, unavailable, or not checked. “Not checked” is better than filling a gap with a guess. Do not include a recovery phrase, private key, or learner’s exam response. A reviewer should be able to repeat the same cluster-scoped requests and understand exactly which part of the claim remains unproven.

MAKE THE CONNECTION

A detail worth keeping

The two RPC methods answer different questions. getSignatureStatuses searches a recent cache by default and accepts searchTransactionHistory for an older lookup where provider history is available. getTransaction retrieves a transaction at a chosen commitment or returns null when it cannot supply one there. They may therefore return objects or null independently. Preserve each request and response separately; do not merge a status object into transaction metadata.

Work through an example

When transaction metadata is available, meta.err records execution outcome and meta.fee records the charged fee in lamports. Balance arrays are indexed by the account-key order, and versioned messages may load additional addresses through lookup tables. Token balances identify a token account and mint and include raw amount and decimals. These fields need careful mapping; a display label or a single balance delta may not establish the intended transfer.

Select Devnet in Solana Explorer and choose a recent public transaction with a visible signature. Run the read-only Devnet inspector for that exact signature. Compare its status and transaction results with the explorer, then inspect the state field relevant to the transaction claim. Record the cluster, signature, provider, observation time, slot, commitment, error, fee, and checked account fields. If the endpoint returns 429, an RPC error, or null, classify that response accurately and do not infer transaction absence. No wallet connection, signing, or SOL is needed.

GUIDED PRACTICE · BASIC

Do the work, one step at a time

Use fictional addresses and disposable test data. Do not enter a recovery phrase or private key. Unless a lesson explicitly says “read-only Devnet,” use paper or a local test and do not connect to a public network.

  1. Open Solana Explorer and explicitly select Devnet. Choose a recent public transaction with a visible signature.
  2. Download or open the read-only devnet-inspector.mjs file and run node devnet-inspector.mjs --signature BASE58_SIGNATURE; never enter a private key or recovery phrase.
  3. Record the fixed Devnet cluster, exact signature, observation time, returned status slot, confirmationStatus, and status error.
  4. Inspect the separate transaction result: slot, version, executionError, feeLamports, signers, and top-level instruction count. Compare relevant account or token state before claiming the intended effect.
  5. If a result is null, HTTP 429, or an RPC capability error, label that provider observation precisely and state what additional lookup would resolve it; do not report nonexistence without evidence.

Before you move on, check your reasoning

  • Find one public Devnet signature and record its cluster and source.
  • Run the inspector and separate the status response from transaction metadata.
  • Explain what a null or rate-limit response does and does not establish.

OPEN SELF-CHECK · UNGRADED

Pause and test your reasoning

An explorer shows a Devnet signature, while a Mainnet lookup returns null. What does that Mainnet response prove?

  1. It proves the signature failed on Mainnet.
  2. It proves the explorer is incorrect.
  3. It proves only that this lookup returned no matching result; it does not prove the transaction ran or failed on Mainnet.
Reveal one best answer and its explanation

One best answer: It proves only that this lookup returned no matching result; it does not prove the transaction ran or failed on Mainnet.

Signatures and account history are cluster-scoped. A null RPC result is not a confirmed execution failure, and a Devnet observation cannot establish Mainnet state. Verify the intended cluster, endpoint, signature, and commitment context.

Sources: Clusters and Public RPC Endpoints ↗ · getSignatureStatuses ↗

This practice is not scored, saved, or part of a certificate. Account-based lesson checkpoints and level exams remain separate.

Scored checkpoints and level exams are online and require a free account. They are not included in this pack.

Optional lab files

These files are included with the pack. Follow the safety and toolchain notes in the lesson before running a lab; a Devnet read requires an internet connection.

READ THE SOURCE

Go deeper in the official docs

Reviewed on 2026-09-28. Protocol documentation can change; check the linked page’s current version when you reconnect.