Block Management Best Practices

Code that works against Base in development often fails in production because the conditions change: at ~2s per block the sequencer emits roughly 43,000 blocks a day, transient RPC errors that never appeared in testing become routine at scale, shallow reorgs rewrite the head, and a naive loop over a large block range will exhaust memory long before it finishes. Production-grade block management has to assume all of that. This guide collects the patterns and checklists we recommend for running Base block processing against https://base.therpc.io/YOUR_API_KEY under real load — robust retries and recovery, reorg-safe state handling, memory-efficient batch processing, and the operational monitoring that keeps a pipeline healthy on an OP Stack rollup settling to Ethereum L1.

Error Handling and Recovery

• Retry mechanisms: wrap reads such as eth_getBlockByNumber in a bounded retry with exponential backoff and jitter (1s, 2s, 4s, max 3–5 tries), as shown in the fetchBlockWithRetry helper below. Distinguish a transient error (timeout, 5xx, rate limit) which should retry, from a null result for a not-yet-propagated head block, which should simply wait for the next ~2s Base block instead of retrying the same height.
• Timeouts without data loss: track the last block number you successfully committed and persist it. On a timeout, resume from that checkpoint and backfill any gap, so a dropped request never leaves a hole in your processed range even across restarts.
• Reorg-safe processing: before committing a new block, verify its parentHash equals the hash of your last processed block. If it does not, walk back to the common ancestor, roll back the side effects of the orphaned blocks, and reprocess the canonical chain — never apply a block whose parent you have not seen.
• Fallback nodes: configure a secondary Base endpoint and fail over automatically when the primary's error rate or latency degrades. The fallback gives you continuity during an outage; after switching, re-check the head hash since the backup may lag the primary by a block or two.

Performance Optimization

• Caching: cache finalized historical Base blocks by hash — they never change once settled on Ethereum L1 — and size the cache to your working set (an LRU bounded by memory, keyed by block hash). Give the recent reorg-prone head a short TTL of a few seconds, or do not cache it, so a shallow reorg cannot serve stale data.
• Batch requests: combine many block or receipt lookups into JSON-RPC batches instead of sequential calls. The processBlockRange helper below fetches in batches of 10; batching a wide range cuts round trips and Compute Unit spend against base.therpc.io dramatically compared with one request per block.
• Polling: when polling for new blocks, match Base's ~2s cadence rather than sub-second intervals, add jitter to avoid synchronized bursts, and back off when the head number has not advanced. Better still, drive real-time work from a newHeads subscription and reserve polling for backfill.
• Memory on large ranges: never Promise.all over thousands of blocks at once. Process in fixed-size windows, hand each batch to your processor, and release it before fetching the next so heap usage stays flat regardless of range size — essential given how many blocks Base produces per hour.

Security Considerations

• Confirmations by value: scale your safety margin to the amount at risk. A few Base block confirmations suffice for low-value UI updates; for meaningful value, wait deeper; and for high-value settlement, wait for the transaction's batch to be confirmed on Ethereum L1, which is where an OP Stack rollup gains true finality — sequencer inclusion alone is fast but not final.
• Validate integrity: before processing, confirm the block's number increments by one, its parentHash chains to your last block, and its hash is internally consistent. Reject anything that breaks the chain rather than trusting whatever a node returns.
• Replay exposure: Base's chain ID 8453 with EIP-155 already prevents cross-chain signature replay between Ethereum, Optimism, and Base. Your remaining exposure is application-level re-delivery during a reorg — guard side effects with idempotency keys so reprocessing the same transaction hash never double-applies.
• Anomaly signals: treat a burst of parentHash mismatches, timestamps that move backward, a block number gap or jump, or the sequencer going silent far longer than the normal ~2s interval as a malfunction or attack signal — pause irreversible actions and alert until the head behaves normally again.

Implementation Examples

1import Web3 from 'web3';
2const web3 = new Web3('https://base.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

• Type your block data: use TypeScript interfaces for Base blocks, transactions, and receipts so the compiler catches field mistakes — e.g. that baseFeePerGas exists (Base is EIP-1559) and that hex quantities are parsed as bigint, not silently truncated to JavaScript numbers.
• Comprehensive error handling: every RPC call path should handle timeouts, rate limits, null block results, and malformed responses explicitly, with the retry/backoff and reorg checks described above rather than a bare try/catch that swallows the error.
• Logging and monitoring: instrument each call with method name, block number, chain ID 8453, attempt count, and latency, and emit metrics for error rate, processing lag, and reorg count. Make sure the API key in the base.therpc.io URL never reaches a log line.
• Unit tests: cover the cases that only appear in production — a null head, a timeout that triggers retry, a parentHash mismatch that triggers rollback, and a large-range batch. Mock the Base RPC so these run deterministically in CI.

Production Checklist

• Essential alerts: processing lag behind the Base head, RPC error rate and latency p99, reorg frequency, WebSocket disconnect count, and Compute Unit usage approaching your plan limit — these predict user-visible failures, unlike raw request volume.
• Circuit breakers: when the Base endpoint's error rate crosses a threshold, open a breaker that stops hammering it and either fails over or sheds load, protecting your downstream queues and databases from a flood of retries during a node incident.
• Multiple providers: run at least two Base RPC providers so a single endpoint outage does not take down your service. Route through an abstraction that can switch on health and re-validate the head after a switch.
• Health checks: a periodic probe should confirm the head from eth_blockNumber is advancing, that lag is within bounds, that chain ID is still 8453, and that the fallback endpoint is reachable before you need it.
• Fallback strategy: when the primary https://base.therpc.io/YOUR_API_KEY degrades, automatically promote the secondary, keep serving cached immutable historical blocks, and queue work that must hit the head until a healthy endpoint is available rather than dropping it.

Common Pitfalls to Avoid

• Insufficient error handling: a pipeline with no retries or null checks will silently skip blocks the moment base.therpc.io returns a transient error, leaving permanent gaps in your processed data that are painful to find and backfill later.
• Missing reorg handling: if you commit the head as final on first sight, a shallow Base reorg that replaces those blocks leaves your database holding transactions that no longer exist on the canonical chain — corrupted, inconsistent state that diverges from on-chain reality.
• Poor monitoring: without lag and error-rate alerts you only learn the pipeline fell behind when users report missing data, by which point you may be thousands of ~2s blocks behind and facing a long catch-up.
• Inadequate testing: code that was never tested against timeouts, null heads, or reorgs is fragile by construction — it passes in development and breaks the first time Base behaves the way production always eventually does.

See also

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