Skip to main content
Schema: solana.core Table: fact_transactions Type: View

View DBT Documentation

View the complete technical documentation and data lineage for this table

​
Description

This table contains one record per transaction on the Solana blockchain, capturing high-level transaction metadata as recorded on-chain. Each record includes block timestamp, transaction identifiers, account and token balance changes, program instructions, and execution metadata for every transaction processed on Solana mainnet. The table covers all finalized transactions, both successful and failed, and is updated as new blocks are processed. Data is sourced from on-chain transaction logs and normalized for analytics. IMPORTANT: This is raw transaction data. For most analytics, use the specialized curated tables instead of querying this large table directly. Transaction components are broken down and extracted into purpose-built tables that are optimized for specific analytical use cases and much easier to work with.

​
Key Use Cases

For most of these use cases, prefer the specialized curated tables listed in “Important Relationships” below:
  • Transaction-level metadata and high-level transaction analytics
  • Fee analysis and cost monitoring for Solana transactions (use fee and succeeded fields)
  • Success/failure rate analysis for transactions
  • Basic wallet and signer analysis (for detailed analysis, use core.ez_signers)
  • Building time-series dashboards for network activity at the transaction level
Use curated tables for these common analyses instead:
  • Token and asset movement: Use core.ez_transfers (includes USD values, token symbols)
  • Program and instruction analysis: Use core.fact_events and core.fact_events_inner
  • Decoded instruction details: Use core.ez_events_decoded
  • Token balance changes: Use core.fact_token_balances

​
Important Relationships

STRONGLY PREFER these curated tables over raw transaction data: For instruction and program analysis:
  • core.fact_events - Parsed instruction events and program interactions
  • core.fact_events_inner - Inner/CPI instruction events for composability analysis
  • core.ez_events_decoded - Human-readable decoded instruction details with arguments
For transfer and asset movement analysis:
  • core.ez_transfers - Token transfers with USD values, symbols, and verification status
  • core.fact_token_balances - Token balance changes over time
For wallet and signer analysis:
  • core.ez_signers - Signer addresses extracted and enriched
Raw transaction relationships:
  • Each transaction links to core.fact_blocks via block_id for block context
  • All curated tables use tx_id to link back to transaction context when needed
  • Raw fields like instructions, inner_instructions, and program_ids are parsed into the specialized tables above
Analysis Guidance:
  • DO NOT parse instructions or inner_instructions arrays directly - use core.fact_events and core.fact_events_inner
  • DO NOT analyze program IDs from raw data - use the events tables for program interaction analysis
  • DO NOT extract transfer data manually - use core.ez_transfers for all transfer analytics
  • DO NOT query this large table for routine analytics - it’s optimized as a source table, not for direct analysis

​
Commonly-used Fields

When using this table directly (discouraged for most use cases):
  • tx_id: Unique identifier for joins with curated tables and traceability
  • block_id and block_timestamp: For time-series and block-level context
  • fee: For transaction cost analysis
  • succeeded: For transaction success/failure rate analysis
  • signers: For basic signer analysis (prefer core.ez_signers for detailed analysis)
Fields to avoid parsing directly (use curated tables instead):
  • instructions, inner_instructions: Use core.fact_events and core.fact_events_inner instead
  • account_keys, pre_balances, post_balances: Use core.ez_transfers or core.fact_token_balances instead
  • log_messages: Use core.ez_events_decoded for parsed program logs
Reminder: For most analytics, query the specialized curated tables that extract and enrich these raw fields rather than parsing them manually from this table.

​
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.
TX_IDTEXTThe 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.
RECENT_BLOCK_HASHTEXTThe hash of the most recent block prior to this transaction, as recorded on the Solana blockchain. Used to prevent transaction replay and ensure transaction freshness. This value is a base58-encoded string representing the block hash at the time the transaction was submitted.
SIGNERSARRAYList 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.
FEENUMBERThe transaction fee paid for processing this transaction, denominated in lamports (the smallest unit of SOL). This fee is deducted from the payer’s account and is determined by the compute resources consumed and the current network fee rate.
SUCCEEDEDBOOLEANBoolean 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.
ACCOUNT_KEYSARRAYAn 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.
PRE_BALANCESARRAYList 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.
POST_BALANCESARRAYList 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.
PRE_TOKEN_BALANCESARRAYList 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.
POST_TOKEN_BALANCESARRAYList 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.
INSTRUCTIONSARRAYAn array of program instructions executed as part of this transaction. Each instruction includes the program ID, accounts involved, and input data. Instructions define the actions performed by the transaction.
INNER_INSTRUCTIONSARRAYAn array of instructions invoked by programs during the execution of the main transaction instructions. Inner instructions are generated by CPI (cross-program invocation) and provide details on program-to-program calls.
LOG_MESSAGESARRAYAn array of log messages emitted by programs during transaction execution. Useful for debugging, tracing program logic, and analyzing transaction outcomes. Each entry is a string message as output by the Solana runtime.
UNITS_CONSUMEDNUMBERThe number of compute units consumed by this transaction. Compute units measure the computational resources used and are used to calculate transaction fees.
UNITS_LIMITNUMBERThe maximum number of compute units allowed for this transaction, as set by the compute budget instruction. Transactions exceeding this limit will fail.
TX_SIZENUMBERThe size of the transaction in bytes, including all instructions, signatures, and account references. Used to analyze transaction complexity and network resource usage.
TX_INDEXNUMBERThe position of this transaction within its containing block, starting from zero. Used to order transactions within a block and analyze intra-block activity.
FACT_TRANSACTIONS_IDTEXTA 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_TIMESTAMPTIMESTAMP_NTZThe 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_TIMESTAMPTIMESTAMP_NTZThe 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.

​
Column Details

​
BLOCK_ID

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

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

​
RECENT_BLOCK_HASH

Business Context:
  • Used to prevent transaction replay and ensure transaction freshness
References:

​
SIGNERS

Example:
  • ['9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM', 'AnotherAddress...']
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

​
FEE

References:

​
SUCCEEDED

Example:
  • true
  • false
Business Context:
  • Used to filter for successful transactions in analytics and reporting.
  • Important for error analysis, user experience, and program debugging.

​
ACCOUNT_KEYS

References:

​
PRE_BALANCES

Example:
  • [100.0, 50.0, 25.0]
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

​
POST_BALANCES

Example:
  • [95.0, 55.0, 25.0]
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

​
PRE_TOKEN_BALANCES

Example:
  • [{'mint': 'TokenMintAddress', 'amount': 1000}, {'mint': 'AnotherToken', 'amount': 500}]
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

​
POST_TOKEN_BALANCES

Example:
  • [{'mint': 'TokenMintAddress', 'amount': 900}, {'mint': 'AnotherToken', 'amount': 600}]
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

​
INSTRUCTIONS

References:

​
INNER_INSTRUCTIONS

References:

​
LOG_MESSAGES

References:

​
UNITS_CONSUMED

References:

​
UNITS_LIMIT

References:

​
TX_SIZE

References:

​
TX_INDEX

Example:
  • 0
  • 15
Business Context:
  • Useful for reconstructing block order and analyzing transaction sequencing.
  • Can be used to identify priority transactions or block congestion.
Relationships:
  • Used with block_id and block_timestamp for full ordering.