Skip to main content
Keep each query at one block, and keep later block choices from going backwards. Set head_policy: local for a chain in your file profile to protect sequential block choices on each running instance, with best-effort recovery from connected peers. This is the behavior labeled Block regression protection: On in Lasso Cloud. Peer sharing is automatic when the runtimes are connected; there is no separate protection switch for it. Local mode needs no publication database. Use global only when you need the stronger fleet-wide contract and have configured its journal and serving fleet. Choose a block once with eth_getBlockByNumber("latest", false) and pass its hash to every state read in your query. Your existing RPC endpoint and standard Ethereum methods stay the same. This works for queries that combine proxy resolution, storage and code reads, Multicall, and dependent eth_call rounds. Follow the read at one block guide to integrate it.

​
What the setting guarantees

After a successful block choice returns height N, a later block choice returns N or higher, or an error. Returning the same height is allowed. The scope depends on the selected mode. All API keys using the same profile and chain share its floor within that scope. Different profiles and chains remain independent. The guarantee applies when a later request starts after the earlier response completes; overlapping requests can finish out of height order. Local choices use providers and retain an in-memory floor. Peer hints influence provider preference without requiring a database lookup or peer acknowledgment. They do not raise the receiving node’s mandatory floor. A valid response may therefore be below a peer hint. Recovery has no guaranteed maximum time or block gap; disconnected peers, lost processes and the fleet’s total profile/chain inventory affect it. Losing every copy of local state loses that history. The setting does not group requests into a query. Your application carries the chosen hash through discovery, independent calls, and dependent rounds. A JSON-RPC batch alone does not select a shared block. safe, finalized, pending, log ranges, and subscriptions retain their usual semantics.

​
One query, one block identity

For state reads, use the standard EIP-1898 selector:
A number identifies a height; a hash identifies the particular block at that height. During a reorg, the same number can refer to a different block. If you start with a number, resolve it to a hash once, before the first state read. Use providers that support the method, hash selector and required state history. Lasso keeps the hash during failover and returns an error if the read cannot be completed. Provider capability evidence guides routing; it does not certify that every backend behind an endpoint can execute the request. Your query can therefore finish at block 100 while a newer query reads block 101.

​
Freshness and provider lag

A local choice validates a provider response against the floor captured when that request began. A lower response is rejected; Lasso can try another eligible provider within the request’s deadline and retry budget. Local mode does not cache block responses to hide provider failures. If a provider regresses and all fallbacks are unavailable or quota-limited, the choice fails explicitly. Global mode retains a published block. It can return 101 again after publishing 101 even when a provider later reports 100. During a publication change, a choice can wait up to one second within its request deadline before failing. Both modes reject protected block choices older than the greater of 60 seconds or four configured block intervals, measured from the block timestamp. Repeating a block does not renew its age. This bounds staleness; it does not promise the newest block on the network. Executing state reads still requires a provider with the selected state. Hash-pinned reads continue without waiting for block publication. A provider URL can sit in front of several nodes with different heads. Lasso keeps the hash on every attempt; a lagging node must serve that state or return an error. A successful head probe alone does not establish state availability. One provider is enough to enable the policy. It provides no provider failover or independent verification; reads fail if that provider cannot serve the chosen state.

​
Reorgs and failures

With requireCanonical: true, a provider must reject a block it knows is no longer canonical. Lasso surfaces that conflict; it does not silently replace the query’s hash. Discard the incomplete query and retry the whole operation within your deadline if a fresh result is still useful. Global publication can report attributed replacements at the previous selected height as anchor_hash_changed. Local mode rejects a different hash at its captured floor height. Neither mechanism detects every reorg, and missing state alone is not evidence of one. The floor does not reset downward within its protected scope, so a reorg can temporarily prevent new block choices. Canonicality reflects provider observations at the time of a read. A block can be reorganized later. Lasso does not cryptographically verify arbitrary eth_call results: a provider that silently ignores the selector can return incorrect data without revealing that in its response. Provider head checks and routing evidence do not prove execution correctness or finality.

​
Return the block and routing evidence

Add ?include_meta=headers to collect Lasso’s request ID and routing metadata without changing the JSON-RPC result. Return the chosen number, hash, and collected evidence alongside your application’s query result. The guide shows what to retain. Local routing evidence includes the application generation, captured minimum_height, best-effort recovery_height, and recovery_gap_blocks. A missing recovered height is represented by null; a nonzero gap is allowed. Compare sequential choices within the same generation to assess the local invariant. Node changes and new generations have the softer recovery contract. The local floor survives a recovery-worker restart, but not loss of its owning application. Disabling protection does not cover calls made while it is off. Global floors survive service restarts through the journal; changing away from Global first completes coordinated shutdown. Choices can keep failing until that transition finishes, including when a failed member still needs to be fenced.