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 Median transaction fee Methodology

## 1. Overview

Median transaction fee is calculated as the median fee paid across all transactions on the TON blockchain, expressed in USD. The typical fee paid by a user is shown, without skew from very high or low values. Base transaction fees are combined with forward message fees to determine the daily median, which is then converted to USD using native TON price feeds.

## 2. Data sources

- **Blockchain events**: Transaction and message records, covering TON
- **External data**: End-of-day price feeds for the native TON asset

## 3. Step-by-step calculation

### Component A: Transaction facts extraction

- **Purpose**: Extraction of core transaction data from the TON blockchain
- **Logic**: All transaction records are retrieved, including transaction hashes, block timestamps, total transaction fees, workchain identifiers, and account information. The base fee component is provided for each transaction.
- **Key fields**: `transaction_hash`, `block_timestamp`, `transaction_fees`, `workchain_id`, `account`

### Component B: Message facts extraction
- **Purpose**: Extraction of message-related fee data from the TON blockchain
- **Logic**: Message records are retrieved, including forward fees, transaction associations, and message direction. Outgoing messages are focused on, as forward fees paid by the transaction initiator are contained within them.
- **Key fields**: `message_hash`, `forward_fee`, `transaction_hash`, `direction`, `block_timestamp`

### Component C: Fee aggregation

- **Purpose**: Combination of transaction fees and forward fees into total transaction costs
- **Logic**: Transaction records are joined with outgoing message records using the transaction hash. For each transaction, all outgoing forward fees are summed and added to the base transaction fee. Cases where transactions have no outgoing messages are handled by treating missing forward fees as zero.
- **Key fields**: `fees`, `transaction_hash`, `timestamp`

### Component D: Median calculation

- **Purpose**: Calculation of the daily median transaction fee in native TON units
- **Logic**: All transaction fees are grouped by day using timestamps truncated to day boundaries. Percentiles are calculated to select the 50th percentile (median) value. Zero fees are handled to ensure no null values are returned.
- **Key fields**: `transaction_fee_median`, `timestamp`

### Component E: USD conversion and aggregation

- **Purpose**: Normalize values by decimal precision and convert to USD
- **Logic**: TON-denominated median fees are normalized by decimal precision. The normalized values are then multiplied by end-of-day native TON price feeds to calculate the USD-denominated median transaction fee. Daily granularity is maintained with UTC day boundaries.
- **Key fields**: `transaction_fee_median`, `timestamp`

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

TONGRAM

Median transaction fee

Median transaction fee

Competitive landscape