| BLOCK_ID | NUMBER | A 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. 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 ‘blockid’ s… |
| BLOCK_TIMESTAMP | TIMESTAMP_NTZ | The 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). |
| NETWORK | TEXT | The name of the Solana network from which this block was sourced. Common values include ‘mainnet-beta’, ‘testnet’, or ‘devnet’. Used to distinguish between different Solana environments and support multi-network analytics. Example: “mainnet-beta” “testnet” Business Context: Enables filtering and analysis by network environment. Important for cross-network comparisons and testnet/mainnet separation. |
| CHAIN_ID | TEXT | A static identifier for the Solana blockchain. This value is always ‘solana’ for Solana-native tables and is used to support joins with cross-chain analytics tables. Example: “solana” Business Context: Supports cross-chain analytics and integrations. Used as a join key in multi-chain models. |
| BLOCK_HEIGHT | VARIANT | The height (slot number) of this block in the Solana blockchain. Block height is a sequential integer that increases with each new block and is used to order blocks chronologically. Example: 12345678 Business Context: Used for block ordering, chain growth analysis, and fork resolution. Important for time-series and historical analytics. |
| BLOCK_HASH | TEXT | The cryptographic hash of this block, as recorded on the Solana blockchain. Used to verify block integrity and support block explorer lookups. This value is a base58-encoded string. Example: “5h3k…9zQ” Business Context: Used for block verification, deduplication, and explorer integrations. Supports chain integrity and auditability. |
| PREVIOUS_BLOCK_ID | VARIANT | The block ID (slot number) of the previous block in the Solana blockchain. Used to establish block lineage and support chain traversal. Example: 12345677 Business Context: Enables block-to-block navigation and fork analysis. Important for reconstructing chain history. |
| PREVIOUS_BLOCK_HASH | TEXT | The cryptographic hash of the previous block in the Solana blockchain. Used to verify chain continuity and support block explorer lookups. This value is a base58-encoded string. Example: “4g2j…8yP” Business Context: Supports chain integrity, fork resolution, and auditability. Used for block explorer navigation and verification. |
| FACT_BLOCKS_ID | TEXT | A 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_TIMESTAMP | TIMESTAMP_NTZ | The 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_TIMESTAMP | TIMESTAMP_NTZ | The 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. |