Working with Blocks

Blocks are the unit of state progression on Arbitrum One, and almost every read you perform against https://arbitrum.therpc.io/YOUR_API_KEY — balances, receipts, event logs, gas data — is anchored to a specific block on chain ID 42161. Because Arbitrum One is an Optimistic Rollup running the Nitro stack, its sequencer assembles blocks and returns sub-second soft confirmations, so getting block handling right is what lets your application read consistent state, order events deterministically, and reason about how far a transaction is from L1-backed finality. After working through this guide you will be able to fetch the latest block height, retrieve any block by number or hash with or without full transaction bodies, watch new blocks as the sequencer produces them, count confirmations, and judge when a result is safe to treat as final.

Core Concepts

Block structure: An Arbitrum One block carries a number, hash, parentHash, timestamp, gasLimit, gasUsed, baseFeePerGas, and an array of transactions. Note two Nitro-specific realities: the uncles array is always empty (a single sequencer means no competing forks), and gasUsed reflects L2 execution while the L1 calldata-posting cost is folded into the effective fee rather than a separate header field.
Block retrieval: At the JSON-RPC level you read blocks with eth_blockNumber (latest height) and eth_getBlockByNumber / eth_getBlockByHash. Pass the boolean true flag to receive full transaction objects inline; pass false to get only transaction hashes and a lighter payload. Tags like latest, safe, and finalized are accepted in place of a numeric height.
Block monitoring: Monitoring means reacting to each new block as the sequencer publishes it — needed for indexers, mempool-free transaction tracking, and live dashboards. Because Arbitrum One block intervals are sub-second and driven by demand rather than a fixed slot, prefer a newBlockHeaders WebSocket subscription over tight polling.
Confirmation counting: A confirmation count is simply currentBlock - txBlockNumber. On Arbitrum One a high confirmation count gives strong protection against sequencer-level re-ordering, but true settlement comes from L1 — so confirmation depth and L1 finality are two different guarantees you track in parallel.
Block finality: Soft confirmation from the sequencer is near-instant, but a block is only economically final once its batch is posted to Ethereum L1 and survives the rollup's challenge window. For high-value flows, treat the finalized tag (which tracks L1-backed state) as your source of truth rather than the freshest latest block.

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: Wrap each call to https://arbitrum.therpc.io/YOUR_API_KEY with a request timeout and retry on transient failures. Because the sequencer produces blocks sub-second, a height you read can advance between two calls — re-fetch rather than assume latest is stable across a multi-step operation.
Error handling: Handle the common null case where eth_getBlockByNumber returns null for a height the node has not yet imported, distinguish that from RPC transport errors, and back off exponentially on rate-limit responses instead of hammering the endpoint.
Reorg awareness: Even though a single sequencer makes deep reorgs rare on Arbitrum One, the canonical chain can still be revised before L1 settlement. Compare parentHash linkage when processing consecutive blocks and only treat data behind the finalized tag as immune to revision.
Caching: Finalized blocks are immutable, so cache them aggressively by hash; never cache an unfinalized latest block as permanent truth. Caching historical block bodies and receipts cuts repeated RPC load for indexers and analytics.
Gas and block space: Track baseFeePerGas and gasUsed per block — Arbitrum One fees combine L2 execution with the cost of posting calldata to Ethereum L1, so monitoring both signals lets you time submissions and size gas limits sensibly in ETH.

Block structure: An Arbitrum One block carries a number, hash, parentHash, timestamp, gasLimit, gasUsed, baseFeePerGas, and an array of transactions. Note two Nitro-specific realities: the uncles array is always empty (a single sequencer means no competing forks), and gasUsed reflects L2 execution while the L1 calldata-posting cost is folded into the effective fee rather than a separate header field.

Block retrieval: At the JSON-RPC level you read blocks with eth_blockNumber (latest height) and eth_getBlockByNumber / eth_getBlockByHash. Pass the boolean true flag to receive full transaction objects inline; pass false to get only transaction hashes and a lighter payload. Tags like latest, safe, and finalized are accepted in place of a numeric height.

Block monitoring: Monitoring means reacting to each new block as the sequencer publishes it — needed for indexers, mempool-free transaction tracking, and live dashboards. Because Arbitrum One block intervals are sub-second and driven by demand rather than a fixed slot, prefer a newBlockHeaders WebSocket subscription over tight polling.

Confirmation counting: A confirmation count is simply currentBlock - txBlockNumber. On Arbitrum One a high confirmation count gives strong protection against sequencer-level re-ordering, but true settlement comes from L1 — so confirmation depth and L1 finality are two different guarantees you track in parallel.

Block finality: Soft confirmation from the sequencer is near-instant, but a block is only economically final once its batch is posted to Ethereum L1 and survives the rollup's challenge window. For high-value flows, treat the finalized tag (which tracks L1-backed state) as your source of truth rather than the freshest latest block.

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: Wrap each call to https://arbitrum.therpc.io/YOUR_API_KEY with a request timeout and retry on transient failures. Because the sequencer produces blocks sub-second, a height you read can advance between two calls — re-fetch rather than assume latest is stable across a multi-step operation.

Error handling: Handle the common null case where eth_getBlockByNumber returns null for a height the node has not yet imported, distinguish that from RPC transport errors, and back off exponentially on rate-limit responses instead of hammering the endpoint.

Reorg awareness: Even though a single sequencer makes deep reorgs rare on Arbitrum One, the canonical chain can still be revised before L1 settlement. Compare parentHash linkage when processing consecutive blocks and only treat data behind the finalized tag as immune to revision.

Caching: Finalized blocks are immutable, so cache them aggressively by hash; never cache an unfinalized latest block as permanent truth. Caching historical block bodies and receipts cuts repeated RPC load for indexers and analytics.

Gas and block space: Track baseFeePerGas and gasUsed per block — Arbitrum One fees combine L2 execution with the cost of posting calldata to Ethereum L1, so monitoring both signals lets you time submissions and size gas limits sensibly in ETH.

Working with Blocks

Core Concepts

Block Retrieval

Best Practices

See also

Ready to call this in production?

Working with Blocks

Core Concepts

Block Retrieval

Best Practices

See also