Skip to main content
Schema: solana.gov Table: fact_staking_lp_actions Type: View

​
Description

This table tracks native staking actions on the Solana blockchain using the official Stake11111111111111111111111111111111111111 program. It captures stake delegation, activation, deactivation, and withdrawal operations directly to validators, enabling comprehensive analysis of native staking participation and validator delegation patterns.

​
Key Use Cases

  • Analyze native staking delegation patterns and validator selection
  • Track stake account lifecycle and balance changes
  • Monitor native staking participation and delegation trends
  • Study validator stake distribution and concentration
  • Support native staking analytics and reward distribution analysis

​
Important Relationships

  • Links to gov.fact_stake_accounts through stake account addresses for staking analysis
  • Connects to gov.fact_validators for validator performance context
  • References core.fact_blocks and core.fact_transactions for blockchain context
  • Provides native staking context for validator analytics

​
Commonly-used Fields

  • block_timestamp: Timestamp when the staking action occurred
  • tx_id: Unique transaction identifier for the staking action
  • stake_account: Address of the stake account
  • vote_pubkey: Vote account that the stake is delegated to
  • action: Type of staking action (e.g., ‘delegate’, ‘deactivate’, ‘withdraw’)
  • amount: Amount of SOL involved in the action
  • user: Address of the user performing the action

​
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’. | | 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. | | INDEX | NUMBER | The position of the transfer event within the list of events for a given Solana transaction. Used to order and reference transfers within a transaction. Indexing starts at 0 for the first event.
Data type: Integer Example:
  • 0 (first transfer in the transaction)
  • 2 (third transfer in the transaction)
Business Context:
  • Enables reconstruction of transfer order and analysis of intra-transaction asset movement.
  • Used to join, filter, or segment data for protocol analytics, error tracing, and event sequencing. | | INNER_INDEX | NUMBER | The position of the inner instruction or event within the list of inner instructions for a given Solana transaction. Used to order and reference nested (CPI) instructions. Indexing starts at 0 for the first inner instruction.
Example:
  • 0
  • 2
Business Context:
  • Enables precise identification and ordering of nested program calls (Cross-Program Invocations) within a transaction.
  • Critical for analyzing composability, protocol integrations, and the full execution path of complex transactions. | | EVENT_TYPE | TEXT | A string categorizing the type of event or instruction, such as ‘transfer’, ‘mint’, ‘burn’, or protocol-specific actions.
Example:
  • ‘transfer’
  • ‘mint’
  • ‘burn’
Business Context:
  • Enables segmentation and filtering of on-chain activity for analytics and dashboards.
  • Used to group and analyze protocol-specific actions and user behaviors.
Relationships:
  • May be derived from decoded instruction data or protocol-specific logic. | | PROGRAM_ID | 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. | | SIGNERS | ARRAY | List of accounts that signed the transaction. This field captures all wallet addresses that provided signatures for the transaction, enabling multi-signature analysis and transaction authority tracking.
Data type: ARRAY (list of Solana addresses) Business context: Used to track transaction signers, analyze multi-signature patterns, and identify transaction authorities. Analytics use cases: Multi-signature analysis, transaction authority tracking, and signer pattern studies. Example: [‘9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM’, ‘AnotherAddress…’] | | ACCOUNT_KEYS | ARRAY | An array of all account addresses referenced by this transaction, including signers, writable, and read-only accounts. Each entry is a base58-encoded Solana address. This list is used to resolve account balances and permissions for transaction execution. See: https://docs.solana.com/developing/programming-model/accounts | | INSTRUCTION | VARIANT | Specifies which program it is calling, which accounts it wants to read or modify, and additional data that serves as auxiliary input to the program | | INNER_INSTRUCTION | VARIANT | A call from one smart contract program to another | | PRE_BALANCES | ARRAY | List of pre-transaction balances for different accounts. This field captures the SOL balances of all accounts involved in the transaction before execution, enabling balance change analysis and transaction impact measurement. Data type: ARRAY (SOL amounts) Business context: Used to track balance changes, analyze transaction impact, and measure SOL movement between accounts. Analytics use cases: Balance change analysis, transaction impact measurement, and SOL movement tracking. Example: [100.0, 50.0, 25.0] | | POST_BALANCES | ARRAY | List of post-transaction balances for different accounts. This field captures the SOL balances of all accounts involved in the transaction after execution, enabling balance change analysis and transaction impact measurement. Data type: ARRAY (SOL amounts) Business context: Used to track balance changes, analyze transaction impact, and measure SOL movement between accounts. Analytics use cases: Balance change analysis, transaction impact measurement, and SOL movement tracking. Example: [95.0, 55.0, 25.0] | | PRE_TOKEN_BALANCES | ARRAY | List of pre-transaction token balances for different token accounts. This field captures the token balances of all token accounts involved in the transaction before execution, enabling token balance change analysis. Data type: ARRAY (token balance objects) Business context: Used to track token balance changes, analyze token movements, and measure token transaction impact. Analytics use cases: Token balance change analysis, token movement tracking, and token transaction impact measurement. Example: [{'mint': 'TokenMintAddress', 'amount': 1000}, {'mint': 'AnotherToken', 'amount': 500}] | | POST_TOKEN_BALANCES | ARRAY | List of post-transaction token balances for different token accounts. This field captures the token balances of all token accounts involved in the transaction after execution, enabling token balance change analysis. Data type: ARRAY (token balance objects) Business context: Used to track token balance changes, analyze token movements, and measure token transaction impact. Analytics use cases: Token balance change analysis, token movement tracking, and token transaction impact measurement. Example: [{‘mint’: ‘TokenMintAddress’, ‘amount’: 900}, {‘mint’: ‘AnotherToken’, ‘amount’: 600}] | | FACT_STAKING_LP_ACTIONS_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. |