| 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. |
| CHAIN_ID | TEXT | The unique identifier for the blockchain network (chain) where the block or transaction was recorded. Data type: STRING. On Flow, this value distinguishes between different network deployments (e.g., mainnet, testnet). Used for cross-network analytics and ensuring data integrity when working with multiple environments. Example: ‘flow-mainnet’ or ‘flow-testnet’. |
| PROPOSER | TEXT | The Flow address of the account that proposed the transaction. Data type: STRING. The proposer is responsible for submitting the transaction to the network and paying the proposal fee. This field is used to analyze transaction origination, proposer activity, and fee attribution. Example: ‘0x1cf0e2f2f715450’. Important for understanding transaction lifecycle and participant roles in Flow’s multi-signer model. |
| PAYER | TEXT | The Flow address of the account responsible for paying the transaction fees. Data type: STRING. The payer may be different from the proposer or authorizers. This field is used to analyze fee attribution, sponsorship patterns, and participant roles in Flow’s multi-signer transaction model. Example: ‘0x1cf0e2f2f715450’. Important for understanding who bears the cost of transaction execution. |
| AUTHORIZERS | ARRAY | A list of Flow addresses that authorized the transaction. Data type: ARRAY<STRING> or STRING (comma-separated). Authorizers are accounts whose keys are required to sign the transaction, enabling multi-party authorization. This field is used to analyze participant roles, multi-sig patterns, and access control in Flow’s transaction model. Example: [‘0x1cf0e2f2f715450’, ‘0x2a2e1b2c3d4e5f6’]. Important for understanding transaction security and collaborative workflows. |
| COUNT_AUTHORIZERS | NUMBER | Number of authorizers |
| GAS_LIMIT | NUMBER | The maximum amount of computational resources (gas) allocated for executing the transaction on the Flow blockchain. Data type: INTEGER. If the transaction exceeds this limit, it will fail. This field is used to analyze resource usage, transaction costs, and execution constraints. Example: 1000. Important for understanding transaction execution, fee estimation, and optimizing smart contract operations. |
| SCRIPT | TEXT | The Cadence smart contract code or script executed as part of the transaction. Data type: STRING. This field contains the source code that defines the transaction’s logic, including function calls, arguments, and contract interactions. Used for auditing, debugging, and analyzing smart contract usage on Flow. Example: a Cadence script for transferring tokens. For more details, see Flow Cadence Scripts. |
| ARGUMENTS | ARRAY | The parameters or values passed into the Cadence script when the transaction was submitted. Data type: ARRAY<STRING> or STRING (JSON-encoded). Arguments customize the behavior of the script, enabling dynamic contract interactions. Used for auditing, debugging, and analyzing transaction intent. Example: [‘0x1cf0e2f2f715450’, 100]. Important for understanding how smart contracts are invoked and parameterized on Flow. |
| TRANSACTION_RESULT | OBJECT | The outcome of the transaction execution, including status (success/failure), error messages, and any events emitted. Data type: STRING (JSON-encoded or structured). This field is used to analyze transaction success rates, debug failures, and audit on-chain activity. Example: ‘{"status": "success", "events": [...]}’. Essential for understanding transaction lifecycle, error handling, and event-driven analytics on Flow. |
| TX_SUCCEEDED | BOOLEAN | Transaction status, if it succeeded or failed. |
| ERROR_MSG | TEXT | The error message associated with the transaction, if it failed. |
| FACT_TRANSACTIONS_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 | 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. |
