Validators process transactions and receive validator rewards. Super representatives and super representative partners receive voting rewards. TRX stakers receive energy and bandwidth incentives.

Tron is a smart contract platform for decentralized applications (a blockchain). Tron was founded by Justin Sun and launched in 2018.

TRX holders own and govern the protocol. They currently burn all transaction fees paid by users (revenue). It is important to note that the incentives related to energy and bandwidth are effectively returned as revenue, and this is reflected in the earnings.

governance

github

twitter

discord

etherscan

website

Blockchains (L1)

Tron

# Tron Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for TRON measures the number of unique addresses that sent at least one transaction on the TRON blockchain within any rolling 7-day period. This metric answers the business question "How many distinct users are actively transacting on TRON each week?" The calculation uses HyperLogLog approximation algorithms for memory-efficient distinct counting across rolling time windows, providing multiple dimensional breakdowns for comprehensive analysis.

## 2. Data sources

The calculation relies on the following raw data sources:

- **TRON transaction records**: Complete transaction history from the TRON blockchain containing sender addresses, timestamps, and transaction metadata
- **Incremental processing metadata**: Table modification timestamps used to optimize data processing and ensure freshness

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Identifies all unique users who sent transactions on TRON and classifies them with relevant metadata
- **Logic**: Extracts sender addresses from TRON blockchain transaction records using the `from_address` field. Each transaction sender is classified as a "Transaction sender" user type. All users are categorized under the "blockchains_l1" market sector and "blockchain" business segment, with `product_id` set to null since this tracks general blockchain usage rather than specific protocol activity.
- **Key fields**: `from_address` (user address), `block_timestamp` (transaction time), `user_type` (always "Transaction sender"), `chain` (always "tron")

### Component B: Daily active user aggregation
- **Purpose**: Aggregates unique user addresses on a daily basis to create daily active user counts
- **Logic**: Groups transaction sender addresses by day using timestamp truncation to day granularity. Creates distinct user counts for each day along with associated metadata including chain identifier, user type classification, and business categorization. Implements incremental processing with configurable lookback periods to ensure data freshness while maintaining efficiency.
- **Key fields**: `timestamp` (day-truncated date), `user_address` (unique daily users), `timestamp_grain` (always "day"), `chain` (blockchain identifier)

### Component C: HyperLogLog sketch initialization
- **Purpose**: Converts daily user sets into memory-efficient HyperLogLog sketches for approximate distinct counting
- **Logic**: Transforms daily active user data into HLL sketches using BigQuery's `hll_count.init` function with precision parameter 15. Groups by timestamp, chain, user type, and product dimensions to maintain proper aggregation boundaries. This approach enables efficient distinct user counting across time windows without memory constraints.
- **Key fields**: `hll` (HyperLogLog sketch), grouped by timestamp and dimensional attributes

### Component D: Rolling window construction
- **Purpose**: Creates complete date coverage and establishes 7-day rolling windows for WAU calculation
- **Logic**: Generates a datespine covering all days from the earliest data through yesterday to ensure no missing dates. For each date in the spine, creates a 7-day lookback period by generating timestamps from 6 days prior through the current date. This joinday mechanism establishes the rolling window structure needed for WAU calculation while handling missing data gracefully.
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 7-day window)

### Component E: Window aggregation and HLL merging
- **Purpose**: Merges HLL sketches across 7-day periods to calculate distinct user counts for each rolling window
- **Logic**: Joins the rolling window structure with daily HLL sketches, matching on the joinday dates. For each target timestamp, collects all HLL sketches from the 7-day period and merges them using BigQuery's `hll_count.merge_partial` function. Extracts the final distinct count using `hll_count.extract` to produce the weekly active user count for each date and dimension combination.
- **Key fields**: `user_wau` (weekly distinct user count), maintained across all dimensional groupings

### Component F: Dimensional breakdowns
- **Purpose**: Creates multiple analytical perspectives by aggregating WAU across different dimensional hierarchies
- **Logic**: Generates four distinct dimensional breakdowns: project-level (aggregated across all dimensions), chain-level (grouped by blockchain), user-type level (grouped by user classification), and product-level (grouped by product identifier). Each breakdown uses appropriate grouping and sets unused dimensions to null values. All breakdowns use the same HLL merging logic but with different aggregation boundaries.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type` with appropriate nullification

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive result set with multiple analytical perspectives in a single output table
- **Currency conversion**: Not applicable - this metric counts users rather than monetary values
- **Time aggregation**: Uses rolling 7-day windows where each date represents the count of distinct users active in that day plus the 6 preceding days, providing smooth trending without traditional weekly boundaries
- **Final calculation**: The final metric value represents the approximate count of distinct TRON addresses that sent at least one transaction within any 7-day rolling period, calculated using HyperLogLog approximation algorithms and presented across multiple dimensional breakdowns with missing dates filled as zeros

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Unique revenue-generating users over a rolling 7-day window.

TronTRX

Active users (weekly)

Active users (weekly)

Competitive landscape