Skip to main content
Schema: solana.gov Table: fact_block_production Type: Base Table

​
What

​
Description

This table tracks block production events on the Solana blockchain, capturing which validators produced blocks and when. It provides insights into network performance, validator participation in consensus, and block production distribution across the validator set.

​
Key Use Cases

  • Analyze block production distribution across validators
  • Track validator participation in network consensus
  • Monitor network performance and block production efficiency
  • Study validator reliability and block production patterns
  • Support network health analysis and validator performance metrics

​
Important Relationships

  • Links to gov.fact_validators through node_pubkey for validator performance analysis
  • Connects to gov.fact_vote_accounts for vote account analysis
  • References core.fact_blocks for block context
  • Provides block production context for validator analytics

​
Commonly-used Fields

  • block_timestamp: Timestamp when the block was produced
  • block_id: Block number that was produced
  • node_pubkey: Address of the validator that produced the block
  • vote_pubkey: Vote account associated with the block producer
  • epoch: Epoch when the block was produced

​
Columns

Column NameData TypeDescription
EPOCHNUMBERA period of time consisting of 432,000 blocks, which represents a higher-level timekeeping unit within the Solana network
NODE_PUBKEYTEXTThe account for the validator node on the Solana network. This field identifies the specific validator that participates in network consensus and receives stake delegations. Data type: STRING (Solana address) Business context: Used to identify validators, track performance, and analyze stake delegation patterns. Analytics use cases: Validator identification, performance tracking, and stake delegation analysis. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’
NUM_LEADER_SLOTSNUMBERThe number of slots the validator was the leader for in the epoch. This field tracks how many times the validator was selected as the slot leader, enabling validator performance analysis and network participation measurement. Data type: INTEGER (slot count) Business context: Used to analyze validator performance, track network participation, and measure validator reliability. Analytics use cases: Validator performance analysis, network participation tracking, and reliability measurement. Exam…
NUM_BLOCKS_PRODUCEDNUMBERThe number of blocks the validator produced in the epoch. This field tracks the actual blocks created by the validator when it was the slot leader, enabling block production analysis and validator efficiency measurement. Data type: INTEGER (block count) Business context: Used to analyze validator block production efficiency, track network performance, and measure validator reliability. Analytics use cases: Block production analysis, network performance tracking, and validator efficiency measu…
START_SLOTNUMBERThe first slot of the epoch. This field identifies the beginning slot number for the epoch, enabling epoch boundary tracking and time-based analysis. Data type: INTEGER (slot number) Business context: Used to track epoch boundaries, analyze time-based patterns, and provide epoch context for block production data. Analytics use cases: Epoch boundary tracking, time-based analysis, and epoch context provision. Example: 123456789, 123456800
END_SLOTNUMBERThe final slot of the epoch. This field identifies the ending slot number for the epoch, enabling epoch boundary tracking and time-based analysis. Data type: INTEGER (slot number) Business context: Used to track epoch boundaries, analyze time-based patterns, and provide epoch context for block production data. Analytics use cases: Epoch boundary tracking, time-based analysis, and epoch context provision. Example: 123456789, 123456800
FACT_BLOCK_PRODUCTION_IDTEXTA unique, stable identifier for each record in this table. The primary key (PK) ensures that every row is uniquely identifiable and supports efficient joins, lookups, and data integrity across models. The PK may be a natural key (such as a blockchain transaction hash) or a surrogate key generated from one or more fields, depending on the table’s structure and requirements.
INSERTED_TIMESTAMPTIMESTAMP_NTZThe timestamp when this transaction record was first inserted into the analytics database. Used for data freshness tracking and incremental model logic. Format: YYYY-MM-DD HH:MI:SS. Not derived from the blockchain, but from the ETL process.
MODIFIED_TIMESTAMPTIMESTAMP_NTZThe timestamp when this transaction record was last updated in the analytics database. Used for tracking updates and supporting incremental model logic. Format: YYYY-MM-DD HH:MI:SS. Not derived from the blockchain, but from the ETL process.