Why Solana RPC results differ between calls
Last updated:
At a glance
| Property | Value |
|---|---|
| processed | Newest view; can still be rolled back |
| confirmed | Voted on by more than two-thirds of active stake |
| finalized | Maximum lockout; the node's typical default when commitment is omitted |
| How to order two answers | context.slot — the slot at which the node evaluated the request |
| How to prevent going backwards | minContextSlot — the minimum slot the request can be evaluated at |
What you see
getBalance or getAccountInfo for the same account returns one value, and a moment later an older value, or a value that another tool does not show yet. A transaction you just saw reflected in an account can briefly seem to vanish. No call returns an error.
Why this happens
Solana RPC answers are always evaluated at a slot and a commitment level. "processed" is the node's most recent processed block — the newest view, which can still be rolled back. "confirmed" is a block voted on by a supermajority of stake (more than two-thirds of active stake). "finalized" is a block with maximum lockout. When a request omits commitment, the node uses its default, typically finalized, so a call with no commitment and a call with "processed" look at different points of the same chain. On top of that, requests to a pool of RPC nodes can be answered by different nodes that are a few slots apart; each answer is correct for its own slot, so reading them in sequence can make state appear to move backwards. Every response that is wrapped in an RpcResponse carries context.slot, the slot at which the node evaluated the request, which is the only reliable way to order two answers.
What to do
- Pass the same commitment explicitly on every related call instead of mixing explicit levels with the node default.
- Record context.slot from each response and compare slots, not wall-clock times, when deciding which answer is newer.
- Send minContextSlot set to the highest slot you have already seen. It is the minimum slot the request can be evaluated at, so a node that has not reached that slot cannot answer from older state; retry the request instead.
- Show processed data as tentative in a UI and confirm important decisions (credits, withdrawals) at confirmed or finalized.
- Rule out the wrong cluster: mainnet-beta, devnet and testnet have independent state for the same address.
When this is not our problem
Slot and commitment are part of how Solana RPC works on every node; a pool of nodes on any provider, Triport included, can answer two calls from two slightly different slots. context.slot and minContextSlot are the protocol's own tools for making reads monotonic, and they work the same way everywhere.
FAQ
- Why did my Solana balance go back to an older value?
- Either the two reads used different commitment levels, or they were answered by nodes at different slots. Compare context.slot on both responses, and send minContextSlot so a node behind your last-seen slot cannot answer.
- Which commitment level should I use?
- processed for the newest possible view that may still change, confirmed for most application reads, and finalized when a rollback would be costly. Use the same level for all reads that must agree.