Skip to main content
Schema: solana.core Table: dim_idls Type: View

​
Description

This table contains one row per program interface definition (IDL) on the Solana blockchain, but only includes programs for which we have the IDL and are actively decoding instructions. Programs listed here are the only ones for which decoded data is available in downstream models. It maps program IDs to their Interface Definition Language (IDL) documents, hashes, validity, activity status, and submission metadata. Each row represents a unique program interface definition, supporting analytics on program interfaces, upgrades, and developer activity.

​
Key Use Cases

  • Analyze program interface definitions and upgrades
  • Track program activity, validity, and deployment status
  • Support analytics on developer activity and protocol upgrades
  • Study program adoption, composability, and ecosystem growth
  • Enable time-series and event-based analytics on program interfaces

​
Important Relationships

  • Closely related to core.fact_decoded_instructions and core.ez_events_decoded (for decoded program calls)
  • Use core.ez_events_decoded to analyze program calls and usage

​
Commonly-used Fields

  • program_id: For program identification and joins
  • idl, idl_hash: For interface definition and verification
  • is_valid, is_active: For program status analytics
  • last_activity_timestamp, date_submitted: For activity and submission analysis

​
Columns

Column NameData TypeDescription
PROGRAM_IDTEXTThe 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, deployments, events, and interface changes.
  • Supports segmentation of activity by protocol, DEX, NFT marketplace, or other on-chain application. | | 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…”
  • “dev_user_123” | | 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’, ‘in_progress’, ‘not_started’.
Example:
  • “complete”
  • “in_progress”
  • “not_started”
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. |