Different blockhash across RPC endpoints and stale getAccountInfo responses: why nodes disagree

Two Solana RPC endpoints returning different blockhashes are not malfunctioning: each node answers from its own replay position, and there is no single RPC view of the chain. A stale getAccountInfo response comes from the same place, a node that is behind the tip but still answering queries from the state it has. The disagreement you observe is the spread of replay positions across the nodes you happen to be querying, made visible.

Common causes

• A load balancer is rotating you across a pool whose members sit at different slots, so consecutive reads sample different chain states.
• One node is lagging because expensive read traffic, large account scans in particular, is starving its replay of CPU and disk.
• Your requests mix commitment levels: processed reflects the node's newest unconfirmed view, finalized trails the tip by design, and comparing across them across nodes guarantees disagreement.
• A node has fallen far enough behind that its answers are minutes old, but it has not crossed any health threshold that would eject it from the pool.

System-level mechanism

Every RPC node is an independent replica racing to replay the same ledger, and its answers are only as fresh as its replay position. Replay shares the host with query serving, so heavy queries directly push a node backwards relative to its peers: the busier a node, the staler its answers, while it continues to answer. Health checks that test liveness rather than slot position keep such nodes in rotation. The reliable diagnostic is to read the context slot returned alongside RPC responses, which timestamps every answer with the replay position that produced it; disagreement between endpoints then becomes measurable instead of mysterious.

What this indicates

Occasional small spreads across endpoints are normal replication lag. Persistent staleness from one endpoint indicates that node is resource-starved or under heavy shared load, and using it for blockhash acquisition will produce transactions that expire early. Pinning a session to one healthy node, and checking its slot, removes the ambiguity.

Related issues

Transactions expiring with "Blockhash not found" after signing against a stale node; getProgramAccounts timeouts on the same endpoints, which is the load that causes the lag; reads degrading gracefully while writes fail.

Deep references

• Expensive work before authentication covers how unpriced read work pushes an RPC node behind the tip.
• We're securing validators at the wrong layer frames RPC-layer state divergence within the wider infrastructure failure class.
• NR-2026-001, Agave RPC architectural findings documents the saturation patterns that produce lagging-but-answering nodes.