Skip to main content
Schema: somnia.core Table: fact_transactions Type: Base Table

What

This table contains comprehensive transaction-level data for EVM blockchains. Each row represents a single transaction with its execution details, gas consumption, and value transfers. This is a high-level table for analyzing on-chain activity, user behavior, and protocol interactions.

Key Use Cases

  • Tracking wallet activity and transaction patterns
  • Analyzing gas fee trends and optimization opportunities
  • Monitoring smart contract interactions and usage
  • Calculating transaction volumes and network revenue
  • Detecting MEV, arbitrage, and trading patterns

Important Relationships

  • Join with fact_blocks: Use block_number for block-level context
  • Join with fact_traces: Use tx_hash for internal transactions
  • Join with fact_event_logs: Use tx_hash for emitted events
  • Join with ez_decoded_event_logs: Use tx_hash for human-readable events
  • Join with dim_contracts: Use to_address for contract metadata

Commonly-used Fields

  • tx_hash: Unique transaction identifier
  • from_address: Transaction sender
  • to_address: Transaction recipient
  • value: Native token amount transferred
  • gas_used: Actual gas consumed
  • gas_price: Price per gas unit
  • tx_fee: Total transaction fee in native tokens
  • block_timestamp: When transaction was included

Sample queries

-- Daily transaction statistics by type
SELECT 
    DATE_TRUNC('day', block_timestamp) AS day,
    tx_type,
    COUNT(*) AS tx_count,
    COUNT(DISTINCT from_address) AS unique_senders,
    SUM(tx_fee) AS total_fees_native,
    AVG(gas_used) AS avg_gas_used,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY gas_price) AS median_gas_price
FROM <blockchain_name>.core.fact_transactions
WHERE block_timestamp >= CURRENT_DATE - 30
GROUP BY 1, 2
ORDER BY 1 DESC, 3 DESC;

-- High-value native token transfers
SELECT 
    tx_hash,
    block_timestamp,
    from_address,
    to_address,
    value,
    tx_fee,
    gas_used * gas_price / 1e9 AS gas_cost_gwei
FROM <blockchain_name>.core.fact_transactions
WHERE value > 0
    AND tx_succeeded
    AND block_timestamp >= CURRENT_DATE - 7
ORDER BY value DESC
LIMIT 100;

-- Smart contract interaction patterns
SELECT 
    to_address,
    origin_function_signature,
    COUNT(*) AS interaction_count,
    COUNT(DISTINCT from_address) AS unique_users,
    SUM(tx_fee) AS total_fees_paid
FROM <blockchain_name>.core.fact_transactions
WHERE to_address IN (SELECT address FROM dim_contracts)
    AND block_timestamp >= CURRENT_DATE - 1
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 50;

Columns

