eth_getBlockByHash - TRON RPC Method

Returns information about a block by hash on TRON.

Why TRON? Build on the TVM-compatible Layer 1 for TRC-20 payments, wallet APIs, and low-cost smart contract execution with TVM compatibility paired with native TRON wallet APIs, DPoS block production, and low-cost transaction flows.

When to Use This Method

eth_getBlockByHash is essential for TRON developers building payment rails, exchanges, and consumer crypto applications:

• Block verification using deterministic hash lookup: Retrieve block data by its unique, immutable hash on TRON
• Chain reorganization handling: Track blocks reliably by hash during reorgs on the TVM-compatible Layer 1 for TRC-20 payments, wallet APIs, and low-cost smart contract execution
• Cross-chain bridge finality verification: Confirm block existence by its canonical hash for TRC-20 transfers, wallet operations, and EVM-compatible smart contract integrations
• 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 TRON.

import { JsonRpcProvider } from 'ethers';

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

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('0xdcfaa73d566d819ff95b8a9ae944e34c011fb16dd55bce7830a80016c54acf71');

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 the TVM-compatible Layer 1 for TRC-20 payments, wallet APIs, and low-cost smart contract execution.

from web3 import Web3

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

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('0x0000000004d4dd2a62243e06966cb322aefec631e1ec0ce68ed3f2482cecccb9')

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 TRON.

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-tron-mainnet.n.dwellir.com/YOUR_API_KEY/jsonrpc")

    knownHash := common.HexToHash("0x0000000004d4dd2a62243e06966cb322aefec631e1ec0ce68ed3f2482cecccb9")
    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()))
}

Sample Freshness

Use a recent block hash when you copy these examples into your own tooling. Shared RPC infrastructure can return null if the block is no longer available on the node you are querying, so replace placeholders with a fresh block hash when you test or automate against this method later.

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

Code Examples

Error Handling

Related Methods

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