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

## 1. Overview

The TON active addresses daily metric measures the number of unique wallet addresses that initiated at least one transaction on the TON blockchain within a given day. This metric serves as a key indicator of daily user activity and network adoption on TON. The calculation identifies legitimate user wallets by matching transaction sender addresses against known wallet code hash patterns, filtering out smart contracts and other non-user account types.

## 2. Data sources

The metric relies on two primary data sources:

- **TON blockchain transaction records**: Complete transaction data from the TON blockchain including transaction hashes, sender addresses, block timestamps, account state information, and account code hashes after transaction execution
- **Predefined wallet type mappings**: Hardcoded definitions mapping specific code hashes to known wallet types including Wallet V1R1 through V5R1, Highload wallet variants (V1R1, V1R2, V2R1, V2R2), Wallet V5 Beta, and Wallet Lockup implementations

## 3. Step-by-step calculation

### Component A: Wallet type identification
- **Purpose**: Define legitimate user wallet types to distinguish from smart contracts and other account types
- **Logic**: Create a reference table mapping known wallet code hashes to wallet type names. The system includes 14 different wallet implementations covering standard wallets (V1R1 through V5R1), high-load wallets for frequent transactions (V1R1, V1R2, V2R1, V2R2), beta implementations (V5 Beta), and lockup wallets. Code hashes are converted from hexadecimal to base64 format to match the format used in transaction records.
- **Key fields**: `code_hash_hex` (original hex format), `code_hash_base64` (converted format for matching), `account_type` (wallet type name)

### Component B: Transaction filtering and user identification  
- **Purpose**: Extract valid user transactions by matching sender accounts against known wallet types
- **Logic**: Join transaction records with the wallet type reference table on the account code hash after transaction execution. Filter to include only transactions where the transaction hash equals the trace ID to avoid counting internal or child transactions multiple times. Extract the transaction timestamp, hash, sender address, and classify each sender as a transaction sender user type.
- **Key fields**: `block_timestamp` (transaction time), `transaction_hash` (unique transaction identifier), `account` (sender address), `account_state_code_hash_after` (account code hash for wallet type matching)

### Component C: Daily user aggregation
- **Purpose**: Count unique active addresses per day from the filtered transaction data
- **Logic**: Truncate transaction timestamps to daily boundaries and group by day. Extract distinct user addresses within each day to count unique active addresses. Apply incremental processing logic to only process recent data for efficiency, looking back a configurable number of days from the last processed partition.
- **Key fields**: `timestamp` (daily boundary), `user_address` (unique sender addresses), `chain` (blockchain identifier), `user_type` (classification as transaction sender)

### Component D: HyperLogLog aggregation across dimensions
- **Purpose**: Aggregate unique user counts across different analytical dimensions while handling potential overlaps
- **Logic**: Apply HyperLogLog probabilistic counting algorithm with 15-bit precision to create sketches of unique users for each day. Merge HyperLogLog sketches across multiple dimensional breakdowns including project level (all TON activity), chain level (TON-specific), user type level (transaction senders), and product level (currently null for TON). Extract final counts from merged sketches to produce accurate unique address counts even with overlapping data.
- **Key fields**: `hll` (HyperLogLog sketch), `user_dau` (extracted unique user count), `dimensions` (analytical dimension type), `chain_id` (chain identifier), `user_type` (user classification)

### Final aggregation
- **Combining components**: Extract the daily active user count from the HyperLogLog aggregation where the dimension type is either 'chain' or 'project_dbt_tag' and rename the `user_dau` field to `active_addresses_daily`
- **Currency conversion**: Not applicable - this is a count metric measuring number of addresses
- **Time aggregation**: Data is aggregated to daily boundaries using day-level timestamp truncation 
- **Final calculation**: The final metric value is the count of unique addresses that sent at least one transaction from a known wallet type on each day, calculated using HyperLogLog probabilistic counting to ensure accuracy across dimensional aggregations. Missing days are filled with zero values and chain availability filters are applied to ensure data quality.

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

Unique active addresses over a fixed 24-hour window.

TONGRAM

Active addresses (daily)

Active addresses (daily)

Competitive landscape