Validators process transactions and receive fees from users (supply-side fees).

The Open Network (TON) is a smart contract platform for decentralized applications (a blockchain). The Open Network was founded by Telegram and launched in 2019.

GRAM holders own and govern the protocol. They currently take (burn) a cut of the total transaction fees paid by users (revenue). The Open Network's investors include KuCoin Ventures, MEXC Ventures, DWF Labs, etc.

governance

github

twitter

etherscan

website

Blockchains (L1)

# TON Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique addresses that sent at least one transaction on the TON blockchain during a 7-day rolling window period. This metric provides insights into sustained user engagement and network activity trends over time. The calculation uses HyperLogLog sketches for efficient approximate distinct counting across large datasets and creates multiple dimensional breakdowns to analyze user activity patterns.

## 2. Data sources

The calculation relies on the following raw data sources:

- **TON blockchain transaction records**: Complete transaction history from the TON blockchain including sender addresses, transaction hashes, block timestamps, and trace identifiers
- **TON account state data**: Account state information including code hashes after transaction execution, used to identify account types and filter legitimate wallet transactions
- **Known wallet contract registry**: A curated list of code hashes corresponding to legitimate TON wallet contract types (Wallet V1R1 through V5R1, Beta versions, Lockup wallets, and Highload variants)

## 3. Step-by-step calculation

### Component A: Wallet type identification
- **Purpose**: Establishes a registry of legitimate TON wallet contract code hashes to filter user transactions from smart contract operations
- **Logic**: Hardcoded code hashes for known TON wallet types are stored in hex format and converted to base64 encoding. This includes standard wallet versions (V1R1, V1R2, V1R3, V2R1, V2R2, V3R1, V3R2, V4R1, V4R2, V5R1, V5 Beta), specialized wallets (Lockup), and high-throughput wallets (Highload V1R1, V1R2, V2R1, V2R2). The code hashes are sourced from TON documentation and known contract repositories.
- **Key fields**: `code_hash_hex` (original hex format), `code_hash_base64` (converted format for matching), `account_type` (wallet type description)

### Component B: User transaction filtering
- **Purpose**: Identifies legitimate user transactions by filtering TON blockchain transactions to include only those sent from known wallet contract types
- **Logic**: All TON transactions are joined with the wallet type registry using the account's code hash after transaction execution (`account_state_code_hash_after`). Only transactions where the sending account matches a known wallet code hash are retained. Additional filtering ensures only primary transactions are counted by matching `transaction_hash` with `trace_id`. Each qualifying transaction contributes the sender address as a user activity record.
- **Key fields**: `block_timestamp` (transaction timing), `transaction_hash` (unique transaction identifier), `account` (sender address), `user_address` (standardized user identifier), `user_type` (set to "Transaction sender"), `chain` (set to "ton")

### Component C: Daily active user aggregation  
- **Purpose**: Aggregates filtered user transactions into daily distinct user counts using HyperLogLog sketches for efficient processing
- **Logic**: User transactions are grouped by day using timestamp truncation to create daily boundaries. Within each day, distinct user addresses are counted and converted to HyperLogLog sketches using `hll_count.init()` with 15-bit precision. This creates compressed representations of daily user sets that can be efficiently merged for window calculations. Grouping includes dimensions for chain, user type, and product identification.
- **Key fields**: `timestamp` (daily boundary), `timestamp_grain` (set to "day"), `chain` (blockchain identifier), `user_type` (user classification), `product_id` (product identifier), `user_dau` (user address for distinct counting)

### Component D: Rolling window construction
- **Purpose**: Creates 7-day rolling windows for calculating weekly active users from daily data points
- **Logic**: A datespine generates all calendar days from the earliest available data to the current date. For each target date, a 7-day window is constructed by generating timestamps for the 6 preceding days plus the target date itself. This creates "joinday" records that map each target date to its constituent window days. The DAU HLL sketches are then joined to each window day, creating a dataset where each target date has associated HLL sketches for all 7 days in its window.
- **Key fields**: `timestamp` (target date for WAU calculation), `joinday` (individual days within the 7-day window), `hll` (daily HLL sketches for user counts)

### Component E: Dimensional breakdowns
- **Purpose**: Calculates WAU across different analytical dimensions to support various reporting needs
- **Logic**: Four separate breakdowns are created by grouping the windowed data differently. The project-level breakdown aggregates all data regardless of other dimensions. The chain-level breakdown groups by `chain_id`. The user-type breakdown groups by `user_type`. The product-level breakdown groups by `product_id`. For each breakdown, HLL sketches within the 7-day window are merged using `hll_count.merge_partial()` and then extracted to approximate distinct counts using `hll_count.extract()`. Unused dimension fields are set to NULL using `safe_cast()`.
- **Key fields**: `dimensions` (breakdown type identifier), `user_wau` (weekly active user count), dimension-specific fields (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: The four dimensional breakdowns are combined using `union all` operations to create a comprehensive dataset with multiple analytical perspectives in a single table
- **Currency conversion**: No currency conversion is required as this metric counts users rather than monetary values
- **Time aggregation**: The metric maintains daily granularity with each date representing the WAU for the 7-day window ending on that date
- **Final calculation**: The `finalize_metric_user_wau` macro standardizes the output format, applies the TON data identifier, and fills missing dates with zero values to ensure complete time series continuity. Incremental processing includes lookback periods to handle data updates and ensures data freshness while maintaining performance.

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

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

TONGRAM

Active users (weekly)

Active users (weekly)

Competitive landscape