Null is an incomplete observation
getTransaction returns a confirmed transaction or null when the requested transaction is unavailable at the selected commitment. Null alone does not describe the outcome of a transaction. Keep the submission signature, recent blockhash and last valid block height so later checks have useful context.
Make the lookup explicit
{"jsonrpc":"2.0","id":1,"method":"getTransaction","params":["SIGNATURE",{"commitment":"confirmed","encoding":"json","maxSupportedTransactionVersion":0}]}Use confirmed or finalized. This method does not provide a processed-level transaction lookup. The version option handles version-0 transactions; it is not a way to recover missing history.
Check the right evidence
- Confirm the signature belongs to the same cluster as the endpoint.
- For a recent submission, inspect getSignatureStatuses. Use searchTransactionHistory when appropriate, understanding that the node's retained history still limits the search.
- If a previously recorded transaction slot predates getFirstAvailableBlock, the node no longer has that block available through its normal block history.
- If the slot is within range but the lookup remains null, preserve the request and signature for support. Index configuration and ingestion can require a separate diagnosis.
Keep outcome and availability separate
A confirmed transaction with an execution error did land and can still have paid a network fee. A transaction that expired before inclusion has a different lifecycle. A historical record that is no longer retrievable is a data-availability issue. Your database should keep these states separate so a temporary RPC miss cannot reverse a previously verified payment or mark it successful.