Liquidity providers deposit funds into HMX and receive trading fees from traders (supply-side fees).

HMX is a non-custodial exchange for perpetual contracts built on Arbitrum. HMX was founded by Shu Wei, Rockman, and Taoree and was launched in 2022.

HMX tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). HMX's investors include Coral DeFi, Compound Capital Partners, Cryptomind, etc.

github

twitter

discord

etherscan

website

Derivative exchanges

# HMX Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the daily average fee revenue generated per active trader on the HMX derivatives protocol. This metric answers the business question: "How much fee revenue does each active user generate on average per day?" The calculation divides total daily fees by the number of daily active users, providing insight into user monetization and fee generation efficiency.

## 2. Data sources

- **Arbitrum event logs**: Parsed events from HMX protocol smart contracts on Arbitrum, specifically `LogSettleBorrowingFeeValue`, `LogSettleLiquidationFeeValue`, and `LogSettleTradingFeeValue` events from the TradeHelper contract
- **Trading activity events**: Parsed `LogIncreasePosition` and `LogDecreasePosition` events from the HMX TradeService contract on Arbitrum to identify active traders
- **Revenue split configuration**: Time-based configuration data defining how fees are split between protocol revenue and liquidity provider rewards, with changes occurring on specific dates (2023-06-22 and 2023-08-10)

## 3. Step-by-step calculation

### Component A: Fee extraction and processing
- **Purpose**: Extract and normalize fee data from three distinct fee types in HMX's perpetual trading system
- **Logic**: Parse borrowing fee events that capture costs for holding leveraged positions, liquidation fee events from forced position closures, and trading fee events from opening/closing positions. Convert all fee amounts from 30-decimal precision to standard decimal format by dividing by 10^30. Each event includes the `account_address` of the fee payer, transaction details, and USD-denominated fee amounts (`feeUsd` or `usd` fields)
- **Key fields**: `block_timestamp` for timing, `account_address` for user identification, fee amount fields (`borrowing_fee_amount`, `liquidation_fee_amount`, `trading_fee_amount`) after decimal conversion

### Component B: Revenue percentage application
- **Purpose**: Split total fees between protocol revenue and supply-side rewards based on configurable time-based percentages
- **Logic**: Apply different revenue percentages for each fee type based on the transaction date. Borrowing fees: 10% to protocol revenue, 90% to liquidity providers. Liquidation fees: 100% to protocol revenue, 0% to liquidity providers. Trading fees: 10% to protocol revenue initially (from 2023-06-22), then 35% to protocol revenue starting 2023-08-10. Use forward-fill logic to apply the most recent percentage configuration to each day
- **Key fields**: `borrowing_revenue_percentage`, `liquidation_revenue_percentage`, `trading_revenue_percentage` applied based on transaction timestamp

### Component C: Daily active user calculation
- **Purpose**: Identify and count unique active traders per day using HyperLogLog for efficient distinct counting
- **Logic**: Extract trader addresses from position increase and decrease events on Arbitrum. Each event contains a `primaryAccount` field identifying the trader. Truncate timestamps to daily boundaries and apply HyperLogLog initialization and merging to count distinct users efficiently across different dimensional breakdowns (total, by chain, by user type, by product)
- **Key fields**: `user_address` (from `primaryAccount`), `block_timestamp` truncated to day, `user_type` set to 'Trader'

### Component D: Total fees aggregation
- **Purpose**: Combine protocol revenue and supply-side fees to calculate total daily fee volume
- **Logic**: Union the revenue portion of all fees with the supply-side portion of all fees. For each fee type and date, calculate both protocol revenue (fee amount × revenue percentage) and supply-side fees (fee amount × (1 - revenue percentage)). Group by daily timestamp and sum all fee components to get total daily fees
- **Key fields**: `timestamp` at day level, `fees` representing total combined fee amount

### Final aggregation
- **Combining components**: Join the total daily fees with daily active user counts on the same timestamp (day level)
- **Currency conversion**: No additional currency conversion needed as fees are already in USD from the blockchain events
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, with HyperLogLog aggregation ensuring accurate distinct user counting
- **Final calculation**: Divide total daily fees by the daily active user count using the calculate_arpu macro, which performs the division operation (fees ÷ daily_active_users). Apply fill_zeros strategy to populate days with no activity with zero values rather than null values

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

HMXHMX

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape