Two successful reads can describe different moments
A blockchain continues to change while your application reads it. Different commitment settings and different node progress can also produce different observations. A lower-latency result is not automatically stale, and a newer processed result is not automatically the state your accounting system should accept.
Capture context with the value
{"jsonrpc":"2.0","id":1,"method":"getAccountInfo","params":["ADDRESS",{"encoding":"base64","commitment":"confirmed","minContextSlot":123456}]}Use a real minimum slot from an earlier observation. The response context tells you the slot of the read. minContextSlot is a lower bound on the node context; it does not request a historical snapshot at precisely that slot.
Use a repeatable comparison
- Keep the cluster, account, encoding and commitment identical.
- Log the context slot beside each result. Compare state only after accounting for actual writes between slots.
- Use getMultipleAccounts when several account values must be read from a single response context.
- If one node cannot satisfy your minimum context, handle that error explicitly rather than quietly falling back to older data.
Choose the consistency your task needs
A trading signal may accept an early observation that is later reconciled. A settlement ledger needs a stronger commitment policy. Define that policy once and pass it explicitly in every relevant call. If a discrepancy remains at equivalent contexts, retain both responses and the affected signatures so support can investigate evidence rather than a description such as "balances sometimes differ".