| PROGRAM_ID | TEXT | The unique public key (base58-encoded address) of a Solana program. This field identifies the on-chain program (smart contract) responsible for processing instructions, emitting events, or managing accounts. Used throughout Solana analytics models—including events, transactions, IDLs, and program activity tables—to join, filter, and analyze program-level data. Example: “4Nd1mY…” “TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA” Business Context: Used as a join key for program activity, deployme… |
| IDL | VARIANT | The Interface Definition Language (IDL) document for the Solana program, typically in JSON format. Defines the program’s instructions, accounts, and types, enabling clients and analytics tools to interact with the program in a standardized way. Example: JSON object describing program instructions and accounts |
| IDL_HASH | TEXT | The deployed hash of the program IDL |
| IS_VALID | BOOLEAN | Boolean flag indicating whether the IDL is valid and conforms to expected structure and standards. TRUE means the IDL is valid and usable; FALSE indicates errors or incompatibility. Example: true false |
| IS_ACTIVE | BOOLEAN | Boolean flag indicating whether the program has had decoded instructions or activity within a recent time window (e.g., last 14 days). TRUE means the program is active; FALSE means it is dormant or inactive. Example: true false |
| LAST_ACTIVITY_TIMESTAMP | TIMESTAMP_LTZ | The UTC timestamp of the most recent decoded instruction or activity for this program. Used to track program usage, recency, and engagement. Example: “2024-05-01 12:34:56” |
| SUBMITTED_BY | TEXT | The identifier (e.g., address or username) of the entity or user who submitted the IDL for this program. Used for attribution, auditing, and developer analytics. Example: “7G8h…” “devuser123” |
| DATE_SUBMITTED | TIMESTAMP_NTZ | The UTC date and time when the IDL was submitted for this program. Used for tracking submission recency, program upgrades, and developer activity. Example: “2024-05-01 12:34:56” Business Context: Enables submission recency analysis, upgrade tracking, and developer engagement monitoring. |
| FIRST_BLOCK_ID | NUMBER | The block ID (slot number) of the first block in which this program or IDL was observed. Used to track program deployment and interface introduction on-chain. Example: 12345678 Business Context: Supports deployment analysis, program lifecycle tracking, and historical analytics. |
| EARLIEST_DECODED_BLOCK | NUMBER | The block ID (slot number) of the earliest block for which decoded instructions are available for this program. Used to track the start of program activity and analytics coverage. Example: 12345679 Business Context: Enables analytics on program activity start, coverage, and completeness. |
| BACKFILL_STATUS | TEXT | A status indicator describing whether historical data for this program or IDL has been fully backfilled. Common values: ‘complete’, ‘inprogress’, ‘notstarted’. Example: “complete” “inprogress” “notstarted” Business Context: Supports data completeness checks, ETL monitoring, and analytics on historical coverage. |
| DIM_IDLS_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. |