Skip to main content
Schema: solana.core Table: dim_labels Type: View Contains one row per labeled address or entity on the Solana blockchain. This table maps Solana addresses to human-readable labels, label types, subtypes, creators, and project names, supporting entity resolution, attribution, and analytics. Labels are classified by type (e.g., cex, dex, dapp, games) and subtype (e.g., contract_deployer, hot_wallet, token_contract) to enable granular segmentation and analysis. Data is sourced from a combination of automated algorithms, manual curation, protocol APIs, and community submissions. Automatic labels are generated based on on-chain behavior, contract deployments, and protocol integrations, while manual and community labels capture new protocols, exchange wallets, and trending addresses. All labels are reviewed for accuracy and can be updated or removed as needed. This model supports analytics on protocol adoption, ecosystem mapping, and address attribution for Solana.

​
Columns

Column NameData TypeDescription
BLOCKCHAINTEXTThe name of the blockchain network to which the labeled address or entity belongs. For this model, the value is always ‘solana’.
Example:
  • “solana”
Business Context:
  • Enables multi-chain analytics and filtering.
  • Used as a join key in cross-chain models. | | CREATOR | TEXT | The identifier (e.g., address or username) of the entity or user who created the label for this address. Used for attribution, auditing, and analytics on label provenance.
Example:
  • “7G8h…”
  • “labeler_001”
Business Context:
  • Supports label attribution, auditability, and analytics on label creation activity. | | ADDRESS | TEXT | The base58-encoded Solana address (public key) being labeled. Used to join with transaction, account, and program tables for entity resolution and analytics.
Example:
  • “4Nd1mY…”
Business Context:
  • Enables address-level analytics, entity resolution, and attribution.
  • Used as a join key for linking labels to on-chain activity. | | LABEL_TYPE | TEXT | A high-level category describing the main function or ownership of the labeled address (e.g., ‘defi’, ‘nft’, ‘cex’, ‘dapp’). Used for grouping, filtering, and analytics on address types.
Example:
  • “defi”
  • “nft”
  • “cex”
Business Context:
  • Supports segmentation, filtering, and analytics by address type. | | LABEL_SUBTYPE | TEXT | A sub-category nested within label_type, providing further detail about the labeled address (e.g., ‘amm’, ‘marketplace’, ‘bridge’). Used for more granular segmentation and analytics.
Example:
  • “amm”
  • “marketplace”
  • “bridge”
Business Context:
  • Enables fine-grained analytics and filtering by address subtype. | | LABEL | TEXT | The human-readable label or project name associated with the address. Used for entity attribution, analytics, and display in dashboards or explorers.
Example:
  • “Orca”
  • “Magic Eden”
Business Context:
  • Supports attribution, search, and analytics on labeled entities. | | ADDRESS_NAME | TEXT | A human-readable name or alias for the address, if available. Used for display, search, and analytics on labeled addresses.
Example:
  • “Orca Treasury”
  • “ME Marketplace”
Business Context:
  • Enables user-friendly display, search, and analytics on addresses. | | DIM_LABELS_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. |