Working with Blocks

Blocks are the unit in which the Avalanche C-Chain records everything — every transfer, contract call, and state change is bundled into a block and finalized under Snowman consensus in roughly one to two seconds. Almost any C-Chain integration ultimately reads blocks: to confirm a transaction landed, to react to on-chain events, to index history, or to price gas. After reading this guide you will be able to retrieve C-Chain blocks by number and by tag from https://avalanche.therpc.io/YOUR_API_KEY, monitor new blocks as they arrive, count confirmations, and reason correctly about finality on chainId 43114 so your application acts on settled data rather than a transient tip.

Core Concepts

What a block contains: each C-Chain block carries a number (height), a hash, the parentHash linking it to the previous block, a timestamp, the baseFeePerGas, the gasLimit and gasUsed, and the list of transactions. The uncles array is always empty on Avalanche since the chain produces no ommers.
Retrieval at the JSON-RPC level: fetch blocks with eth_getBlockByNumber (a decimal-as-hex height or a tag like latest) or eth_getBlockByHash. Pass the full-transactions flag to get whole transaction objects instead of just hashes, and use eth_blockNumber to read the current tip.
Block monitoring: monitoring means reacting to new blocks as they are produced — needed for live dashboards, transaction watchers, and event indexers. Subscribe to newBlockHeaders for push updates, or poll eth_blockNumber where subscriptions are not available.
Confirmations and finality: a confirmation is one block built atop the block holding your transaction; the count is the tip height minus the transaction's block number. More confirmations means deeper burial and greater certainty.
Finality on Avalanche: the C-Chain reaches finality through Snowman consensus within roughly one to two seconds, so once a block is accepted it is effectively irreversible — far faster and more decisive than probabilistic proof-of-work finality, which lets you treat recent blocks as settled with only a small confirmation margin.

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 an explicit timeout on each block request and retry with bounded exponential backoff. The C-Chain's ~1-2s cadence means a few seconds of backoff covers a transient delay without falling behind the tip.
Error handling: always check that a returned block is non-null before using it — a height ahead of the tip yields null. Wrap reads in try/catch, distinguish transient RPC errors (retry) from logical ones (a missing block), and never assume a request succeeded.
Account for reorgs: when reading the latest, unfinalized block, verify each new header's parentHash matches the prior block's hash. Snowman finality makes C-Chain reorgs rare and shallow, but data at the tip can still shift before it finalizes.
Caching: cache finalized C-Chain blocks by hash with a long TTL since they are immutable; keep only a short (~1s) TTL on latest reads so you do not serve a block behind the tip.
Monitoring gas and block space: track baseFeePerGas and gasUsed/gasLimit across recent blocks to price transactions accurately in AVAX and to spot congestion — fee pressure and block fullness directly affect whether your transactions land promptly.

What a block contains: each C-Chain block carries a number (height), a hash, the parentHash linking it to the previous block, a timestamp, the baseFeePerGas, the gasLimit and gasUsed, and the list of transactions. The uncles array is always empty on Avalanche since the chain produces no ommers.

Retrieval at the JSON-RPC level: fetch blocks with eth_getBlockByNumber (a decimal-as-hex height or a tag like latest) or eth_getBlockByHash. Pass the full-transactions flag to get whole transaction objects instead of just hashes, and use eth_blockNumber to read the current tip.

Block monitoring: monitoring means reacting to new blocks as they are produced — needed for live dashboards, transaction watchers, and event indexers. Subscribe to newBlockHeaders for push updates, or poll eth_blockNumber where subscriptions are not available.

Confirmations and finality: a confirmation is one block built atop the block holding your transaction; the count is the tip height minus the transaction's block number. More confirmations means deeper burial and greater certainty.

Finality on Avalanche: the C-Chain reaches finality through Snowman consensus within roughly one to two seconds, so once a block is accepted it is effectively irreversible — far faster and more decisive than probabilistic proof-of-work finality, which lets you treat recent blocks as settled with only a small confirmation margin.

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 an explicit timeout on each block request and retry with bounded exponential backoff. The C-Chain's ~1-2s cadence means a few seconds of backoff covers a transient delay without falling behind the tip.

Error handling: always check that a returned block is non-null before using it — a height ahead of the tip yields null. Wrap reads in try/catch, distinguish transient RPC errors (retry) from logical ones (a missing block), and never assume a request succeeded.

Account for reorgs: when reading the latest, unfinalized block, verify each new header's parentHash matches the prior block's hash. Snowman finality makes C-Chain reorgs rare and shallow, but data at the tip can still shift before it finalizes.

Caching: cache finalized C-Chain blocks by hash with a long TTL since they are immutable; keep only a short (~1s) TTL on latest reads so you do not serve a block behind the tip.

Monitoring gas and block space: track baseFeePerGas and gasUsed/gasLimit across recent blocks to price transactions accurately in AVAX and to spot congestion — fee pressure and block fullness directly affect whether your transactions land promptly.

Working with Blocks

Core Concepts

Block Retrieval

Best Practices

See also

Prêt à utiliser cela en production ?

Working with Blocks

Core Concepts

Block Retrieval

Best Practices

See also