Consistency and finality

A balance, price, and transaction count read at different blocks may not describe the same state. Pin related calls to one block so your application compares like with like. Choose finality based on whether the result can tolerate a later chain reorganization.

Block references

Repeatable read pattern

When multiple calls must observe the same state:

1. Select a block with eth_blockNumber, or with eth_getBlockByNumber and a tag such as safe or finalized.
2. Store the block number or block hash.
3. Pass that same reference to follow-up eth_call, eth_getLogs, eth_getBalance, eth_getStorageAt, or eth_getCode requests.

For example, these two reads can describe different blocks, because each latest resolves when its request arrives:

[
  { "method": "eth_getBalance", "params": ["0x...", "latest"] },
  { "method": "eth_call", "params": [{ "to": "0x...", "data": "0x..." }, "latest"] }
]

These two reads describe the same block, 18000000:

[
  { "method": "eth_getBalance", "params": ["0x...", "0x112a880"] },
  { "method": "eth_call", "params": [{ "to": "0x...", "data": "0x..." }, "0x112a880"] }
]

Sending the reads in one batch does not pin them; only the explicit block reference does. Read contract state shows the pattern in client code.

Choose finality

A pinned block can still be reorganized if it is newer than finalized. Pick the reference by what a reorganization would cost you:

• Use latest for displays that refresh and can show a brief inconsistency.
• Use safe for user-visible reads that should rarely change.
• Use finalized for settlement, accounting, or any irreversible step.

When you store data from recent blocks, keep enough block identity to undo it. Retries and reorgs shows how.

Next steps