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

## 1. Overview

The TON active addresses weekly metric measures the number of unique wallet addresses that initiated at least one transaction during a rolling 7-day period on the TON blockchain. This metric uses a rolling window approach, where each day reports the count of unique addresses that were active in that day plus the previous 6 days. The calculation specifically focuses on transactions sent from known TON wallet contract types to distinguish actual user activity from contract-to-contract interactions.

## 2. Data sources

The metric relies on the following raw data sources:
- **TON blockchain transaction data**: Complete transaction records from the TON blockchain including sender addresses, transaction hashes, block timestamps, and account state information
- **Known wallet contract specifications**: Predefined code hashes for recognized TON wallet contract types, covering standard wallet versions (V1R1 through V5R1), specialized wallet types (Highload V1R1, V1R2, V2R1, V2R2), and other wallet variants (Lockup, V5 Beta)
- **Account state data**: Post-transaction account state information including code hashes that identify the contract type of sending addresses

## 3. Step-by-step calculation

### Component A: Wallet type identification
- **Purpose**: Establishes a reference of known TON wallet contract types to filter user transactions from contract interactions
- **Logic**: A comprehensive list of known TON wallet contract types is maintained using specific code hashes. These include standard wallet versions from V1R1 through V5R1, specialized Highload wallets (V1R1, V1R2, V2R1, V2R2), and other variants like Lockup and V5 Beta wallets. The code hashes are stored in hexadecimal format and converted to base64 format for matching against blockchain data
- **Key fields**: `account_type` (wallet version name), `code_hash_hex` (hexadecimal code hash), `code_hash_base64` (base64 converted code hash for matching)

### Component B: User transaction filtering  
- **Purpose**: Identifies transactions sent by actual user wallets rather than contract-to-contract interactions
- **Logic**: TON blockchain transaction data is filtered to include only transactions where the sending address corresponds to a known wallet type. This is achieved by matching the `account_state_code_hash_after` field from transaction records against the base64 code hashes of known wallet types. Only trace root transactions are included (where `transaction_hash` equals `trace_id`) to avoid counting internal transaction traces multiple times
- **Key fields**: `block_timestamp` (transaction timing), `transaction_hash` (unique transaction identifier), `account` (sender address), `account_state_code_hash_after` (code hash for wallet type matching)

### Component C: Daily active user calculation
- **Purpose**: Aggregates unique user addresses that were active each day
- **Logic**: Transaction data is grouped by day using timestamp truncation, and distinct sender addresses are counted for each day. Each record represents a unique combination of day, chain, user type, and user address. The user type is classified as "Transaction sender" to distinguish from other potential user classifications
- **Key fields**: `timestamp` (day-level timestamp), `chain` (blockchain identifier), `user_type` (classification as transaction sender), `user_address` (unique wallet address)

### Component D: Weekly aggregation with HyperLogLog
- **Purpose**: Calculates weekly active users using a rolling 7-day window with efficient deduplication
- **Logic**: Daily active user data is processed through HyperLogLog sketches to enable efficient deduplication across rolling time windows. A datespine is generated to ensure all days are represented, even those with no activity. For each day, a 7-day rolling window is created by joining the current day with the previous 6 days. HyperLogLog sketches are created for each day's unique users, then merged across the 7-day window to count distinct users without double-counting addresses active on multiple days within the window
- **Key fields**: `timestamp` (daily timestamp), `hll` (HyperLogLog sketch for user deduplication), `user_wau` (weekly active users count extracted from merged HyperLogLog sketches)

### Final aggregation
- **Combining components**: The weekly active users calculation produces counts broken down by different dimensions (chain-level, project-level, user type, product ID). For the active addresses weekly metric, only chain-level and project-level breakdowns are selected
- **Currency conversion**: Not applicable for this count-based metric
- **Time aggregation**: The metric uses a rolling 7-day window where each day reports the count of unique addresses active in that day plus the previous 6 days. This creates a smoothed weekly trend that updates daily
- **Final calculation**: The `user_wau` field is renamed to `active_addresses_weekly` and processed through finalization macros that standardize the schema and fill missing periods with zeros to ensure a continuous time series

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

Unique active addresses over a rolling 7-day window.

TONGRAM

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape