Working with Blocks

Blocks are the unit of progress on OP Mainnet: every transaction, balance change, and event is ordered inside a block, and on this OP Stack rollup (chain ID 10) a new one arrives roughly every two seconds. Reading blocks correctly is therefore the foundation of almost everything you build — tracking the head, confirming transactions, indexing Velodrome or Synthetix activity, or reacting to on-chain events. After this guide you will be able to retrieve OP Mainnet blocks by number or hash over JSON-RPC against https://optimism.therpc.io/YOUR_API_KEY, understand the fields a block carries, monitor new blocks as the sequencer produces them, count confirmations, and reason about when a block is final relative to Ethereum L1.

Core Concepts

• Block structure: an OP Mainnet block carries a number, hash, parentHash, timestamp, gasLimit, gasUsed, baseFeePerGas, and the list of transactions. Because it is an OP Stack chain, blocks also surface fields tied to L1 settlement; note that uncles is always an empty array since OP Mainnet has no ommer blocks.
• Block retrieval: at the JSON-RPC level, eth_blockNumber returns the current head, eth_getBlockByNumber and eth_getBlockByHash return a block, and a boolean flag chooses whether transactions come back as full objects or just hashes — exactly what the web3.eth.getBlock calls above wrap.
• Block monitoring: monitoring means watching for each new block as the sequencer produces it, needed for live indexers, confirmation tracking, and event-driven reactions. With ~2s blocks, a newBlockHeaders subscription is the efficient way to keep up.
• Confirmation counting: confirmations are the number of OP Mainnet blocks built on top of the one holding your transaction (head minus the transaction's block number). More confirmations mean a deeper, harder-to-reorg position — a proxy for safety ahead of true finality.
• Finality on OP Mainnet: as an optimistic rollup, OP Mainnet reaches its strongest finality when a block's batch is settled and finalized on Ethereum L1. Until then, recent blocks are fast but provisional, so treat L1 finalization — not just L2 depth — as the bar for irreversible actions.

Block Retrieval

1// Get latest block number
2const blockNumber = await web3.eth.getBlockNumber();
3 
4// Get block by number
5const block = await web3.eth.getBlock(blockNumber);
6 
7// Get block with full transaction details
8const blockWithTx = await web3.eth.getBlock(blockNumber, true);

Best Practices

• Network delays and timeouts: set explicit timeouts on every call to https://optimism.therpc.io/YOUR_API_KEY and retry with exponential backoff. Treat a missing block at the head as "not produced yet, retry" rather than a hard error, since you may be querying microseconds ahead of the next ~2s block.
• Error handling: wrap block reads in bounded retries, distinguish transient failures from permanent ones, and never advance your processing cursor until a block is successfully fetched and validated — so no OP Mainnet block is silently skipped.
• Accounting for reorgs: when consuming recent, unfinalized blocks, check that each block's parentHash links to the previous one and be ready to roll back if it does not. Wait for L1 finalization before treating high-value state as permanent.
• Caching: cache finalized OP Mainnet blocks permanently by hash since they never change; cache recent unfinalized blocks only briefly because they can still reorg. Caching by hash keeps you correct across reorgs and cuts repeated lookups of immutable data.
• Monitoring gas and block space: watch baseFeePerGas and gasUsed versus gasLimit to gauge congestion and price transactions well. Because OP Mainnet cost also includes an L1 data fee, tracking block-level gas signals helps you choose cheaper windows and avoid underpaying during demand spikes.

See also

• eth_blockNumber - Get the latest block number
• eth_getBlockByNumber - Retrieve block information by number
• Block Confirmations Guide - Understanding transaction finality
• Syncing Strategies - Blockchain synchronization methods