Network Revenue via Fees

Hedera’s revenue is calculated by summing the total transaction fees collected across the mainnet. Every transaction pays fees to various recipients: consensus nodes, the staking account (0.0.800), the node rewards account (0.0.801), and the Hedera treasury (0.0.98). By examining each transaction, determining the total fee paid, and identifying which portions go to these accounts, Hedera can determine its total network revenue. This total can then be categorized by service type—Hedera Token Service (HTS), Hedera Smart Contract Service (HSCS), Hedera Consensus Service (HCS), and Other (including file and account operations)—to provide a detailed breakdown of revenue sources.

Hedera Data Access

To access this Hedera network statistic (and others) via Hgraph's GraphQL & REST APIs, get started here.

Methodology

Transaction-Level Fee Analysis

Every transaction submitted to the Hedera mainnet incurs certain fees, which are distributed to various recipients:

• Consensus Nodes: Nodes that reach consensus on the order of transactions and earn a portion of the transaction fee.
• Staking Account (0.0.800): An account designated for staking rewards. A portion of the fee goes here.
• Node Reward Account (0.0.801): An account designated for rewarding all active consensus nodes. A portion of the fee goes here.
• Hedera Treasury (0.0.98): The central treasury account on the network. Another portion of the fee is directed here.

Note: While these recipients exist, the SQL implementation only sums total transaction fees and does not break down how much of each fee goes to each specific account.

Data Inputs

To calculate revenue at a high level, we only need to know the total fees charged per transaction. The distribution to each account can be derived from other data sources or additional queries, but is not part of the SQL function shown below.

Calculating Total Revenue

This is the sum of charged_tx_fee across all transactions. Conceptually, you can think of it as:

Total Revenue (HBAR) = Σ (Transaction Fees going to Consensus Nodes 
                         + Transaction Fees going to Staking Account 
                         + Transaction Fees going to Hedera Treasury 
                         + Transaction Fees going to Node Rewards)

In other words, for each transaction:

• Identify the total fee charged.
• Extract the portions of that fee allocated to consensus nodes, the staking account, and the treasury.
• Sum all such portions across all transactions to get the total revenue.

Breaking Down by Service Type

Hedera offers multiple services, and transactions can be grouped based on the type of service they utilize:

• HTS (Hedera Token Service): Revenue from fees associated with token operations (creation, transfers, minting, etc.).
• HSCS (Hedera Smart Contract Service): Revenue from fees tied to smart contract operations (creation, calls, updates).
• HCS (Hedera Consensus Service): Revenue from fees generated by consensus message submissions.
• Crypto Service: Crypto related transactions.
• Other Services: Revenue from all other transaction types.

Important: The SQL function below does not categorize fees by transaction type. If you need the breakdown of total revenue by service type, you’ll need an additional query or post-processing step that segments transactions accordingly.

Use Case Example

Network revenue serves as a proxy for overall transaction volume and network adoption, indicating that a healthy network sees consistent fee generation from active use. Sudden fluctuations in this metric can quickly alert operators to potential performance issues or shifts in user behavior.

GraphQL API Examples

Test out these queries using our developer playground.

Note: The results for total are stored in tinybar (devide by 100,000,000).

Fetch total revenue for the last 24hrs

query RevenueLast24hrs {
  metric: ecosystem_metric_aggregate(
    where: {name: {_eq: "network_fee"}}
    order_by: {end_date: desc_nulls_last}
    limit: 24
  ) {
    aggregate {
      sum {
        total
      }
    }
  }
}

Fetch hourly revenue (timeseries)

query HourlyNetworkRevenue {
  metric: ecosystem_metric(
    order_by: {end_date: desc_nulls_last}
    limit: 8760
    where: {name: {_eq: "transaction_fees"}, period: {_eq: "hour"}}
  ) {
    total
    end_date
  }
}

7 day percentage change (period comparison)

query Change7Days {
  current: ecosystem_metric_aggregate(
    where: {name: {_eq: "network_fee"}, period: {_eq: "hour"}}
    order_by: {start_date: desc_nulls_last}
    limit: 168
  ) {
    aggregate {
      sum {
        total
      }
    }
  }
  previous: ecosystem_metric_aggregate(
    where: {name: {_eq: "network_fee"}, period: {_eq: "hour"}}
    order_by: {start_date: desc_nulls_last}
    offset: 168
    limit: 168
  ) {
    aggregate {
      sum {
        total
      }
    }
  }
}

# Percent Change = ((current - previous) / previous) * 100

Available Time Periods

• hour

SQL Implementation

Below is a link to the Hedera Stats GitHub repository. The repo contains the SQL function that calculates the Network Revenue statistic outlined in this methodology.

SQL Function: ecosystem.dashboard_network_fee

View GitHub Repository →

Dependencies

• Hedera mirror node