EVM WebSocket Gap Recovery: Never Lose Blocks or Logs After Reconnect
Subscriptions are low-latency notifications, not a durable event ledger.
EVM WebSocket Gap Recovery: Never Lose Blocks or Logs After Reconnect
Subscriptions are low-latency notifications, not a durable event ledger.
Model the failure correctly
Checkpoint the last fully committed block number and hash, not merely the last received message.
Collect evidence
On reconnect, compare the checkpoint hash with canonical state and roll back to a common ancestor if necessary.
Build the control path
Capture the new head, backfill bounded eth_getLogs ranges, then drain buffered live notifications.
Handle edge cases
Deduplicate by chain ID, block hash, transaction hash, and log index.
Recovery procedure
Adapt range width on provider limits and use jittered retries without multiplying total load.
Production metrics
Test disconnects, duplicate and out-of-order events, failover, busy blocks, and shallow reorgs.
TierZero can help implement or review this architecture through our relevant engineering service.
Primary reference
See the official technical documentation and pin the exact API behavior used by your deployment.
Building this for production?
We turn this architecture into tested, non-custodial software with monitoring, documentation and deployment support.
Related technical guides
Using debug_traceTransaction to Explain Failed EVM Bot Trades
Receipts show an outcome; traces reveal which nested call, proxy, or token behavior caused it.
Read articleEVM Multicall for Trading Bots: Fast Reads Without Inconsistent State
Sequential latest-state reads can combine reserves, balances, and oracles from different blocks.
Read articleWhen an EVM Bot Actually Needs an Archive Node
Archive access is required for old state, not merely for reading old blocks and receipts.
Read article