A block is a list of transactions plus metadata that links it to the previous block. Linking blocks by their identifiers forms the chain, making historical state tamper-evident: any change to a past block invalidates every later block, and any node validating the chain detects the inconsistency immediately.

This page covers the contents of a block, the composite block ID design that is unique to TRON, and how blocks are produced.

📘

Prerequisites

• Accounts and keys
• Consensus and DPoS

Block structure

Each block has two top-level sections: block_header (containing raw_data and a signature) and a list of transactions. Here is a representative block:

{
  "blockID": "000000000164387f...4e1dc6c6",
  "block_header": {
    "raw_data": {
      "number": 23345279,
      "txTrieRoot": "b04e2c9f...e7a3041e",
      "witness_address": "410765be...888e606",
      "parentHash": "00000000...4e1dc6c6",
      "version": 28,
      "timestamp": 1715000000000
    },
    "witness_signature": "73f5c6a8...1b2c3d4e"
  },
  "transactions": [
    /* transaction objects — see Transactions */
  ]
}

The fields:

📘

Legacy witness_* naming

The witness_* field names are TRON's internal naming and are kept in code, configuration, and protobuf for backward compatibility. In documentation prose, the role is called Super Representative (SR).

Block ID

A block's ID is not a simple hash of the block. It is a 32-byte composite value:

This composite design lets nodes verify both the block's position (via the number prefix) and its content (via the hash suffix) from a single value. The next block's parentHash field stores the previous block's complete block ID — this is the link that chains blocks together.

The 8-byte number prefix is also reused in the TAPOS mechanism: every transaction includes ref_block_bytes that references a recent block, and TAPOS uses bytes from this composite block ID to anchor the transaction to the chain.

Because of the composite design, prose and table headers in TRON documentation use block number when referring to the sequential integer (height) and block ID when referring to the unique identifier. The term "block hash" does not match the actual structure and is avoided.

Block production

The TRON network produces a new block every 3 seconds. The 27 active Super Representatives take turns: each round of 27 slots gives each SR exactly one slot, and the rotation order is fixed for that round.

If a scheduled SR fails to produce its block on time (because of network issues or downtime), the slot is skipped. The next scheduled SR produces the next block at its own slot time, leaving a gap in the timestamps.

The schedule pauses briefly at the start of each Maintenance Period (every 6 hours), while the network promotes new SRs into the active set based on the latest vote tallies. Block production resumes immediately after the rotation update.

For the full mechanism — including how blocks become irreversible — see Consensus and DPoS.

Block size

A TRON block can hold up to 2,000,000 bytes (≈ 1.9 MB) of transaction data. This limit gives SRs enough headroom to include large smart-contract transactions while keeping block propagation fast across the network.

APIs

How to query blocks and transactions

Block query APIs are split by latest block, solidified block, block number, block ID, and block range. Transactions embedded in a block are transaction bodies. Execution result, fees, events, and internal transactions are in the receipt and must be queried through transaction receipt APIs.

For TriggerSmartContract transactions, do not infer business success only from the transaction body embedded in a block. Query the receipt. For the complete confirmation path, see Sign and broadcast — the API workflow.

Related resources

• Consensus and DPoS — How blocks are produced and become irreversible
• Transactions — What blocks contain
• TronScan — Block explorer to inspect blocks on-chain