| TX_ID | TEXT | The unique identifier (hash) for a transaction on the Flow blockchain. Data type: STRING. Each transaction is assigned a cryptographic hash that ensures its uniqueness and immutability. Used for joining transaction data across tables, tracing transaction execution, and verifying transaction integrity. Example: ‘e3f1c2d4…’. Essential for transaction-level analytics, debugging, and cross-referencing with block and event data. |
| BLOCK_TIMESTAMP | TIMESTAMP_NTZ | The timestamp (in UTC) when the block or transaction was recorded on the Flow blockchain. Data type: TIMESTAMP_NTZ. This field is essential for time-series analysis, ordering events, and joining with other tables by time. For example, a block with block_height 100,000 may have a block_timestamp of ‘2023-01-01 12:00:00’. Used for analytics on network activity, transaction throughput, and historical state reconstruction. |
| BLOCK_HEIGHT | NUMBER | Block height is the unique, sequential integer assigned to each block as it is added to the Flow blockchain. It serves as the primary identifier for block ordering and is used to reference the position of a block within the chain. Data type: INTEGER. Block height is essential for joining block, transaction, and event tables, and for analyzing blockchain growth over time. For example, block height 100,000 refers to the 100,000th block produced on Flow. This field is critical for time-series analytics, chain reorganization analysis, and historical state reconstruction. |
| TX_SUCCEEDED | BOOLEAN | Transaction status, if it succeeded or failed. |
| EVENT_INDEX | NUMBER | The zero-based position of the event within the list of events emitted by a transaction. Data type: INTEGER. This field indicates the order in which events occurred during transaction execution. Used for reconstructing event sequences, debugging, and analyzing event-driven workflows. Example: 0 (first event), 1 (second event), etc. Important for event ordering and traceability. |
| EVENT_CONTRACT | TEXT | The Flow contract that emitted the event. Data type: STRING. This value is a concatenation of the contract’s account address and its primary name (e.g., ‘A.0ae53cb6e3f42a79.FlowToken’). Used for identifying the source of events, joining with contract metadata, and analyzing contract activity. Example: ‘A.0ae53cb6e3f42a79.FlowToken’. Equivalent to the ‘Contract’ column on Flowscan. |
| EVENT_TYPE | TEXT | The name or identifier of the event emitted by a contract during transaction execution. Data type: STRING. In the fact_events table, this field represents the user-defined or system event type, such as ‘A.0ae53cb6e3f42a79.FlowToken.TokensDeposited’. Used for filtering, categorizing, and analyzing on-chain events. Example: ‘A.0ae53cb6e3f42a79.FlowToken.TokensWithdrawn’. For more details, see Flow User-Defined Events. |
| EVENT_DATA | OBJECT | The data passed to the event, in the form of key-value pairs. |
| FACT_EVENTS_ID | TEXT | pk_id is a surrogate primary key, uniquely generated for each row in the table. Data type: STRING or INTEGER (implementation-specific). This field ensures every record is uniquely identifiable, even if the source data lacks a natural primary key. Used for efficient joins, deduplication, and as a reference in downstream models. Example: an auto-incremented integer or a UUID string. Essential for maintaining data integrity and supporting dbt tests for uniqueness. |
| _INSERTED_TIMESTAMP | TIMESTAMP_NTZ | |
| INSERTED_TIMESTAMP | TIMESTAMP_NTZ | The UTC timestamp when the record was first created and inserted into this table. Data type: TIMESTAMP_NTZ. Used for ETL auditing, tracking data freshness, and identifying when data was loaded or updated in the analytics pipeline. Example: ‘2023-01-01 12:00:00’. This field is critical for monitoring data latency, troubleshooting ETL issues, and supporting recency tests in dbt. |
| MODIFIED_TIMESTAMP | TIMESTAMP_NTZ | The UTC timestamp when this record was last updated or modified by an internal ETL or dbt process. Data type: TIMESTAMP_NTZ. Used for change tracking, ETL auditing, and identifying the most recent update to a record. Example: ‘2023-01-02 15:30:00’. This field is important for troubleshooting data issues, monitoring pipeline health, and supporting recency or freshness tests in dbt. |