Skip to main content
Schema: tron.core Table: dim_labels Type: Base Table

​
What

The labels table is a dimension table that maps Tron addresses to recognizable entities, protocols, and wallet types. Labels are categorized into types (cex, dex, defi, etc.) and subtypes (hot_wallet, treasury, etc.) to enable entity-based analysis.

​
Key Use Cases

  • Track centralized exchange flows (deposits, withdrawals, hot/cold wallet movements)
  • Analyze DeFi protocol usage on Tron (JustLend, SunSwap, etc.)
  • Monitor whale and institutional wallet activities
  • Identify token contracts and their movements
  • Assess labeling coverage for active addresses

​
Important Relationships

  • Join with fact_transactions: Use address to identify exchange flows and protocol usage
  • Join with ez_token_transfers: Use address to track token movements by entity type (especially USDT flows)
  • Join with ez_native_transfers: Use address to track TRX movements by entity
  • Join with dim_contracts: Combine with contract metadata for labeled contracts

​
Commonly-used Fields

  • address: 0x-prefixed hex address, primary join key
  • label_type: High-level category (cex, dex, defi, token, etc.)
  • label_subtype: Specific categorization within type (hot_wallet, pool, etc.)
  • label: Protocol or entity name (renamed from project_name)
  • address_name: Most specific, granular label

​
Sample Queries

-- CEX inflow/outflow analysis
WITH cex_addresses AS (
    SELECT DISTINCT address
    FROM tron.core.dim_labels
    WHERE label_type = 'cex'
        AND label_subtype IN ('hot_wallet', 'deposit')
)
SELECT
    DATE_TRUNC('day', t.block_timestamp) AS day,
    CASE
        WHEN t.to_address IN (SELECT address FROM cex_addresses) THEN 'CEX Inflow'
        WHEN t.from_address IN (SELECT address FROM cex_addresses) THEN 'CEX Outflow'
    END AS flow_direction,
    COUNT(*) AS transaction_count
FROM tron.core.fact_transactions t
WHERE (t.to_address IN (SELECT address FROM cex_addresses)
       OR t.from_address IN (SELECT address FROM cex_addresses))
    AND t.block_timestamp >= CURRENT_DATE - 30
GROUP BY 1, 2
ORDER BY 1 DESC;

-- Top labeled protocols by transaction count
SELECT
    l.label,
    l.label_type,
    COUNT(*) AS total_interactions
FROM tron.core.fact_transactions t
JOIN tron.core.dim_labels l ON t.to_address = l.address
WHERE l.label_type IN ('defi', 'dex')
    AND t.block_timestamp >= CURRENT_DATE - 7
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 20;

​
Columns

Column NameData TypeDescription
BLOCKCHAINTEXTThe blockchain network for this label. Always ‘tron’ in this table. Example: ‘tron’
CREATORTEXTThe source or creator of this label entry. Labels from verified sources may be more reliable. Example: ‘flipside’
ADDRESSTEXTThe Tron address in 0x-prefixed hex format. Primary join key for matching with transaction and transfer tables. Example: ‘0xa614f803b6fd780986a42c78ec9c7f77e6ded13c’
ADDRESS_NAMETEXTThe most specific, granular label for this address. Provides maximum detail for precise identification. Example: ‘Binance 14’
LABEL_TYPETEXTHigh-level category describing the address’s primary function. Core types include cex, dex, defi, token, nft, bridge, games, whale, and institution. Example: ‘cex’
LABEL_SUBTYPETEXTSpecific categorization within the label type. Used for detailed filtering within broader categories. Example: ‘hot_wallet’
LABELTEXTHigh-level label identifying the general entity or wallet type. Renamed from project_name. Often combines the protocol name with wallet function. Example: ‘Binance Hot Wallet’
DIM_LABELS_IDTEXTPrimary key — unique identifier for each row ensuring data integrity. Format: VARCHAR containing composite key generated using MD5 hash of the relevant columns. Usage: Deduplication in incremental loads Join operations for data quality checks Troubleshooting specific records
INSERTED_TIMESTAMPTIMESTAMP_NTZUTC timestamp when the record was first added to the Flipside database. Format: TIMESTAMP_NTZ Use Cases: Data freshness monitoring Incremental processing markers Debugging data pipeline issues
MODIFIED_TIMESTAMPTIMESTAMP_NTZUTC timestamp of the most recent update to this record. Format: TIMESTAMP_NTZ Use Cases: Tracking data corrections and reprocessing Monitoring incremental model updates Data quality audits