Fact Proposal Creation

Schema: solana.gov Table: fact_proposal_creation Type: Base Table

​

Description

This table tracks governance proposal creation events across different platforms including Realms and Tribeca. It captures the initial creation of governance proposals, including proposal details, creator information, and proposal parameters, enabling comprehensive analysis of governance proposal lifecycle and creation patterns.

​

Key Use Cases

• Track governance proposal creation patterns and frequency
• Analyze proposal creation by different governance platforms
• Study proposal lifecycle from creation to voting
• Monitor governance participation and proposal diversity
• Support DAO analytics and governance reporting

​

Important Relationships

• Links to gov.fact_proposal_votes through proposal address for complete proposal lifecycle
• Connects to gov.fact_gov_actions for governance action analysis
• References core.fact_blocks and core.fact_transactions for blockchain context
• Provides proposal context for governance analytics

​

Commonly-used Fields

• block_timestamp: Timestamp when the proposal was created
• tx_id: Unique transaction identifier for the proposal creation
• proposal: Address representing the created proposal
• creator: Address of the account that created the proposal
• governance_platform: Platform where the proposal was created
• program_name: Name of the governance program
• realms_id: Address representing the voting group within Realms

​

Columns

Column Name	Data Type	Description
GOVERNANCE_PLATFORM	TEXT	The 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 unique public key (base58-encoded address) of a Solana program. This field identifies the on-chain program (smart contract) responsible for processing instructions, emitting events, or managing accounts. Used throughout Solana analytics models—including events, transactions, IDLs, and program activity tables—to join, filter, and analyze program-level data. Example:

• “4Nd1mY…”
• “TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA”

Business Context:

• Used as a join key for program activity, deployments, events, and interface changes.
• Supports segmentation of activity by protocol, DEX, NFT marketplace, or other on-chain application. | | 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. | | 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’ | | 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’ | | PROPOSAL_WRITER | TEXT | Address of the user who is submitting the proposal for voting. This field identifies the creator of the governance proposal, enabling creator analysis and proposal attribution tracking. Data type: STRING (user address) Business context: Used to track proposal creators, analyze creator patterns, and attribute governance activity to specific users. Analytics use cases: Creator tracking, pattern analysis, and activity attribution. Example: ‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’ | | PROPOSAL_NAME | TEXT | The name of the proposal that is being submitted. This field contains the human-readable title or name of the governance proposal, enabling proposal identification and content analysis. Data type: STRING (proposal name) Business context: Used to identify proposals, analyze proposal content themes, and categorize governance topics. Analytics use cases: Proposal identification, content theme analysis, and topic categorization. Example: ‘Increase Treasury Allocation’, ‘Update Protocol Parameters’, ‘Community Grant Proposal’ | | VOTE_TYPE | TEXT | The type of voting strategy that will be used for voting on the proposal. This field specifies the voting mechanism or strategy for the governance proposal, enabling voting analysis and strategy comparison. Data type: STRING (vote type) Business context: Used to track voting strategies, analyze voting mechanisms, and compare different governance approaches. Analytics use cases: Strategy tracking, mechanism analysis, and approach comparison. Example: ‘Single Choice’, ‘Multiple Choice’, ‘Quadratic Voting’, ‘Token Weighted’ | | VOTE_OPTIONS | TEXT | The options that will be available to users who are voting on the proposal. This field contains the available voting choices or options for the governance proposal, enabling option analysis and voting choice tracking. Data type: ARRAY (vote options) Business context: Used to track voting options, analyze choice patterns, and understand proposal structure. Analytics use cases: Option tracking, choice pattern analysis, and structure understanding. Example: [‘Yes’, ‘No’], [‘Option A’, ‘Option B’, ‘Option C’], [‘Approve’, ‘Reject’, ‘Abstain’] | | FACT_PROPOSAL_CREATION_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. |