Block Management Best Practices

Code that reads a single OP Mainnet block in a local script is trivial; code that keeps up with a ~2s-block optimistic rollup at chain ID 10, around the clock, without dropping or double-counting a block, is not. Production traffic exposes everything development hides: transient endpoint errors, dropped WebSocket connections, reorgs of unfinalized blocks before they settle to Ethereum L1, and memory blowups when backfilling long ranges. This guide delivers the concrete patterns and copy-ready checklists that make OP Mainnet block processing survive that environment — robust retries, reorg detection, memory-bounded batch processing, and the monitoring you need to know it is still working against https://optimism.therpc.io/YOUR_API_KEY.

Error Handling and Recovery

• Retry mechanism: wrap every OP Mainnet block read in bounded retries with exponential backoff (e.g. 1s, 2s, 4s) and jitter. Treat "block not found" for a height at or above the current head as "not produced yet, retry" rather than a hard failure, since the sequencer may be moments from minting it.
• Network timeouts: set explicit per-request timeouts and persist a last-processed-block cursor. On a timeout, retry the same height — do not advance the cursor — so no OP Mainnet block is silently skipped.
• Reorg handling: compare each new block's parentHash against the hash you stored for the previous height. On mismatch, walk back to the common ancestor, roll back any state derived from the orphaned blocks, and reprocess the new canonical chain. Key state by block hash so this is a replace, not a duplicate.
• Fallback nodes: configure a secondary OP Mainnet endpoint and switch to it on repeated primary errors or a stalled head. Since all nodes serve chain ID 10, the fallback returns identical canonical state, and you can cross-check a disputed block hash between the two before committing.

Performance Optimization

