Basic · LESSON 07 OF 08
7. Foundations capstone: verify a Solana transfer
By the end, you can trace a sol or token transfer and report what the transaction and resulting account state establish.
Read the workflow
The report first identifies the intended asset and cluster so the evidence is scoped correctly. It then inspects the transaction signature and execution metadata, checks the relevant post-transaction account state, and records what each observation supports. SOL balance changes can include fees or other instructions, so they do not alone prove the transfer amount.
- IDENTIFY ASSET + CLUSTER
- INSPECT SIGNATURE
- CHECK ACCOUNT STATE
- REPORT EVIDENCE
Read a text version: Separate SOL and token transfer evidence
For native SOL, inspect the system-program instruction and the same account keys at matching positions in preBalances and postBalances; report the transaction fee separately. For tokens, compare preTokenBalances and postTokenBalances by accountIndex and mint, then use the raw integer amount and decimals. Both paths begin with the transaction result and its execution error. A separate getAccountInfo response is a later account-state observation with its own context slot, not the transaction's before/after record.
- Read the transaction result
- Match accounts by transaction index
- Compare the correct asset units
- Label the observation and limits
FIELD NOTE 01
Start with the question being asked
A friend says, “I sent you tokens.” Your task is to determine what evidence supports that statement. Ask for the transaction signature and intended cluster; a wallet screenshot, copied ticker, or “sent” toast is not enough. A signature identifies a transaction, but you still need to inspect the network result and the instructions it executed. Keep the sender’s claim, the RPC observation, and the recipient’s resulting account state separate in your notes.
FIELD NOTE 02
Identify the asset and account types
A native SOL transfer changes lamports in system accounts. A token transfer moves units between token accounts for the same mint. The token mint identifies the asset configuration, while a token account holds a balance for a particular mint and owner. A wallet address may have several token accounts. If the sender provides a token address, distinguish a mint account from a token account and confirm the token program and mint instead of relying on a symbol or logo.
FIELD NOTE 03
Choose the right network
Mainnet, Devnet, and Testnet have separate state. A signature found on one cluster does not prove that the same transfer happened on another. Record the cluster and the explorer or RPC endpoint used for the lookup. Devnet SOL is for testing and has no Mainnet value. An address can exist on one cluster and have a different or empty balance on another, so do not omit network context from a screenshot or report.
FIELD NOTE 04
Inspect the transaction result
Use a cluster-specific transaction lookup to inspect the signature, slot, execution error, fee, and instructions when the provider has the record. The official `getTransaction` method returns `null` when it cannot find a transaction at the requested commitment; one null result is limited evidence and does not prove that the transfer failed on every cluster or provider. When transaction metadata is present, `meta.err` reports execution success or failure, and the fee is recorded separately. Transactions execute atomically: if an instruction fails, their state changes revert, but the fee can still be charged. For a successful transaction, inspect the actual source and destination accounts and amounts.
FIELD NOTE 05
Follow the transfer into account state
For SOL, compare the relevant account balances before and after when that evidence is available. A sender’s balance change may combine the transfer with the transaction fee and other instructions, so inspect the fee and all relevant instructions before attributing the full difference to the payment. For tokens, inspect the token accounts’ stored mint, token authority, and raw amount; confirm both accounts use the expected mint. Displayed token balances are formatted from integer base units and mint decimals. Token-account creation or closure can also change lamports. Do not mistake a token account’s SOL balance for its token amount.
FIELD NOTE 06
Distinguish approval from execution
A wallet connection only reveals a public address to the application. A wallet signature approves specific transaction bytes. Submission sends those bytes to a network provider, and confirmation reports an observed status. These steps are not interchangeable. Check the exact destination, asset, amount, cluster, and fee payer before signing. If the wallet rejected the request, there is no user-approved transaction to report as sent. If a signature was submitted but not yet observed, label it pending or unknown until evidence changes.
FIELD NOTE 07
Write a bounded conclusion
State what you observed: the cluster and endpoint, signature, requested commitment, slot, transaction success or error, fee, destination, mint when relevant, and resulting account evidence. Say whether the account snapshot is transaction metadata from that execution or a later state lookup. Then state what remains unknown, such as whether the sender intended this particular address or whether the provider has complete historical data. A transaction proves execution of encoded instructions under the recorded transaction result; it does not establish the real-world identity or honesty of the person behind a key. Good reports show their source and avoid turning missing evidence into certainty.
FIELD NOTE 08
Match RPC fields to the claim
A `getTransaction` result gives the transaction slot plus metadata such as `meta.err`, `meta.fee`, and pre/post balances. A null execution error means the transaction executed successfully; it does not answer every question about what a sender meant. The `preBalances` and `postBalances` arrays refer to the account keys in that transaction response. Pair the same account key across those arrays before interpreting a lamport delta, and inspect instructions because a transaction may contain more than one action. The fee is reported separately in lamports.
Token balance metadata uses `preTokenBalances` and `postTokenBalances`. Each entry can identify an `accountIndex`, mint, token program, owner, raw amount, and decimals. Match the account index and mint on the before and after sides. Use the integer `amount` together with `decimals` for exact arithmetic; a formatted display amount is for reading. A token account created or closed in the transaction may appear on only one side, and missing metadata is not the same thing as a proven zero.
A later `getAccountInfo` lookup is a separate state observation with its own context slot. Label it as the state returned by that request, not as transaction pre/post data. If the parser omits address-lookup-table keys or reports an unsupported transaction version, resolve the decoding problem or use another source before mapping indexes; never guess which wallet a number belongs to.
MAKE THE CONNECTION
A detail worth keeping
Compare a native SOL transfer with an SPL token transfer. Draw the signer, fee payer, source account, destination account, token mint if present, and program that processes the instruction. Explain why the two balance displays cannot be verified in exactly the same way.
Work through an example
Open one confirmed sample from the official transaction documentation or use a disposable Devnet wallet and test SOL. Record the cluster, signature, transaction result, fee, and destination. If you cannot observe an item, mark it unavailable instead of filling it with an assumption.
Write a one-page transfer verification report with one SOL and one token example. For each, record the signature, exact cluster and RPC or explorer source, commitment, execution result, fee, destination, and mint when relevant. Reconcile the SOL fee separately from transfer amounts and inspect the token account mint and token authority. State whether account evidence is transaction pre/post metadata or a later snapshot, and list any unavailable facts.
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.
- Choose a published sample transaction or a disposable Devnet transfer and record the exact cluster.
- Identify whether the transfer concerns SOL or a token, then list its source, destination, fee payer, and mint if applicable.
- Inspect the signature and report execution status, fee, slot, and relevant instructions.
- Read the resulting system or token account state and compare it with the transaction claim.
- Write a conclusion that separates observed facts from sender identity, intent, or unavailable history.
Before you move on, check your reasoning
- Identify the asset, source, destination, and intended cluster.
- Inspect the transaction and verify the resulting account state.
- Report the evidence and the remaining limits separately.
OPEN SELF-CHECK · UNGRADED
Pause and test your reasoning
Practice 1 of 3
A SOL transfer report shows the sender’s balance fell by 0.102 SOL and lists a 0.002 SOL fee. How should you report the transfer amount?
- 0.102 SOL, because all balance decrease is transferred value.
- 0.100 SOL, with the 0.002 SOL network fee recorded separately.
- 0.104 SOL, because the fee is added to the sender’s balance decrease.
Reveal the answer and explanation
One best answer: 0.100 SOL, with the 0.002 SOL network fee recorded separately.
For this synthetic case, reconcile the lamport delta into transfer value plus fee: 0.102 minus 0.002 equals 0.100 SOL. State the signature, cluster, execution result, and evidence source; do not generalize without checking other debits.
Sources: Transaction Fees ↗ · getTransaction ↗
Practice 2 of 3
You find a matching transaction signature on Devnet, but a Mainnet lookup returns null. What can you conclude?
- The transfer also occurred on Mainnet, and this matching Devnet signature proves the Mainnet recipient was paid.
- A matching Devnet signature proves the same recipient and amount were recorded on Mainnet.
- Only the Devnet observation is established.
Reveal the answer and explanation
One best answer: Only the Devnet observation is established.
Signatures and account state are cluster-scoped. Report the cluster with every observation and verify the recipient state on the same intended network. A Devnet lookup cannot establish a Mainnet result.
Sources: getTransaction ↗ · Solana RPC JSON Structures ↗
Practice 3 of 3
Your report has a transaction with no execution error. What additional evidence supports the claimed recipient amount?
- Check recipient account state on the same cluster.
- A wallet label proves receipt.
- The sender’s success label establishes the recipient’s final token amount without inspecting its account or mint.
Reveal the answer and explanation
One best answer: Check recipient account state on the same cluster.
Execution status does not by itself establish every business claim. Trace the correct recipient account, asset, mint, amount, and cluster, then state only what those records show.
Sources: getTransaction ↗ · SPL Token Basics ↗
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 available online through 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-30. Protocol documentation can change; check the linked page’s current version when you reconnect.