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

​
Description

This table captures all governance proposal votes across different platforms including Realms and Tribeca (Marinade). It tracks voting participation, vote choices, voting power, and governance decisions, providing comprehensive analytics on decentralized governance voting patterns and decision-making processes.

​
Key Use Cases

  • Analyze voting participation and patterns across governance platforms
  • Track proposal outcomes and voting power distribution
  • Study governance decision-making processes and voter behavior
  • Monitor governance platform adoption and usage trends
  • Support DAO analytics and governance reporting

​
Important Relationships

  • Links to gov.fact_gov_actions through governance context for comprehensive governance analysis
  • Connects to gov.fact_proposal_creation for proposal lifecycle tracking
  • References core.fact_blocks and core.fact_transactions for blockchain context
  • Provides voting context for protocol-specific governance analytics

​
Commonly-used Fields

  • block_timestamp: Timestamp when the vote was cast
  • tx_id: Unique transaction identifier for the vote
  • voter: Address of the account that cast the vote
  • voter_account: Account with locked tokens linked to the NFT (determines voting power)
  • voter_nft: NFT mint used in this vote on Marinade
  • proposal: Address representing the proposal being voted on
  • governance_platform: Platform used for governance (e.g., ‘realms’, ‘tribeca’)
  • program_name: Name of the governance program
  • vote_choice: The voting option selected by the user on a Realms proposal
  • vote_rank: The order which a user ranks their choices on a ranked vote
  • vote_weight: Percentage of voting power put towards a voting option
  • realms_id: Address representing the voting group within Realms

​
Columns

Column NameData TypeDescription
GOVERNANCE_PLATFORMTEXTThe platform used for governance space and voting mechanisms. This field identifies which governance platform hosted the voting activity, enabling cross-platform analysis and platform adoption tracking.
Data type: STRING (platform identifier) Business context: Used to identify governance platforms and analyze cross-platform governance patterns and tool adoption. Analytics use cases: Platform adoption analysis, cross-platform governance comparison, and governance tool effectiveness studies. Example: ‘realms’, ‘tribeca’ | | PROGRAM_NAME | TEXT | The 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 | The address of the account that cast the governance vote. This field identifies the specific wallet or account that participated in the governance decision, enabling voter analysis and participation tracking.
Data type: STRING (Solana address) Business context: Used to track governance participation, analyze voter behavior, and identify key governance participants. Analytics use cases: Voter participation analysis, whale voting tracking, and governance participation pattern studies. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’ | | VOTER_ACCOUNT | TEXT | The account with locked tokens linked to the NFT that determines voting power. This field identifies the specific account that holds the governance tokens and determines the voting power for the governance action. Data type: STRING (Solana address) Business context: Used to analyze voting power distribution, governance token holdings, and voter influence measurement. Analytics use cases: Voting power analysis, governance token distribution studies, and voter influence measurement. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’ | | VOTER_NFT | TEXT | The NFT mint used in this vote on Marinade governance. This field identifies the specific NFT that was used to participate in the governance vote, enabling NFT-based voting analysis and utility measurement. Data type: STRING (NFT mint address) Business context: Used to track NFT-based governance participation and analyze the utility of governance NFTs. Analytics use cases: NFT-based voting analysis, governance participation tracking, and NFT utility measurement. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’ | | PROPOSAL | TEXT | Address representing the proposal being voted on. This field identifies the specific proposal within the governance system, enabling proposal tracking and governance activity analysis. Data type: STRING (proposal address) Business context: Used to track individual proposals, analyze proposal lifecycle, and monitor governance activity. Analytics use cases: Proposal tracking, lifecycle analysis, and governance activity monitoring. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’ | | REALMS_ID | TEXT | An address that is unique to the space or voting group on Realms. This field identifies the specific governance space within the Realms platform where the proposal is being created, enabling governance space analysis and proposal categorization. Data type: STRING (Realms address) Business context: Used to track governance spaces, analyze proposal distribution across spaces, and categorize governance activity. Analytics use cases: Governance space tracking, proposal distribution analysis, and activity categorization. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’ | | VOTE_CHOICE | TEXT | The voting option selected by the user on a Realms proposal. This field captures the specific choice made by the voter, enabling voting preference analysis and outcome prediction. Data type: STRING (voting option) Business context: Used to track voting preferences, analyze proposal outcomes, and measure governance sentiment. Analytics use cases: Voting preference analysis, proposal outcome prediction, and governance sentiment analysis. Example: ‘yes’, ‘no’, ‘abstain’ | | VOTE_RANK | NUMBER | The order which a user ranks their choices on a ranked vote on Realms. This field captures the preference ranking in multi-choice governance votes, enabling ranked voting analysis and preference ordering studies. Data type: INTEGER (ranking number) Business context: Used to analyze ranked voting patterns, preference ordering, and governance decision complexity. Analytics use cases: Ranked voting analysis, preference ordering studies, and governance decision complexity measurement. Example: 1, 2, 3 | | VOTE_WEIGHT | NUMBER | The percentage of voting power put towards a voting option on Realms. This field represents the proportion of a voter’s total voting power allocated to a specific choice in weighted voting systems. Data type: DECIMAL (percentage as decimal) Business context: Used to analyze voting power distribution, measure governance influence, and study weighted voting outcomes. Analytics use cases: Voting power distribution analysis, governance influence measurement, and weighted voting outcome studies. Example: 0.75, 1.0, 0.25 | | FACT_PROPOSAL_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. |