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

View DBT Documentation

View the complete technical documentation and data lineage for this table

​
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.
IDLVARIANTThe 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.
IDL_HASHTEXTThe deployed hash of the program IDL
IS_VALIDBOOLEANBoolean 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.
IS_ACTIVEBOOLEANBoolean 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.
LAST_ACTIVITY_TIMESTAMPTIMESTAMP_LTZThe UTC timestamp of the most recent decoded instruction or activity for this program. Used to track program usage, recency, and engagement.
SUBMITTED_BYTEXTThe 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.
DATE_SUBMITTEDTIMESTAMP_NTZThe UTC date and time when the IDL was submitted for this program. Used for tracking submission recency, program upgrades, and developer activity.
FIRST_BLOCK_IDNUMBERThe 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.
EARLIEST_DECODED_BLOCKNUMBERThe 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.
BACKFILL_STATUSTEXTA status indicator describing whether historical data for this program or IDL has been fully backfilled. Common values: ‘complete’, ‘in_progress’, ‘not_started’.
DIM_IDLS_IDTEXTA 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_TIMESTAMPTIMESTAMP_NTZThe 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_TIMESTAMPTIMESTAMP_NTZThe 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.

​
Column Details

​
PROGRAM_ID

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

Example:
  • JSON object describing program instructions and accounts

​
IS_VALID

Example:
  • true
  • false

​
IS_ACTIVE

Example:
  • true
  • false

​
LAST_ACTIVITY_TIMESTAMP

Example:
  • “2024-05-01 12:34:56”

​
SUBMITTED_BY

Example:
  • “7G8h…”
  • “dev_user_123”

​
DATE_SUBMITTED

Example:
  • “2024-05-01 12:34:56”
Business Context:
  • Enables submission recency analysis, upgrade tracking, and developer engagement monitoring.

​
FIRST_BLOCK_ID

Example:
  • 12345678
Business Context:
  • Supports deployment analysis, program lifecycle tracking, and historical analytics.

​
EARLIEST_DECODED_BLOCK

Example:
  • 12345679
Business Context:
  • Enables analytics on program activity start, coverage, and completeness.

​
BACKFILL_STATUS

Example:
  • “complete”
  • “in_progress”
  • “not_started”
Business Context:
  • Supports data completeness checks, ETL monitoring, and analytics on historical coverage.