eth_getBlockByHash - Arc RPC Method

Returns information about a block by hash on Arc.

Why Arc? Build on Circle's stablecoin-native Layer 1 where USDC is the gas token and BFT consensus gives sub-second deterministic finality with USDC as the native gas token, sub-second irreversible finality, an EWMA-smoothed fee market with a 20 Gwei floor, and EIP-7708 Transfer logs for native value movement.

When to Use This Method

eth_getBlockByHash is essential for payment platforms, stablecoin issuers, exchange and treasury teams, and Solidity developers building on Arc:

• Block verification using deterministic hash lookup: Retrieve block data by its unique, immutable hash on Arc
• Chain reorganization handling: Track blocks reliably by hash during reorgs on Circle's stablecoin-native Layer 1 where USDC is the gas token and BFT consensus gives sub-second deterministic finality
• Cross-chain bridge finality verification: Confirm block existence by its canonical hash for crossborder settlement, merchant payments, institutional clearing, and USDC-denominated financial applications
• Deterministic queries when block number may change: Ensure consistent results for applications that need stable references regardless of chain state

Common Use Cases

1. Verify a Specific Block from a Transaction's blockHash Field

When a transaction response includes blockHash, use eth_getBlockByHash to retrieve the full parent block. This cross-references the transaction's context and confirms which block it was included in on Arc.

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider('https://api-arc-mainnet.n.dwellir.com/YOUR_API_KEY');

async function verifyBlockFromTx(txHash) {
  const tx = await provider.getTransaction(txHash);
  if (!tx || !tx.blockHash) return null;

  const block = await provider.getBlock(tx.blockHash);
  console.log(`Transaction ${txHash} in block #${block.number}`);
  console.log(`Block hash: ${block.hash}`);
  console.log(`Block timestamp: ${new Date(block.timestamp * 1000).toISOString()}`);
  return block;
}

verifyBlockFromTx('0x4c4fad6d08e677e54644301bbbbffcba734b6c5fb3e47488565b61ecae3b0c1f');

2. Cross-Reference Blocks During Chain Reorganization

During a chain reorganization, block numbers can shift but block hashes remain unique identifiers. Use eth_getBlockByHash to verify the canonical chain state and detect whether a previously observed block has been orphaned on Circle's stablecoin-native Layer 1 where USDC is the gas token and BFT consensus gives sub-second deterministic finality.

from web3 import Web3

w3 = Web3(Web3.HTTPProvider('https://api-arc-mainnet.n.dwellir.com/YOUR_API_KEY'))

def verify_block_still_canonical(block_hash):
    block = w3.eth.get_block(block_hash)
    if block is None:
        print(f'Block {block_hash} has been pruned or orphaned')
        return False
    print(f'Block {block_hash} still canonical at height #{block.number}')
    return True

# Check a known block hash
verify_block_still_canonical('0x78832716c6c7748b86d169975f583044511781701d74dc1443b35292b17c87ba')

3. Audit Block Data by Known Hash Reference

For compliance and audit workflows, store block hashes as permanent references. Re-querying eth_getBlockByHash with a stored hash guarantees you retrieve the exact same block data, even months later on Arc.

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/ethereum/go-ethereum/common"
    "github.com/ethereum/go-ethereum/ethclient"
)

func main() {
    client, _ := ethclient.Dial("https://api-arc-mainnet.n.dwellir.com/YOUR_API_KEY")

    knownHash := common.HexToHash("0x78832716c6c7748b86d169975f583044511781701d74dc1443b35292b17c87ba")
    block, err := client.BlockByHash(context.Background(), knownHash)
    if err != nil || block == nil {
        log.Fatal("Block not found: may be pruned from node")
    }

    fmt.Printf("Audited block #%d\n", block.Number().Uint64())
    fmt.Printf("Hash: %s\n", block.Hash().Hex())
    fmt.Printf("Transactions: %d\n", len(block.Transactions()))
}

Best Practices

• Hash-based lookups are more reliable during chain reorgs than number-based: A block hash uniquely identifies one canonical block, while a block number may shift to a different block after a reorg
• Store block hashes in your database for future verification: Persisting the hash alongside related records enables deterministic re-querying for audits and data integrity checks
• Handle null results gracefully: Blocks can be pruned by the node, especially on non-archive endpoints; your application should treat a null response as a missing or unavailable block
• For L2 optimistic rollups, verify the L1 anchor hash separately: The hash on the L2 chain references a different block space than the L1 anchor; validate both independently for full finality confidence

Arc block header notes

Four header fields behave differently on Arc than on Ethereum:

• extraData carries the next block's base fee, as an 8-byte big-endian value. Read it to price a transaction for the block you are about to land in.
• timestamp is non-decreasing, not strictly increasing. Timestamps come from the proposer's wall clock at one-second granularity, and Arc produces sub-second blocks, so consecutive blocks can share a timestamp. Order events by block number, never by timestamp.
• mixHash / PREVRANDAO is always 0. Arc has no beacon-chain RANDAO, so there is no onchain randomness source. The EIP-4788 beacon-roots contract is also omitted; parentBeaconBlockRoot is set to the parent execution block hash and reads from the beacon-roots contract return empty.
• withdrawals is always empty. Arc has no EIP-4895 withdrawals.

Blocks are final on commit. Arc's Malachite BFT consensus gives deterministic finality in under a second, so a block returned by this method will never be reorganized out.

Code Examples

Error Handling

Related Methods

• eth_getBlockByNumber - Get block by number
• eth_blockNumber - Get latest block number