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

​
Description

This table tracks voting rewards distributed to vote accounts on the Solana blockchain. It captures reward events for validator voting participation, enabling analysis of voting reward distribution, validator voting performance, and network consensus participation incentives.

​
Key Use Cases

  • Analyze voting reward distribution and validator incentives
  • Track vote account voting performance and reward generation
  • Study voting participation patterns and reward accumulation
  • Monitor validator voting reliability and reward patterns
  • Support validator performance analysis and incentive optimization

​
Important Relationships

  • Links to gov.fact_vote_accounts through vote account addresses for reward analysis
  • Connects to gov.fact_validators through vote_pubkey for validator performance
  • References gov.dim_epoch for epoch-based reward analysis
  • Provides voting reward context for validator analytics

​
Commonly-used Fields

  • block_timestamp: Timestamp when the voting reward was distributed
  • tx_id: Unique transaction identifier for the voting reward
  • vote_pubkey: Address of the vote account receiving the reward
  • node_pubkey: Validator node associated with the vote account
  • reward_amount: Amount of SOL distributed as voting reward
  • epoch: Epoch when the voting reward was earned

​
Columns

Column NameData TypeDescription
BLOCK_TIMESTAMPTIMESTAMP_NTZThe timestamp (UTC) at which the block was produced on the Solana blockchain. This field is recorded as a TIMESTAMP data type and represents the precise moment the block was finalized and added to the chain. It is essential for time-series analysis, block production monitoring, and aligning transaction and event data to specific points in time. Used extensively for analytics involving block intervals, network activity trends, and historical lookups. Format: YYYY-MM-DD HH:MI:SS (UTC).
BLOCK_IDNUMBERA unique identifier for the block in which this transaction was included on the Solana blockchain. Typically a sequential integer or hash, depending on the data source. Used to group transactions by block and analyze block-level activity.
Example:
  • 123456789
Business Context:
  • Supports block-level analytics, such as block production rate and transaction throughput.
  • Useful for tracing transaction inclusion and block explorer integrations.
Relationships:
  • All transactions with the same ‘block_id’ share the same ‘block_timestamp’. | | VOTE_PUBKEY | TEXT | Account address of voter | | EPOCH_EARNED | NUMBER | The epoch that rewards were recieved for. Staking and voting rewards for an epoch are recieved in the first block of the following epoch, so this would identify the prior epoch, which is where the rewards were determined. Fee and rent rewards are determined in the epoch they are recieved. | | REWARD_AMOUNT_SOL | FLOAT | The amount of the asset transferred in the event. For native SOL, this is decimal adjusted and is not in Lamports. For SPL tokens, this is decimal adjusted according to the token’s mint. Represents the value moved from sender to recipient in a single transfer event.
Data type: Numeric (integer for lamports, decimal for tokens) Example:
  • USDC: 50.00 (represents 50 USDC tokens)
Business Context:
  • Used to analyze transaction volumes, user activity, and protocol flows.
  • Supports aggregation of asset movement for analytics and reporting. | | POST_BALANCE_SOL | FLOAT | The amount of SOL in the account after event | | FACT_REWARDS_VOTING_ID | TEXT | A unique identifier for the record. | | MODIFIED_TIMESTAMP | TIMESTAMP_NTZ | The 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. | | INSERTED_TIMESTAMP | TIMESTAMP_NTZ | The 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. | | DIM_EPOCH_ID | TEXT | Join key to the dim_epoch table |