A hash is not a receipt
An RPC acknowledgement means the endpoint accepted a submission request. A receipt exists after inclusion in a block. A null receipt can therefore be normal immediately after sending, but it can also indicate a wrong chain, a dropped transaction, replacement by another transaction with the same nonce, or unavailable historical data.
Inspect both transaction and receipt
[{"jsonrpc":"2.0","id":"tx","method":"eth_getTransactionByHash","params":["HASH"]},{"jsonrpc":"2.0","id":"receipt","method":"eth_getTransactionReceipt","params":["HASH"]}]Match batch responses by id. A transaction object whose blockHash is null is still pending from that node's perspective. An included receipt contains the block hash and execution status. Store both instead of interpreting any non-null response as success.
Follow the sender and nonce
- Check eth_chainId and compare it with the chain used when signing.
- Look up the account nonce and your own submission records. A later transaction using the same nonce can replace the original transaction.
- If the account nonce advanced, locate the included transaction rather than polling the original hash forever.
- If inclusion was previously verified, check retention and the node's indexing before changing the recorded outcome.
Make polling bounded
Use a bounded polling schedule with backoff, plus a terminal state for unresolved submissions. A receipt status of zero means included execution failed; it is different from no receipt. Record confirmation depth or the relevant finality signal separately because inclusion is only one stage of settlement.