Column NameData TypeDescription
BLOCK_NUMBERNUMBERSequential counter representing the position of a block in the blockchain since genesis (block 0). Key Facts: Immutable once finalized Primary ordering mechanism for blockchain data Increments by 1 for each new block Used as a proxy for time in many analyses Usage in Queries: Important: Block numbers are chain-specific. Block 15000000 on Ethereum ≠ block 15000000 on Polygon.
BLOCK_TIMESTAMPTIMESTAMP_NTZUTC timestamp when the block was produced by validators/miners. Format: TIMESTAMP_NTZ (no timezone) Precision: Second-level accuracy Reliability: Set by block producer Can have minor variations (±15 seconds) Always increasing (newer blocks = later timestamps) Best Practices: Note: Use for time-series analysis, but be aware that block production rates vary by chain.
TX_HASHTEXTUnique 66-character identifier for the transaction. Format: 0x + 64 hexadecimal characters Usage: Primary key for transaction lookups Join key for traces, logs, and token transfers Immutable once confirmed Example: 0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060
FROM_ADDRESSTEXTThe externally-owned account (EOA) or contract address that initiated the transaction. Key Points: Always 42 characters (0x + 40 hex chars) Lowercase normalized in all tables Cannot be NULL for valid transactions For contract creation: sender of creation transaction Common Patterns: EOA → EOA: Simple transfer EOA → Contract: User interaction Contract → Contract: Internal calls (see fact_traces) Known addresses: Exchange hot wallets, protocol deployers Query Examples:
TO_ADDRESSTEXTThe destination address for the transaction - either an EOA or contract address. Special Cases: NULL: Contract creation transaction Contract address: Interacting with smart contract EOA address: Simple transfer or receiving funds Important Patterns: Note: For token transfers, this is the token contract, not the recipient. See eztokentransfers tables for recipient.
ORIGIN_FUNCTION_SIGNATURETEXTFunction signature (first 4 bytes) of the called method. Format: 0x + 8 hex characters Common Signatures: 0xa9059cbb: transfer(address,uint256) 0x095ea7b3: approve(address,uint256) 0x23b872dd: transferFrom(address,address,uint256) Note: NULL for simple transfers or invalid calls
VALUEFLOATAmount of native tokens transferred, in token units (not Wei). Key Points: 0 for most contract interactions >0 for native token transfers or payable functions Already converted from Wei (divided by 1e18) Use value_precise for exact amounts Example Query:
VALUE_PRECISE_RAWTEXTString representation of numeric values preserving exact precision without any adjustments. Format: VARCHAR containing numeric string Purpose: Prevents floating-point precision loss due to snowflake limitations Contains: Raw blockchain values (usually in smallest unit) Example Values: “1000000000000000000” = 1 ETH in Wei “50000000” = 50 USDC (6 decimals) Usage:
VALUE_PRECISETEXTString representation of numeric values adjusted for human readability while maintaining precision. Format: VARCHAR containing decimal string Adjustments: Converted from smallest unit to standard unit Purpose: Human-readable values without precision loss Example Values: “1.0” = 1 ETH (converted from Wei) “50.0” = 50 USDC (converted from 6 decimal places) Best Practices:
TX_FEEFLOATTotal fee paid for transaction execution in native token units. Example: 0.002
TX_FEE_PRECISETEXTExact transaction fee as string to prevent floating-point precision loss. Example: ‘0.002345678901234567’
TX_SUCCEEDEDBOOLEANBoolean indicator of transaction success. Values: TRUE: Transaction executed successfully FALSE: Transaction failed/reverted
TX_TYPENUMBERTransaction envelope type (EIP-2718). Example: 2
NONCENUMBERSequential counter of transactions sent by the from_address. Example: 42
TX_POSITIONNUMBERZero-indexed position of transaction within its block. Insights: Position 0: First transaction in block MEV bots often target early positions Bundle transactions appear consecutively Useful for analyzing transaction ordering
INPUT_DATATEXTEncoded data sent with the transaction, containing function calls and parameters. Example: ‘0xa9059cbb0000000000000000000000001234567890123456789012345678901234567890’
GAS_PRICEFLOATPrice per gas unit in Gwei (1 Gwei = 1e-9 native token). Example: 25
EFFECTIVE_GAS_PRICEFLOATActual price paid per gas unit for EIP-1559 transactions, in Gwei. Example: 23.5
GAS_USEDNUMBERActual gas units consumed by transaction execution. Example: 89234
GAS_LIMITNUMBERMaximum gas units the sender is willing to consume for this transaction. Example: 150000
CUMULATIVE_GAS_USEDNUMBERRunning total of gas consumed by all transactions up to and including this transaction within the block. Example: 1234567
RTEXTR component of ECDSA signature (32 bytes). Example: ‘0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef’
STEXTS component of ECDSA signature (32 bytes). Example: ‘0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890’
VNUMBERRecovery identifier for ECDSA signature. Example: 27
FACT_TRANSACTIONS_IDTEXTPrimary key - unique identifier for each row ensuring data integrity. Format: Usually VARCHAR containing composite key generated using MD5 hash of the relevant columns. Example: MD5(blocknumber, txhash, trace_index) Usage: Deduplication in incremental loads Join operations for data quality checks Troubleshooting specific records Important: Implementation varies by table - check table-specific documentation.
INSERTED_TIMESTAMPTIMESTAMP_NTZUTC timestamp when the record was first added to the Flipside database. Format: TIMESTAMP_NTZ Use Cases: Data freshness monitoring Incremental processing markers Debugging data pipeline issues SLA tracking Query Example:
MODIFIED_TIMESTAMPTIMESTAMP_NTZUTC timestamp of the most recent update to this record. Format: TIMESTAMP_NTZ Triggers for Updates: Data corrections Enrichment additions Reprocessing for accuracy Schema migrations Monitoring Usage: