Fact Events

​

Description

​

Key Use Cases

• Analyze program interactions and instruction execution flow
• Track specific program events, methods, or user actions
• Protocol usage analytics and event-level activity monitoring
• Avoid complex JSON array parsing from core.fact_transactions by using pre-parsed event fields
• Downstream analytics for protocol-specific event flows and decoded instructions

​

Important Relationships

• Closely related to core.fact_events_inner (for inner/CPI events), core.ez_events_decoded (preferred for decoded instruction details), and core.ez_transfers (for transfer events)
• Use core.fact_events_inner to analyze Cross-Program Invocations (CPIs) and nested program calls
• Use core.ez_events_decoded for detailed instruction and argument analysis (if program is being decoded)
• Use core.ez_transfers for asset movement and transfer analytics
• Joins with core.fact_blocks for block context and core.fact_transactions for transaction context

​

Commonly-used Fields

• block_timestamp: For time-series and event sequencing analysis
• block_id, tx_id, index: For unique event identification and joins
• program_id, event_type: For filtering by program or event type
• instruction, inner_instruction: For instruction-level analytics
• signers, succeeded: For user attribution and transaction outcome analysis

​

Sample Queries

​

Event distribution by program with inner instruction metrics

SELECT
    DATE_TRUNC('day', block_timestamp) AS date,
    program_id,
    COUNT(*) AS event_count,
    COUNT(DISTINCT tx_id) AS unique_transactions,
    AVG(ARRAY_SIZE(inner_instruction_events)) AS avg_inner_events,
    MAX(ARRAY_SIZE(inner_instruction_events)) AS max_inner_events
FROM solana.core.fact_events
WHERE block_timestamp >= CURRENT_DATE - 7
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC;

​

Simple event count by program

SELECT
    program_id,
    COUNT(*) AS total_events
FROM solana.core.fact_events
WHERE block_timestamp >= CURRENT_DATE - 1
GROUP BY program_id
ORDER BY total_events DESC
LIMIT 20;

​

Recent events with basic details

SELECT
    block_timestamp,
    tx_id,
    program_id,
    instruction_index,
    data
FROM solana.core.fact_events
WHERE block_timestamp >= CURRENT_TIMESTAMP - INTERVAL '1 hour'
ORDER BY block_timestamp DESC
LIMIT 100;

​

Columns

• 123456789

• Supports block-level analytics, such as block production rate and transaction throughput.
• Useful for tracing transaction inclusion and block explorer integrations.

• 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.

• 5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw5Nf6Q2k6v1Qw2k3v4Qw

• 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 | | 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.

• true
• false

• 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.

• 0 (first transfer in the transaction)
• 2 (third transfer in the transaction)

• 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. | | EVENT_TYPE | TEXT | A string categorizing the type of event or instruction, such as ‘transfer’, ‘mint’, ‘burn’, or protocol-specific actions.

• ‘transfer’
• ‘mint’
• ‘burn’

• Enables segmentation and filtering of on-chain activity for analytics and dashboards.
• Used to group and analyze protocol-specific actions and user behaviors.

• 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.

• “4Nd1mY…”
• “TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA”

• 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. | | 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 | | FACT_EVENTS_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. |