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 revenue per user (ARPU) Methodology

## 1. Overview

Average revenue per user (ARPU) measures the average daily revenue generated per active user on the TON blockchain. The metric is calculated by dividing daily revenue by active users (daily). Insight is provided into the economic value generated per user from transaction fees on the TON network. TON's unique fee structure is incorporated, and a key business rule is implemented where 50% of transaction fees are considered as burned (and thus revenue) starting from June 17, 2023.

## 2. Data sources

- **Revenue**: Derived from the Revenue metric
- **Active users (daily)**: Derived from the Active users (daily) metric

## 3. Step-by-step calculation

### Component A: Fee collection and aggregation

- **Purpose**: Calculate total fees paid per transaction including both base transaction fees and message forward fees
- **Logic**: TON transactions are extracted and joined with outgoing message data to capture forward fees. For each transaction, the base `transaction_fees` is summed with all `forward_fee` amounts from outgoing messages. Fees are grouped by transaction hash to obtain total fees per transaction. Standard transaction processing fees and additional fees for message routing across the network are both included in the calculation.
- **Key fields**: `transaction_fees`, `forward_fee`, `transaction_hash`, `block_timestamp`, `workchain_id`

### Component B: Revenue calculation with burn mechanism

- **Purpose**: Convert fees to USD and apply TON's fee burn mechanism to determine actual revenue
- **Logic**: Aggregated fees are normalized by decimal precision and converted to USD using the end-of-day market price of the native TON asset. A critical business rule starting on June 17, 2023, is implemented: 50% of all transaction fees are burned, which is classified as protocol revenue. For dates prior to June 17, 2023, revenue is set to zero. For dates on or after June 17, 2023, revenue is calculated as 50% of total fees in USD.
- **Key fields**: `fees`, `timestamp`, `revenue`

### Component C: User identification and classification

- **Purpose**: Identify legitimate user wallets from transaction activity using known wallet type signatures
- **Logic**: Transaction sender addresses are extracted from TON transaction records. These addresses are filtered to only include known wallet types by matching the `account_state_code_hash_after` field against a predefined list of wallet code hashes. Wallet types including various versions from Wallet V1R1 through V5R1, Beta versions, Lockup wallets, and Highload wallet variants are supported. Only root transactions where the `transaction_hash` equals the `trace_id` are included to avoid double-counting internal transactions. Genuine user wallets are counted while smart contracts and other non-user accounts are excluded by this filtering.
- **Key fields**: `account`, `account_state_code_hash_after`, `transaction_hash`, `trace_id`, `block_timestamp`

### Component D: Daily active user aggregation

- **Purpose**: Count distinct active users (daily)
- **Logic**: Identified user addresses are grouped by day to determine distinct active users (daily). Users are aggregated across different dimensions including the overall project level, chain, user type, and product. The project-level total user count is utilized as the primary aggregation for the average revenue per user calculation.
- **Key fields**: `user_address`, `timestamp`, `user_dau`

### Component E: Final aggregation

- **Purpose**: Calculate the average revenue per user by dividing daily revenue by active users (daily)
- **Logic**: Daily revenue and active users (daily) are aligned by timestamp. The average revenue per user is calculated by dividing daily revenue by the daily active user count. Zero-filling is applied for dates where either component is missing to maintain a complete time series.
- **Key fields**: `revenue`, `user_dau`, `arpu`

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

TONGRAM

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape