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 Average fees per user (AFPU) Methodology

## 1. Overview

Average fees per user (AFPU) is defined as the daily average amount of fees paid per active user on the TON blockchain. The business question of how much the average user pays in transaction fees per day is answered by this metric. Total daily fees (in USD) are divided by the number of active users (daily), providing insight into user engagement cost and network economics.

## 2. Data sources

The AFPU calculation is based on the following raw data sources:

- **TON blockchain transactions**: Complete transaction records from the TON blockchain including transaction hashes, timestamps, sender accounts, transaction fees, and account state information
- **TON blockchain messages**: Message records including forward fees and routing fees for outgoing messages associated with transactions
- **End-of-day price feeds**: Asset price data for the native TON asset to enable USD conversion
- **Known wallet type definitions**: Hardcoded mappings of code hashes to wallet types for user identification

## 3. Step-by-step calculation

### Component A: User identification and active users (daily) counting

- **Purpose**: Identify valid wallet users and count unique active users (daily)
- **Logic**: Valid users are identified by examining TON transaction senders and validating them against known wallet types. Transaction records are filtered to include only accounts whose `account_state_code_hash_after` matches one of 15 predefined wallet code hashes (including Wallet V1R1 through V5R1, Wallet V5 Beta, Wallet Lockup, and various Highload wallet versions). Only transactions where the `transaction_hash` equals the `trace_id` are considered to ensure primary transaction inclusion. Users are classified as "Transaction sender" type with chain set to "ton".
- **Key fields**: `account` (user address), `account_state_code_hash_after` (for wallet validation), `block_timestamp` (for daily aggregation), `transaction_hash` and `trace_id` (for transaction filtering)

### Component B: Active users (daily) aggregation

- **Purpose**: Aggregate unique user counts across different dimensions using efficient counting methods
- **Logic**: Individual user records are aggregated to daily totals to calculate unique active users (daily). Multiple dimension breakdowns are created by the aggregation, including project-level, chain-level, user-type-level, and product-level views. Daily timestamps are truncated to day boundaries for consistent aggregation periods.
- **Key fields**: `user_address` (for unique user counting), `timestamp` (truncated to day), `chain`, `user_type`, `product_id`

### Component C: Transaction fee calculation

- **Purpose**: Calculate total fees including both transaction fees and message forward fees
- **Logic**: Base transaction fees are extracted from TON transaction records and joined with outgoing message data to capture forward fees. For each transaction, the base `transaction_fees` are summed with all associated outgoing `forward_fee` amounts from messages where direction equals "out". Missing forward fees are handled by setting null values to zero before summation.
- **Key fields**: `transaction_fees` (base fees), `forward_fee` (message fees), `direction` (to filter outgoing messages), `workchain_id` (for network segmentation)

### Component D: Fee aggregation and USD conversion

- **Purpose**: Sum daily fees and convert to USD for standardized reporting
- **Logic**: Transaction-level fees are aggregated to daily totals by summing combined transaction and forward fees, grouped by day and workchain. The TON fee amounts are normalized by a decimal precision of 9 and converted to USD using end-of-day price feeds for the native TON asset.
- **Key fields**: `fees` (combined transaction and forward fees), `timestamp` (daily aggregation)

### Final aggregation

- **Combining components**: The final AFPU calculation is performed by dividing the total daily fees (in USD) by the count of active users (daily) using the calculate_arpu macro, which performs the mathematical division while handling edge cases like zero users.
- **Currency conversion**: All fees are converted to USD using end-of-day price feeds for the native TON asset with proper decimal adjustments applied before the division calculation.
- **Time aggregation**: Daily time boundaries (timestamp truncated to day) are used for both fees and user counts to ensure consistent aggregation periods.
- **Final calculation**: The AFPU value is calculated as total daily fees in USD divided by the active users (daily) count, with the result processed through finalize_metric_afpu to apply metadata, handle missing data points with zero-filling, and ensure consistent schema formatting across time periods.

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

TONGRAM

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape