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

​
Description

This table tracks gauge voting events, particularly for Marinade Finance’s gauge system. Gauge voting allows users to allocate rewards to different liquidity pools or protocols, providing a mechanism for decentralized reward distribution and liquidity incentivization.

​
Key Use Cases

  • Analyze gauge voting patterns and reward allocation preferences
  • Track reward distribution across different protocols and pools
  • Study liquidity incentivization strategies and effectiveness
  • Monitor gauge voting participation and user behavior
  • Support DeFi analytics and reward optimization

​
Important Relationships

  • Links to gov.fact_gov_actions through governance context for comprehensive governance analysis
  • Connects to gov.fact_gauges_creates for gauge creation lifecycle
  • References core.fact_blocks and core.fact_transactions for blockchain context
  • Provides gauge context for DeFi analytics

​
Commonly-used Fields

  • block_timestamp: Timestamp when the gauge vote was cast
  • tx_id: Unique transaction identifier for the gauge vote
  • voter: Address of the account that cast the gauge vote
  • gauge: Address of the gauge being voted on
  • vote_weight: Weight of the vote for reward allocation
  • program_name: Name of the gauge program (e.g., ‘marinade’)

​
Columns

Column NameData TypeDescription
PROGRAM_NAMETEXTThe name of the Solana program that processed the governance action or transaction. This field identifies which specific governance protocol or program handled the action, enabling cross-program analysis and protocol-specific filtering.
Data type: STRING (program identifier) Business context: Used to identify governance programs and analyze cross-protocol governance patterns and adoption. Analytics use cases: Program usage analysis, cross-protocol governance comparison, and governance tool adoption tracking. Example: ‘marinade’, ‘saber’, ‘realms’ | | BLOCK_TIMESTAMP | TIMESTAMP_NTZ | The 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_ID | NUMBER | A 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’. | | TX_ID | TEXT | The unique transaction signature (hash) for each transaction on the Solana blockchain. This field is a base58-encoded string, typically 88 characters in length, and serves as the primary identifier for transactions across all Solana data models. Used to join transaction data with related tables (blocks, events, transfers, logs, decoded instructions) and to trace the full lifecycle and effects of a transaction. Essential for transaction-level analytics, debugging, and cross-referencing with block explorers or Solana APIs.
Example:
  • 5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw
Business Context:
  • Enables precise tracking, auditing, and attribution of on-chain activity
  • Used for linking transactions to events, logs, and protocol actions
  • Critical for compliance, monitoring, and analytics workflows | | SUCCEEDED | BOOLEAN | Boolean flag indicating whether the transaction was successfully executed and confirmed on the Solana blockchain. A value of TRUE means the transaction was processed without errors; FALSE indicates failure due to program errors, insufficient funds, or other issues.
Example:
  • true
  • false
Business Context:
  • Used to filter for successful transactions in analytics and reporting.
  • Important for error analysis, user experience, and program debugging. | | VOTER | TEXT | Address performing the vote | | VOTER_NFT | TEXT | NFT representing tokens for governance. This is only available for certain types of governance. | | GAUGE | TEXT | Address that determines the rewards share to give to a liquidity pool, or in the case of Marinade, the amount of SOL that should be delegated to a given validator | | POWER | NUMBER | Total voting power of the voter. This is only available for certain types of gauge votes. | | DELEGATED_SHARES | NUMBER | Number of shares delegated to vote for this gauge | | FACT_GAUGES_VOTES_ID | TEXT | A 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_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. | | 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. |