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 Revenue Methodology

## 1. Overview

HMX revenue represents the protocol's share of fees generated from perpetual trading activities on the HMX decentralized derivatives exchange. The metric captures revenue that flows to HMX token stakers and the development team from three fee types: borrowing fees, liquidation fees, and trading fees. Revenue is calculated by applying time-based percentage splits to total fees collected, reflecting changes in the protocol's revenue sharing model over time.

## 2. Data sources

- **HMX TradeHelper contract events**: Parsed event logs from HMX's TradeHelper contract deployed on Arbitrum, specifically the `LogSettleBorrowingFeeValue_event`, `LogSettleLiquidationFeeValue_event`, and `LogSettleTradingFeeValue_event` emissions
- **Smart contract fee data**: USD-denominated fee amounts embedded directly in the contract events with 30-decimal precision, eliminating the need for external price conversion
- **Protocol configuration data**: Hardcoded revenue percentage splits that define how fees are divided between the protocol and liquidity providers

## 3. Step-by-step calculation

### Component A: Borrowing fee revenue
- **Purpose**: Calculates protocol revenue from borrowing fees charged to perpetual trading positions
- **Logic**: Extracts borrowing fee settlement events from the HMX TradeHelper contract on Arbitrum. Each event contains the `feeUsd` field representing the borrowing fee in USD with 30-decimal precision. The fee amount is converted to standard decimal format by dividing by 10 to the power of 30. Revenue is calculated by multiplying the borrowing fee amount by the applicable borrowing revenue percentage for that day (10% throughout the protocol's history).
- **Key fields**: `block_timestamp` for daily aggregation, `address` for the account being charged, `feeUsd` for the raw fee amount, and transaction details for deduplication

### Component B: Liquidation fee revenue  
- **Purpose**: Calculates protocol revenue from liquidation fees collected when positions are liquidated
- **Logic**: Extracts liquidation fee settlement events from the HMX TradeHelper contract on Arbitrum. Each event contains the `usd` field representing the liquidation fee in USD with 30-decimal precision. The fee amount is converted to standard decimal format by dividing by 10 to the power of 30. Revenue is calculated by multiplying the liquidation fee amount by the liquidation revenue percentage (100% throughout the protocol's history, meaning all liquidation fees go to the protocol).
- **Key fields**: `block_timestamp` for daily aggregation, `address` for the liquidated account, `usd` for the raw fee amount, and transaction details for deduplication

### Component C: Trading fee revenue
- **Purpose**: Calculates protocol revenue from trading fees charged on perpetual trading transactions
- **Logic**: Extracts trading fee settlement events from the HMX TradeHelper contract on Arbitrum. Each event contains the `feeUsd` field representing the trading fee in USD with 30-decimal precision. The fee amount is converted to standard decimal format by dividing by 10 to the power of 30. Revenue is calculated by multiplying the trading fee amount by the applicable trading revenue percentage for that day. The trading revenue percentage was 10% from protocol launch (June 22, 2023) until August 10, 2023, when it increased to 35%.
- **Key fields**: `block_timestamp` for daily aggregation, `address` for the trading account, `feeUsd` for the raw fee amount, and transaction details for deduplication

### Component D: Revenue percentage configuration
- **Purpose**: Applies time-based revenue splits to determine the protocol's share of each fee type
- **Logic**: Uses a hardcoded configuration table that defines revenue percentage splits by date. The configuration includes three percentage fields: borrowing revenue percentage (10%), liquidation revenue percentage (100%), and trading revenue percentage (10% before August 10, 2023, then 35%). These percentages are forward-filled across all days to ensure every day has appropriate revenue split values. The percentages represent the portion of total fees that constitute protocol revenue versus liquidity provider compensation.
- **Key fields**: `timestamp` for date-based lookups, `borrowing_revenue_percentage`, `liquidation_revenue_percentage`, and `trading_revenue_percentage` for the respective fee type splits

### Final aggregation
- **Combining components**: All three fee revenue components are combined using union operations, with each component joined to the revenue percentage configuration based on the transaction date. The revenue calculation multiplies each fee amount by its corresponding revenue percentage to isolate the protocol's share.
- **Currency conversion**: No currency conversion is required as all fee amounts are already denominated in USD within the smart contract events with 30-decimal precision, which is converted to standard decimal format.
- **Time aggregation**: All transactions are aggregated to daily boundaries using timestamp truncation to the day level. Days without any fee activity are filled with zeros to maintain complete time series data.
- **Final calculation**: The final revenue metric represents the sum of all protocol revenue from borrowing fees, liquidation fees, and trading fees for each day, calculated as the total of (borrowing_fee_amount × borrowing_revenue_percentage) + (liquidation_fee_amount × liquidation_revenue_percentage) + (trading_fee_amount × trading_revenue_percentage) for all transactions within each day.

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

HMXHMX

Revenue

Revenue

Competitive landscape

Chain breakdown