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

## 1. Overview

Monthly active addresses for TON measures the number of unique wallet addresses that conducted at least one transaction during any 30-day rolling window within each month. This metric treats active users as active addresses, which is standard practice for blockchain analytics. The calculation uses HyperLogLog algorithms for efficient unique address counting across large transaction volumes and implements 30-day rolling windows to capture sustained user activity patterns.

## 2. Data sources

- **TON blockchain transactions**: Complete transaction records from the TON blockchain, including transaction metadata, sender addresses, and account state information
- **Wallet type classifications**: Hardcoded code hashes for known TON wallet types including standard wallets (V1R1 through V5R1, V5 Beta), specialized wallets (Lockup, Highload V1-V2 variants)
- **Account state data**: Post-transaction account state information including code hashes used for wallet type identification
- **Daily timestamp boundaries**: Date spine data for creating consistent daily and monthly time boundaries

## 3. Step-by-step calculation

### Component A: Wallet type identification
- **Purpose**: Classify TON addresses by wallet type to focus on genuine user wallets rather than smart contracts or system accounts
- **Logic**: Define known wallet types using hardcoded code hashes for different TON wallet versions. These include standard wallets from V1R1 through V5R1, V5 Beta versions, Lockup wallets, and Highload wallet variants (V1R1, V1R2, V2R1, V2R2). Convert code hashes from hexadecimal to base64 format to match the format used in transaction data. This creates a lookup table of legitimate wallet code hashes.
- **Key fields**: `code_hash_hex` (original hexadecimal code hash), `code_hash_base64` (converted format for matching), `account_type` (human-readable wallet version name)

### Component B: User transaction identification  
- **Purpose**: Extract user addresses from TON transactions, filtering to only include transactions from known wallet types
- **Logic**: Join TON transaction records with the known wallet types lookup table, matching the `account_state_code_hash_after` field from transactions against `code_hash_base64` from wallet types. This ensures only transactions from legitimate user wallets are included, excluding smart contracts and system accounts. Filter to only include transactions where the `transaction_hash` equals the `trace_id` to get top-level transactions. Extract the transaction sender address as the user address and classify them as "Transaction sender" user type.
- **Key fields**: `block_timestamp` (transaction timing), `transaction_hash` (unique transaction identifier), `account` (sender address), `user_address` (cleaned sender address), `chain` (set to "ton")

### Component C: Daily active user aggregation
- **Purpose**: Count unique user addresses per day to create daily active user metrics
- **Logic**: Group user transactions by day using timestamp truncation to daily boundaries. Count distinct user addresses per day to create daily active user (DAU) counts. Maintain chain, user type, and product ID dimensions for downstream aggregation flexibility.
- **Key fields**: `timestamp` (daily boundary), `timestamp_grain` (set to "day"), `user_dau` (unique user address per day)

### Component D: Monthly active user calculation via rolling windows
- **Purpose**: Calculate 30-day rolling monthly active users using efficient probabilistic counting
- **Logic**: Initialize HyperLogLog sketches for each day's unique users to enable efficient approximate counting. Create a date spine covering all possible days from the earliest transaction date to current date. For each day, generate a 30-day lookback window (current day plus previous 29 days). Join the date spine with daily HLL sketches to create windows that capture all user activity over each 30-day period. Merge HLL sketches within each 30-day window and extract the approximate unique user count. This creates a 30-day rolling monthly active user metric for each day.
- **Key fields**: `timestamp` (daily boundary), `hll` (HyperLogLog sketch of daily users), `user_mau` (30-day rolling unique user count)

### Component E: Dimensional breakdown aggregation
- **Purpose**: Calculate monthly active users across multiple analytical dimensions
- **Logic**: Aggregate the 30-day rolling MAU data across four key dimensions. For chain-level analysis, group by chain ID while nullifying other dimensions. For project-level analysis, aggregate across all dimensions to get total project MAU. For user type analysis, group by user type classification. For product analysis, group by product ID (though this is null for TON). Each dimensional breakdown uses HLL merge operations to combine sketches and extract unique user counts.
- **Key fields**: `dimensions` (analytical dimension type), `chain_id` (for chain-level breakdown), `user_type` (for user type breakdown), `product_id` (for product breakdown)

### Final aggregation
- **Combining components**: Select monthly active user data specifically for chain-level and project-level dimensions, filtering where `dimensions` equals 'chain' or 'project_dbt_tag'
- **Address conversion**: Rename the `user_mau` field to `active_addresses_monthly` to reflect that active users are treated as active addresses in blockchain analytics
- **Time aggregation**: Apply monthly timestamp boundaries and implement zero-filling strategy for months with no activity to ensure consistent time series data
- **Final calculation**: The final metric represents the count of unique addresses that conducted at least one transaction within any 30-day rolling window during each month, calculated using HyperLogLog approximation algorithms for scalable unique counting

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

Unique addresses active over a rolling 30-day window.

TONGRAM

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape