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 addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that have initiated at least one transaction on the Tron blockchain within a rolling 7-day window. This metric serves as a proxy for user engagement and network activity on Tron. The calculation uses HyperLogLog sketches for efficient approximate counting of unique addresses over sliding weekly periods.

## 2. Data sources

- **Tron transaction records**: Raw transaction data from the Tron blockchain containing transaction hashes, sender addresses, recipient addresses, and block timestamps
- **Transaction metadata**: Block timestamps and transaction identifiers for temporal aggregation and deduplication

## 3. Step-by-step calculation

### Component A: User identification
- **Purpose**: Identify unique user addresses from transaction activity
- **Logic**: Extract sender addresses (`from_address`) from all Tron blockchain transactions. Each transaction sender is classified as a "Transaction sender" user type and associated with the Tron chain. The model captures block timestamps for temporal analysis and assigns metadata including market sector as "blockchains_l1" and business segment as "blockchain".
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for uniqueness, `from_address` as the user identifier, and `user_type` classification

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily unique active users as the foundation for weekly calculations
- **Logic**: Aggregate transaction senders to daily granularity by truncating `block_timestamp` to day boundaries. Take distinct user addresses per calendar day to count unique daily active users. Filter and partition data incrementally to handle large transaction volumes efficiently.
- **Key fields**: `timestamp` truncated to day, `user_address` for uniqueness, `chain` for network identification

### Component C: Weekly active user calculation via HyperLogLog
- **Purpose**: Calculate 7-day rolling window unique user counts using probabilistic data structures
- **Logic**: Initialize HyperLogLog sketches for each day's unique users to enable efficient approximate counting. Create a complete datespine covering all days to ensure continuous time coverage. Generate 7-day rolling windows by creating jointables that map each target day to its preceding 6 days plus itself. For each day in the window, merge the daily HyperLogLog sketches using `hll_count.merge_partial()` to combine unique user estimates. Extract the final approximate unique count using `hll_count.extract()`. Break down results by multiple dimensions: project level (project_dbt_tag), chain level, user type level, and product level.
- **Key fields**: `timestamp` for window boundaries, `hll` sketches for probabilistic counting, `user_wau` as the extracted unique count

### Final aggregation
- **Combining components**: The weekly active addresses metric directly maps the weekly active user counts to active addresses, since users are identified by their unique addresses on the blockchain
- **Currency conversion**: No currency conversion required as this is a count-based metric
- **Time aggregation**: Uses 7-day rolling windows where each day represents the count of unique addresses active in that day plus the preceding 6 days
- **Final calculation**: Filter results to include only chain-level and project-level dimensions, then apply the finalization macro to standardize the schema and fill any missing days with zero values. The `user_wau` field becomes `active_addresses_weekly` through direct mapping since blockchain users are inherently identified by their addresses.

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

Unique active addresses over a rolling 7-day window.

TronTRX

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape