Keeping data consistent
Two healthy nodes can see a new block at different times. If each interprets latest independently, switching providers can make an application's state reads move between blocks. Direct resolves supported reads against a shared reference block, so provider choice does not determine which state answers the request.
A shared view of latest
The reference identifies a block by both height and hash. For supported reads, the gateway resolves latest to that block before choosing a provider. If the reference is N−1, a node at N and a node at N−1 both receive a request for the same block, rather than interpreting latest independently.
eth_blockNumber returns the reference height locally. State reads use the reference hash through EIP-1898, with canonical-chain checking. A block lookup such as eth_getBlockByNumber("latest", …) can be forwarded as a lookup by the reference hash. Omitted block parameters that default to latest follow the same policy.
A request retains its selected block through retries and optional response verification, so all participating providers are asked about the same state. Later requests use the reference available when they begin. Applications that need several calls to share one snapshot supply an explicit block hash; the reference can advance between calls.
Explicit block numbers and hashes keep their meaning. pending, safe, and finalized are distinct requests, not aliases for Direct's reference head. They are outside this guarantee.
Additional block-based methods follow the same selected reference. Number-based transaction counts, transaction-position lookups, and applicable uncle queries resolve latest before execution. Where the API has an equivalent hash-based lookup, the gateway uses the selected hash. Optional block-receipt and access-list methods must preserve supported block selectors as part of capability qualification; EIP-1898 objects are not blindly passed to methods that do not accept them.
For eth_feeHistory, the gateway resolves a latest endpoint before requesting the bounded history. This aligns its target range without changing the API's allowance for a shorter returned history. Fee estimates without a block selector and pending observations remain outside the snapshot guarantee.
Establishing the reference
Direct-operated monitors compare observations from multiple chain nodes, including block heights, hashes, and ancestry. Agreement identifies a candidate reference; freshness checks keep stale observations from determining the current view. Agreement among RPC nodes is an operational observation, not a replacement for the blockchain's consensus or finality rules.
Consumers receive authenticated reference updates from Direct-operated infrastructure. Each update carries an expiry and enough information to identify its network and block unambiguously. Forwarding a pinned request remains a direct operation between consumer and provider; monitors do not carry application traffic.
The reference hash must reach request execution, not just provider selection. Replacing latest with a number aligns heights but still allows different answers from competing branches at that height.
Keeping providers eligible
A provider must be able to serve the selected block on the expected chain, with the state and methods the request requires. Being ahead of the reference is acceptable. Being behind it, or following a conflicting branch, makes the provider unsuitable for that request.
Consumers exclude providers that cannot serve the reference and choose another eligible connection. This immediate routing decision is separate from declaring an offering unhealthy: a brief propagation delay should not be treated like a sustained synchronization failure.
Direct's ongoing checks establish whether the offering still meets the provider requirements. Failed baseline checks remove it from selection; recovery must be verified before it returns. Optional capabilities are checked separately.
What can be pinned
| Request type | Handling |
|---|---|
| State read with a block selector | Resolve latest to the reference hash and request canonical-chain checking |
| Block lookup | Use the selected block hash where a corresponding hash-based method exists |
| Log range | Resolve moving endpoints once and preserve that range through splitting and retries |
| Transaction submission | Send to an eligible provider; submission is not a snapshot read |
| Block-independent read, such as chain ID | Any provider qualified for the network |
| Fee estimate or transaction visibility | Return the provider's observation; identical answers across providers are not guaranteed |
A numeric log range does not identify every block hash within it. Splitting therefore requires checking that the assembled result belongs to a consistent chain. If a reorganization invalidates that view, retry within the execution deadline or return an error; never return a successful, partially assembled result. See Log-query limits.
Where the guarantee ends
Hash pinning identifies the state being queried; it does not make an unfinalized block irreversible. Canonical-chain checking can reject a block that a provider no longer considers canonical, but cannot prevent a later reorganization.
The reference also does not freeze pending transactions or fee estimates. A receipt may become visible at one provider before another, or refer to a block newer than the reference. Those observations retain their method-specific semantics rather than pretending to be reads of a fixed snapshot.
WebSocket subscriptions remain tied to a live provider connection and do not inherit the snapshot guarantee.