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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Tron measures the number of unique addresses that sent at least one transaction on the Tron blockchain within any rolling 30-day period. This metric answers the question "How many distinct users were active on Tron during each month?" and uses a rolling window approach rather than calendar months to provide more consistent and responsive tracking of user engagement trends.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Tron blockchain transaction records**: Complete transaction history including sender addresses (`from_address`), transaction hashes, and block timestamps
- **Table edit cache metadata**: Internal tracking data used for incremental processing optimization

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identifies unique transaction senders per day as the foundation for MAU calculation
- **Logic**: Extracts all transaction records from Tron blockchain data and identifies the sender address (`from_address`) for each transaction. Groups transactions by day (using `timestamp_trunc` to day granularity) and takes distinct sender addresses per day. Each sender is classified as user type "Transaction sender" and associated with chain identifier "tron", market sector "blockchains_l1", and business segment "blockchain". Product ID remains null for Tron transactions.
- **Key fields**: `block_timestamp` (transaction timing), `from_address` (user identifier), `transaction_hash` (unique transaction reference), `user_type` (classification as transaction sender)

### Component B: HyperLogLog initialization
- **Purpose**: Converts daily user lists into memory-efficient data structures for large-scale distinct counting
- **Logic**: Takes the daily active user data and applies HyperLogLog initialization with precision parameter 15 to each day's user set. Groups by timestamp, chain, user type, and product ID. This creates compressed representations of user sets that can be efficiently merged across time periods without storing individual addresses.
- **Key fields**: `hll` (HyperLogLog data structure), `timestamp` (day identifier), `chain_id` (blockchain identifier), `user_type` (user classification)

### Component C: Date spine creation
- **Purpose**: Ensures complete time series coverage without gaps in the rolling window calculation
- **Logic**: Generates a complete sequence of daily timestamps from the earliest available data through the current date minus one day. Uses BigQuery's `generate_timestamp_array` function with 1-day intervals. For incremental processing, the start date is adjusted to include a safety margin of 29 days plus additional lookback days before the last modified timestamp.
- **Key fields**: `timestamp` (complete daily sequence)

### Component D: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for each date to capture monthly active user periods
- **Logic**: For each date in the date spine, generates a 30-day window spanning from 29 days before that date through the date itself (inclusive). Uses cross-join with `generate_timestamp_array` to create all date pairs. Joins this window data with the HyperLogLog daily data to connect each date with all its relevant historical days within the 30-day lookback period.
- **Key fields**: `timestamp` (target date), `joinday` (individual days within the 30-day window), `hll` (daily user data for aggregation)

### Component E: Dimensional breakdown aggregation
- **Purpose**: Calculates MAU across different analytical dimensions for flexible reporting
- **Logic**: Creates four separate dimensional views of the MAU data:
  1. **Project level**: Overall MAU across all Tron activity (nullifies chain, product, and user type dimensions)
  2. **Chain level**: MAU broken down by blockchain (maintains chain_id, nullifies product and user type)  
  3. **User type level**: MAU by user classification (maintains user_type, nullifies chain and product)
  4. **Product level**: MAU by product identifier (maintains product_id, nullifies chain and user type)

Each breakdown merges HyperLogLog structures across the dimensional groupings and extracts the final distinct count using `hll_count.extract` function.

### Final aggregation
- **Combining components**: Unions all four dimensional breakdowns using `UNION ALL` to create a comprehensive result set with multiple analytical perspectives in a single table
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows anchored on each date, providing daily MAU values that represent unique users active in the preceding 30 days including the current date
- **Final calculation**: Applies the `finalize_metric_user_mau` macro to standardize the schema, add metadata fields like data_id ("tron"), and fill any missing time periods with zero values using the 'fill_zeros' strategy. For incremental runs, filters results to only include dates within the processing window based on table modification timestamps.

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

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

TronTRX

Active users (monthly)

Active users (monthly)

Competitive landscape