Skip to main content
Schema: flow.core Table: dim_labels Type: View

Description

This table provides a comprehensive mapping of Flow addresses to human-readable labels, supporting entity identification and classification across the blockchain. Each row represents a unique address and its associated label, with additional metadata such as label type, subtype, and creator. Labels are sourced from both automated algorithms and manual curation, enabling robust address classification for analytics and reporting. The table is continuously updated to reflect new addresses, protocol deployments, and community contributions.

Key Use Cases

  • Enriching transaction, event, and contract data with human-readable labels for dashboards and analytics
  • Segmenting addresses by type (e.g., CEX, DEX, dApp, game) and subtype (e.g., contract_deployer, hot_wallet)
  • Supporting compliance, risk analysis, and wallet attribution
  • Powering entity-level analytics for DeFi, NFT, and governance applications

Important Relationships

  • Can be joined to core.fact_transactions, core.fact_events, and other gold models via address for entity enrichment
  • Used by curated models in DeFi, NFT, and rewards domains to provide address context and segmentation
  • Label type and subtype fields enable advanced filtering and grouping in analytics workflows

Commonly-used Fields

  • address: The Flow blockchain address being labeled
  • label: The human-readable name or tag for the address
  • label_type: The primary category of the address (e.g., CEX, NFT, DeFi)
  • label_subtype: The secondary classification (e.g., hot_wallet, validator)
  • creator: The source or contributor of the label

Columns

Column NameData TypeDescription
BLOCKCHAINTEXTThe name of the blockchain network involved in the transaction or address. Data type: STRING. This field is used to distinguish between different blockchains (e.g., ‘flow’, ‘ethereum’, ‘polygon’) in cross-chain analytics, bridge activity, and multi-chain protocols. It is essential for filtering, aggregating, and attributing activity to the correct network, especially in bridge and DeFi models where assets may move between chains. Example: ‘flow’ for native Flow transactions, ‘ethereum’ for bridged assets. Important for cross-chain analytics, protocol attribution, and ensuring accurate data segmentation in multi-chain environments.
CREATORTEXTThe source of the labeling information for the address.
ADDRESSTEXTThe unique on-chain address representing an account or contract on the Flow blockchain. Data type: STRING. Addresses are used to identify participants, contracts, and assets in all Flow transactions and events. Example: ‘0x1cf0e2f2f715450’. Used for joins, analytics, and entity mapping. For more details, see Flow Accounts and Addresses.
ADDRESS_NAMETEXTThe name for a specific address, like Kraken or Huobi for CEX, or consensus vs verification for validator.
LABEL_TYPETEXTThe primary category or classification assigned to an address, contract, or entity (e.g., ‘CEX’, ‘Operator’, ‘NFT’, ‘DeFi’, ‘Game’). Data type: STRING. Used for grouping, filtering, and analyzing entities by type in dashboards and reports. Example: ‘CEX’ for centralized exchanges, ‘NFT’ for non-fungible token contracts. Important for segmentation and entity-level analytics.
LABEL_SUBTYPETEXTA more granular classification within the primary label_type, specifying the role or function of the address or contract (e.g., ‘hot wallet’, ‘deposit wallet’, ‘validator’, ‘marketplace’). Data type: STRING. Used for detailed segmentation, filtering, and analytics. Example: ‘hot wallet’ under ‘CEX’, or ‘validator’ under ‘Operator’. Important for fine-grained entity analysis and reporting.
LABELTEXTA human-readable name or tag assigned to an address, contract, or entity for identification and analytics. Data type: STRING. Labels provide context such as project names, exchange names, or protocol identifiers. Used for dashboards, segmentation, and entity-level reporting. Example: ‘Blocto’, ‘NBA Top Shot’, ‘Flow Foundation’. Important for making blockchain data more interpretable and actionable.
DIM_LABELS_IDTEXTA unique identifier for the record. In the context of blocks, this is the block hash—a cryptographic string that uniquely identifies a block on the Flow blockchain. Data type: STRING. Used for verifying block integrity, referencing blocks in other tables, and supporting chain reorganization analysis. Example: ‘a1b2c3d4…’. For other models, ‘id’ may refer to a unique row identifier.
INSERTED_TIMESTAMPTIMESTAMP_NTZThe UTC timestamp when the record was first created and inserted into this table. Data type: TIMESTAMP_NTZ. Used for ETL auditing, tracking data freshness, and identifying when data was loaded or updated in the analytics pipeline. Example: ‘2023-01-01 12:00:00’. This field is critical for monitoring data latency, troubleshooting ETL issues, and supporting recency tests in dbt.
MODIFIED_TIMESTAMPTIMESTAMP_NTZThe UTC timestamp when this record was last updated or modified by an internal ETL or dbt process. Data type: TIMESTAMP_NTZ. Used for change tracking, ETL auditing, and identifying the most recent update to a record. Example: ‘2023-01-02 15:30:00’. This field is important for troubleshooting data issues, monitoring pipeline health, and supporting recency or freshness tests in dbt.