Best Practices

OP Mainnet is an OP Stack optimistic rollup (chain ID 10, 0xa) that settles to Ethereum L1 and produces a new block roughly every two seconds through a single sequencer. That fast, steady cadence means a naive integration can fall behind, miss blocks, or act on data that L1 finalization later changes — so a systematic approach to block handling pays off directly in uptime and correctness. This guide gathers the patterns that keep an OP Mainnet integration dependable across four areas: reliability (never dropping or double-processing a block), performance (keeping up with sub-second-margin polling against https://optimism.therpc.io/YOUR_API_KEY), security (validating data before trusting it), and maintainability (code that the next engineer can extend without fear).

Core Principles

• Reliability: every OP Mainnet block between your last cursor and the chain head is processed exactly once. With ~2s blocks, track the last processed block number and reconcile gaps after any disconnect rather than assuming the next header you receive is contiguous.
• Performance: favor batched eth_getBlock calls, in-memory caching of immutable block data, and WebSocket newBlockHeaders subscriptions over tight polling. Block-heavy workloads (indexers, fee trackers for Velodrome or Synthetix activity) live or die on request efficiency against your endpoint.
• Security: treat sequencer-supplied data as untrusted until validated — check that returned block numbers, parent hashes, and timestamps form a consistent chain before acting, and never compute economic outcomes from an unconfirmed head.
• Maintainability: isolate RPC access behind a thin client layer, type your block shapes, and keep reorg/recovery logic in one place so OP Stack upgrades (Bedrock and beyond) need changes in a single module.
• Error handling: assume any call to https://optimism.therpc.io/YOUR_API_KEY can fail transiently. Wrap reads in bounded retries with exponential backoff, distinguish "block not yet produced" (retry) from "permanent error" (surface it), and fail loud rather than silently skipping data.

Implementation Guidelines

1// Reliable block fetching with retry mechanism
2const fetchBlockWithRetry = async (blockNumber, maxRetries = 3) => {
3  let retries = 0;
4  while (retries < maxRetries) {
5    try {
6      const block = await web3.eth.getBlock(blockNumber);
7      if (block) return block;
8      throw new Error('Block not found');
9    } catch (error) {
10      retries++;
11      if (retries === maxRetries) throw error;
12      await new Promise((resolve) => setTimeout(resolve, 1000 * retries));
13    }
14  }
15};
16 
17// Safe event handling with error boundaries
18const createBlockListener = (callback) => {
19  return web3.eth
20    .subscribe('newBlockHeaders')
21    .on('data', async (blockHeader) => {
22      try {
23        await callback(blockHeader);
24      } catch (error) {
25        console.error('Block processing error:', error);
26        // Implement your error handling strategy
27      }
28    })
29    .on('error', (error) => {
30      console.error('Subscription error:', error);
31      // Implement your reconnection strategy
32    });
33};

Error Handling

• Retries and backoff: retry idempotent reads (eth_getBlockByNumber, eth_getBlockByHash) up to three times with exponential backoff starting near the ~2s block interval (1s, 2s, 4s) plus a little jitter, so transient sequencer or network hiccups self-heal without hammering the endpoint.
• Network interruptions: on a dropped WebSocket or timeout, persist the last processed OP Mainnet block number, reconnect, then backfill every block from that cursor to the current head before resuming live processing — never trust that the stream resumed exactly where it stopped.
• Logging: log the block number, block hash, method, and error class for every failed call to https://optimism.therpc.io/YOUR_API_KEY, and emit a counter you can alert on. In production, structured logs that let you replay a specific block range are worth far more than free-text messages.
• Fallback providers: keep a secondary OP Mainnet endpoint and fail over when the primary returns repeated errors or stalls. Because all OP Mainnet nodes serve the same chain ID 10 state, you can cross-check a suspicious block hash against the fallback before acting on it.

Performance Optimization

• Caching: blocks below the L1-finalized head on OP Mainnet are immutable, so cache them indefinitely by hash; cache recent unfinalized blocks with a short TTL (tens of seconds) since they can still be reorged before L1 finalization. Cache by block hash, not number, to stay correct across reorgs.
• Batching: when backfilling a range, send eth_getBlockByNumber calls in JSON-RPC batches (10–20 per request) instead of one round trip per block. On a ~2s-block chain this is the difference between keeping pace and falling permanently behind during a backfill.
• Polling: if you must poll, set the interval near the 2s block time (e.g. 2s), add small random jitter to avoid thundering-herd alignment, and back off when the head has not advanced rather than spinning.
• WebSocket subscriptions: subscribe to newBlockHeaders for real-time updates. A subscription pushes each new OP Mainnet header the instant the sequencer produces it — lower latency and far fewer wasted requests than polling for a chain that mints a block every couple of seconds.

Security Considerations

• Integrity validation: before acting on a block, confirm its parentHash matches the hash of the block you previously processed and that its number is exactly one greater. A broken chain link means a reorg or a bad node response, not new data.
• Reorg safety: never commit irreversible state from an unfinalized OP Mainnet block. Buffer effects until the block is sufficiently deep (or L1-finalized for high value), and key your storage by block hash so a reorg replaces rather than duplicates entries.
• Replay protection: OP Mainnet uses chain ID 10 (0xa) in EIP-155 signatures, so a signed transaction cannot be replayed onto Ethereum L1 or another OP Stack chain. Always pin chain ID 10 when signing, and deduplicate by transaction hash so a transaction reappearing after a reorg is processed only once.
• Anomaly monitoring: alert on signals that suggest a node problem or attack — block timestamps moving backward, the head stalling well beyond the ~2s cadence, a parent-hash mismatch, or two different hashes reported for the same height.

Maintenance

• Health checks: periodically call eth_blockNumber and confirm the head advances at roughly the expected ~2s rate, and verify the node reports chain ID 10 so you never accidentally read a fork or wrong network.
• Monitoring and alerting: track processing lag (head block minus last processed block), RPC error rate against https://optimism.therpc.io/YOUR_API_KEY, reorg frequency, and end-to-end block-handling latency. Lag growing over time is the earliest actionable warning that you are falling behind.
• Code reviews: for any change to block-handling logic, require reviewers to check retry and backoff bounds, reorg/parent-hash handling, idempotency of side effects, and that cursor state is persisted — these are the failure modes that only surface under production load on a fast chain.

See also

• Syncing Strategies Guide - Optimal synchronization methods
• Chain Reorganization Guide - Handling chain restructuring