• What to cache: cache finalized OP Mainnet blocks (those below the L1-finalized head) permanently by hash since they never change; cache recent unfinalized blocks with a short TTL because they can still reorg. Size the cache to your working set — an indexer scanning recent Velodrome or Synthetix activity rarely needs more than a few thousand recent blocks hot.
• Batch requests: combine many eth_getBlockByNumber calls into JSON-RPC batch requests (10–20 per call, as the example's processBlockRange does) to cut round trips. On a 2s-block chain this dramatically reduces the time and request count to backfill a range.
• Efficient polling: poll near the 2s block interval with jitter, or better, drive live processing from a newBlockHeaders subscription and reserve polling for gap recovery. Backing off when the head has not advanced avoids paying for requests that return nothing new.
• Memory management: process large ranges in fixed-size batches and release each batch before fetching the next, rather than loading thousands of blocks into memory at once. Stream results to your sink (database, queue) so memory stays flat regardless of range length.

Security Considerations

• Confirmation depth by value: scale required confirmations to transaction value. A few OP Mainnet blocks suffice for low-value or UI updates, more for meaningful sums, and for high-value settlement wait until the block is finalized on Ethereum L1 — that L1 finalization, not local block depth, is the strong guarantee on an optimistic rollup.
• Integrity validation: verify each block's number is contiguous and its parentHash links to the prior block before processing. Reject or re-fetch any block that fails this check instead of trusting the response.
• Replay protection: OP Mainnet signs with chain ID 10 (0xa) under EIP-155, so transactions cannot be replayed onto Ethereum L1 or sibling Superchain networks. Pin chain ID 10 when signing and deduplicate by transaction hash so a post-reorg reappearance is handled once.
• Anomaly signals: monitor for timestamps that move backward, the head stalling far past the ~2s cadence, conflicting hashes at one height, or a sudden parent-hash break — any of these signals a node malfunction or manipulation and should pause irreversible actions.

Implementation Examples

1import Web3 from 'web3';
2const web3 = new Web3('https://optimism.therpc.io/YOUR_API_KEY');
3 
4// Robust block fetching with retries
5const fetchBlockWithRetry = async (blockNumber, maxRetries = 3) => {
6  for (let i = 0; i < maxRetries; i++) {
7    try {
8      const block = await web3.eth.getBlock(blockNumber);
9      if (block) return block;
10      throw new Error('Block not found');
11    } catch (error) {
12      if (i === maxRetries - 1) throw error;
13      await new Promise((resolve) => setTimeout(resolve, 1000 * (i + 1)));
14    }
15  }
16};
17 
18// Efficient block monitoring
19const createBlockMonitor = (callback, errorHandler) => {
20  let lastProcessedBlock = 0;
21 
22  return web3.eth
23    .subscribe('newBlockHeaders')
24    .on('data', async (blockHeader) => {
25      try {
26        if (blockHeader.number <= lastProcessedBlock) return;
27        await callback(blockHeader);
28        lastProcessedBlock = blockHeader.number;
29      } catch (error) {
30        errorHandler(error);
31      }
32    })
33    .on('error', errorHandler);
34};
35 
36// Memory-efficient block processing
37const processBlockRange = async (startBlock, endBlock, processor) => {
38  const batchSize = 10;
39  for (let i = startBlock; i <= endBlock; i += batchSize) {
40    const batch = await Promise.all(
41      Array.from(
42        { length: Math.min(batchSize, endBlock - i + 1) },
43        (_, index) => fetchBlockWithRetry(i + index)
44      )
45    );
46    await processor(batch);
47  }
48};
49 
50// Handle block reorgs
51const monitorReorgs = async (callback) => {
52  let lastBlock = await web3.eth.getBlock('latest');
53 
54  return web3.eth.subscribe('newBlockHeaders').on('data', async (block) => {
55    if (block.parentHash !== lastBlock.hash) {
56      await callback({
57        oldBlock: lastBlock,
58        newBlock: block,
59      });
60    }
61    lastBlock = block;
62  });
63};

Development Checklist

• TypeScript types: type your OP Mainnet block, header, and transaction shapes (including the OP Stack fields such as the L1 fee components) so the compiler catches a missing parentHash or a misread baseFeePerGas before it reaches production.
• Comprehensive error handling: ensure every RPC call has a retry path, every retry has a ceiling, and every unrecoverable error is surfaced — not swallowed. Cover the "block not yet produced" case distinctly from genuine failures.
• Logging and monitoring: instrument structured logs carrying block number, hash, and method, plus metrics for processing lag and error rate against https://optimism.therpc.io/YOUR_API_KEY, before shipping.
• Unit tests: cover the contiguity check, the reorg/common-ancestor walk, retry-and-backoff behavior, and idempotency of side effects using fixtures of real chain ID 10 block sequences, including a crafted reorg fixture.

Production Checklist

• Monitoring and alerting: alert on processing lag (head minus last processed block), RPC error rate, reorg frequency, and a stalled head that exceeds the expected ~2s cadence. These four signals catch nearly every OP Mainnet pipeline incident early.
• Circuit breakers: when the OP Mainnet endpoint returns sustained errors, trip a breaker that pauses downstream writes instead of forwarding garbage — this protects your database and consumers from a node having a bad moment.
• Multiple providers: run at least two OP Mainnet endpoints. A single provider is a single point of failure; with two serving identical chain ID 10 state you can fail over instantly and even quorum-check disputed hashes.
• Health checks: regularly verify the node reports chain ID 10, the head is advancing, and eth_syncing shows it caught up — a pipeline reading a stale or wrong-network node is worse than one that is down.
• Fallback strategy: when the primary degrades, automatically route reads to the fallback, keep buffering live headers so no block is lost during the switch, and backfill any gap once the primary recovers.

Common Pitfalls to Avoid

• Insufficient error handling: without bounded retries and a persisted cursor, a single transient error on https://optimism.therpc.io/YOUR_API_KEY skips an OP Mainnet block, leaving a permanent gap in your data that is painful to detect and backfill later.
• Missing reorg handling: acting on an unfinalized block and never reconciling when it is reorged corrupts state — you record effects from blocks that no longer exist on the canonical chain ID 10 history, and balances or indexes drift out of sync.
• Poor monitoring: with no lag or error metrics, an integration can fall hours behind the OP Mainnet head or silently stall, and you only learn about it from users instead of an alert.
• Inadequate testing: pipelines that are never tested against reorg fixtures or simulated endpoint failures look fine until the first real reorg or outage, then fail in exactly the path that was never exercised.

See also

• Working with Blocks - Fundamental concepts of block handling
• Chain Reorganization Guide - Handling chain reorgs
• Block Confirmations Guide - Understanding transaction finality