| BLOCKCHAIN | TEXT | The blockchain the record occurred on. See evm.dim_chains for a list of all EVM chains. Format: VARCHAR Example: ‘ethereum’ Usage: Filtering by blockchain Joining across tables Analyzing chain-specific patterns |
| NATIVE_TOKEN | TEXT | The native token symbol for the blockchain. See evm.dim_chains for a list of all EVM chains. Format: VARCHAR Example: ‘ETH’ |
| BLOCK_NUMBER | NUMBER | Sequential 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_TIMESTAMP | TIMESTAMP_NTZ | UTC 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_HASH | TEXT | Unique 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_ADDRESS | TEXT | The 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 evm_facttraces) Known addresses: Exchange hot wallets, protocol deployers Query Examples: |
| TO_ADDRESS | TEXT | The 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 evm_eztoken_transfers tables for recipient. |
| ORIGIN_FUNCTION_SIGNATURE | TEXT | Function 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 |
| VALUE | FLOAT | Amount 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_RAW | TEXT | String 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_PRECISE | TEXT | String 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_FEE | FLOAT | Total fee paid for transaction execution in native token units (the blockchain’s gas token). Example: 0.002 |
| TX_FEE_PRECISE | TEXT | Exact transaction fee as string to prevent floating-point precision loss. Example: ‘0.002345678901234567’ |
| GAS_PRICE | FLOAT | Price per gas unit in Gwei (1 Gwei = 1e-9 native token). Example: 25 |
| GAS_USED | NUMBER | Actual gas units consumed by transaction execution. Example: 89234 |
| GAS_LIMIT | NUMBER | Maximum gas units the sender is willing to consume for this transaction. Example: 150000 |
| TX_SUCCEEDED | BOOLEAN | Boolean indicator of transaction success. Values: TRUE: Transaction executed successfully FALSE: Transaction failed/reverted |
| TX_TYPE | NUMBER | Transaction envelope type (EIP-2718). Example: 2 |
| NONCE | NUMBER | Sequential counter of transactions sent by the from_address. Example: 42 |
| TX_POSITION | NUMBER | Zero-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_DATA | TEXT | Encoded data sent with the transaction, containing function calls and parameters. Example: ‘0xa9059cbb0000000000000000000000001234567890123456789012345678901234567890’ |
| FACT_TRANSACTIONS_ID | TEXT | Primary 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_TIMESTAMP | TIMESTAMP_NTZ | UTC 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_TIMESTAMP | TIMESTAMP_NTZ | UTC 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: |