Fact Blocks

core.fact_blocks

Schema: tron.core Table: fact_blocks Type: View

What

This table contains block-level data for the Tron blockchain, providing a complete record of all blocks produced on the network. Each row represents one block with its associated metadata and transaction count. Tron uses Delegated Proof of Stake (DPoS) consensus with 27 elected Super Representatives producing blocks every 3 seconds.

Key Use Cases

• Tracking block production rates and Super Representative activity
• Analyzing network throughput and gas utilization over time
• Monitoring empty vs active blocks (many early blocks have zero transactions)
• Identifying network congestion patterns

Important Relationships

• Join with fact_transactions: Use block_number to analyze all transactions within a block
• Join with fact_event_logs: Use block_number to find all events emitted in a block
• Join with fact_internal_transactions: Use block_number to examine internal calls

Commonly-used Fields

• block_number: Sequential identifier for blocks
• block_timestamp: UTC timestamp of block production
• gas_used: Total gas consumed by all transactions
• tx_count: Number of transactions in the block
• miner: Super Representative address that produced the block

Sample queries

-- Block production and transaction throughput by hour
SELECT
    DATE_TRUNC('hour', block_timestamp) AS hour,
    COUNT(*) AS blocks_count,
    SUM(tx_count) AS total_transactions,
    AVG(tx_count) AS avg_tx_per_block,
    SUM(CASE WHEN tx_count = 0 THEN 1 ELSE 0 END) AS empty_blocks
FROM tron.core.fact_blocks
WHERE block_timestamp >= CURRENT_DATE - 7
GROUP BY 1
ORDER BY 1 DESC;

-- Top Super Representatives by blocks produced
SELECT
    miner,
    COUNT(*) AS blocks_produced,
    SUM(tx_count) AS total_transactions,
    AVG(gas_used) AS avg_gas_used
FROM tron.core.fact_blocks
WHERE block_timestamp >= CURRENT_DATE - 1
GROUP BY 1
ORDER BY 2 DESC
LIMIT 27;

Columns

Column Name	Data Type	Description
BLOCK_NUMBER	NUMBER	Sequential counter representing the position of a block in the Tron blockchain since genesis (block 0). Key Facts: Immutable once finalized Primary ordering mechanism for blockchain data Increments by 1 for each new block Encoded in the first bytes of blockhash Usage in Queries: Important: Many early Tron blocks are empty (zero transactions). Expect blocknumber gaps in transaction-based tables.
BLOCK_HASH	TEXT	The unique hash of the block header. Key Facts: Contains the block number encoded in its first bytes Used for chain reorganization detection Example: ‘0x00000000033fc3d68297d9c3bfab0a01c57a56a61a82f270ba7f9e4400000000’
BLOCK_TIMESTAMP	TIMESTAMP_NTZ	UTC timestamp when the block was produced by the super representative (SR). Format: TIMESTAMP_NTZ (no timezone) Precision: Second-level accuracy Best Practices: Note: Tron produces blocks every 3 seconds via DPoS consensus.
NETWORK	TEXT	The blockchain network name. Example: ‘mainnet’
TX_COUNT	NUMBER	Number of transactions included in the block. Many early Tron blocks contain zero transactions. Example: 142
PARENT_HASH	TEXT	Hash of the previous block (block_number - 1). Example: ‘0x00000000033fc3d58297d9c3bfab0a01c57a56a61a82f270ba7f9e4400000000’
SIZE	NUMBER	Block size in bytes. Example: 125432
EXTRA_DATA	TEXT	EXTRA_DATA column
GAS_LIMIT	NUMBER	GAS_LIMIT column
GAS_USED	NUMBER	Total gas consumed by all transactions in the block. Example: 15234567
BASE_FEE_PER_GAS	NUMBER	BASE_FEE_PER_GAS column
MIX_HASH	TEXT	MIX_HASH column
DIFFICULTY	TEXT	DIFFICULTY column
TOTAL_DIFFICULTY	TEXT	TOTAL_DIFFICULTY column
MINER	TEXT	Address of the Super Representative that produced the block, in 0x-prefixed hex format. Tron has 27 elected Super Representatives that take turns producing blocks. Example: ‘0x414d1ef8673f916debb7e2515a8f3ecaf2611034aa’
UNCLES_SHA3	TEXT	UNCLES_SHA3 column
UNCLES	VARIANT	UNCLES column
TRANSACTIONS_ROOT	TEXT	TRANSACTIONS_ROOT column
RECEIPTS_ROOT	TEXT	RECEIPTS_ROOT column
STATE_ROOT	TEXT	STATE_ROOT column
LOGS_BLOOM	TEXT	LOGS_BLOOM column
FACT_BLOCKS_ID	TEXT	Primary key — unique identifier for each row ensuring data integrity. Format: VARCHAR containing composite key generated using MD5 hash of the relevant columns. Usage: Deduplication in incremental loads Join operations for data quality checks Troubleshooting specific records
INSERTED_TIMESTAMP	TIMESTAMP_NTZ	UTC timestamp when the record was first added to the Flipside database. Format: TIMESTAMP_NTZ Use Cases: Data freshness monitoring Incremental processing markers Debugging data pipeline issues
MODIFIED_TIMESTAMP	TIMESTAMP_NTZ	UTC timestamp of the most recent update to this record. Format: TIMESTAMP_NTZ Use Cases: Tracking data corrections and reprocessing Monitoring incremental model updates Data quality audits