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

Description

This table tracks fee rewards distributed on the Solana blockchain, capturing transaction fee distribution to validators and vote accounts. It enables analysis of fee reward patterns, validator fee income, and network fee distribution across the validator set.

Key Use Cases

  • Analyze fee reward distribution and validator income
  • Track validator fee generation and reward patterns
  • Study network fee distribution and validator incentives
  • Monitor fee reward accumulation and validator economics
  • Support validator performance and fee optimization analysis

Important Relationships

  • Links to gov.fact_validators through node_pubkey for validator fee analysis
  • Connects to gov.fact_vote_accounts through vote_pubkey for vote account fee analysis
  • References gov.dim_epoch for epoch-based fee analysis
  • Provides fee reward context for validator economics

Commonly-used Fields

  • block_timestamp: Timestamp when the fee reward was distributed
  • tx_id: Unique transaction identifier for the fee reward
  • vote_pubkey: Vote account receiving the fee reward
  • node_pubkey: Validator node associated with the fee reward
  • reward_amount: Amount of SOL distributed as fee reward
  • epoch: Epoch when the fee 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’. | | PUBKEY | TEXT | The address receiving the fee rewards. This field identifies the account that received the fee reward, enabling reward distribution analysis and recipient tracking.
Data type: STRING (Solana address) Business context: Used to track reward recipients, analyze reward distribution patterns, and identify fee reward beneficiaries. Analytics use cases: Reward distribution analysis, recipient tracking, and fee reward beneficiary identification. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’ | | 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_FEE_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 |