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 Supply-side fees Methodology

## 1. Overview

HMX supply-side fees represent the portion of trading-related fees that are distributed to HLP (HMX Liquidity Pool) liquidity providers rather than retained as protocol revenue. This metric aggregates three types of fees generated from perpetual trading activities on HMX: borrowing fees for holding leveraged positions, liquidation fees from position liquidations, and trading fees from opening and closing positions. The calculation applies time-based revenue percentage splits to determine what portion of total fees flows to liquidity providers versus the protocol.

## 2. Data sources

The calculation relies on the following data sources:
- **Blockchain events**: Parsed Arbitrum event logs from HMX's TradeHelper contract, specifically `LogSettleBorrowingFeeValue`, `LogSettleLiquidationFeeValue`, and `LogSettleTradingFeeValue` events that capture fee settlement activities
- **Protocol configuration**: Hardcoded revenue percentage splits that define how fees are divided between protocol revenue and liquidity provider rewards, with different percentages for each fee type and changes over time

## 3. Step-by-step calculation

### Component A: Borrowing fees collection
- **Purpose**: Captures fees charged to traders for holding leveraged positions over time
- **Logic**: Extracts data from Arbitrum `LogSettleBorrowingFeeValue` events emitted by HMX's TradeHelper contract. Each event represents a borrowing fee settlement for a specific account. The `feeUsd` field contains the fee amount in USD but stored with 30 decimal places, so values are divided by 10^30 to convert to standard USD amounts. Events are deduplicated using transaction hash and log index.
- **Key fields**: `feeUsd` (fee amount in 30 decimals), `address` (account being charged), `block_timestamp` (when fee was settled)

### Component B: Liquidation fees collection  
- **Purpose**: Captures fees generated when leveraged positions are liquidated due to insufficient margin
- **Logic**: Extracts data from Arbitrum `LogSettleLiquidationFeeValue` events from HMX's TradeHelper contract. Each event represents a liquidation fee charged when a position is forcibly closed. The `usd` field contains the fee amount in USD with 30 decimal places, converted to standard USD by dividing by 10^30. Events are deduplicated to avoid double-counting.
- **Key fields**: `usd` (fee amount in 30 decimals), `address` (liquidated account), `block_timestamp` (liquidation timestamp)

### Component C: Trading fees collection
- **Purpose**: Captures fees charged when traders open or close perpetual positions
- **Logic**: Extracts data from Arbitrum `LogSettleTradingFeeValue` events from HMX's TradeHelper contract. Each event represents a trading fee charged for position changes. The `feeUsd` field contains the fee amount in USD with 30 decimal places, converted by dividing by 10^30. Events are deduplicated using transaction hash and log index.
- **Key fields**: `feeUsd` (fee amount in 30 decimals), `address` (trading account), `block_timestamp` (trade timestamp)

### Component D: Revenue percentage splits
- **Purpose**: Defines what portion of each fee type goes to protocol revenue versus liquidity providers
- **Logic**: Uses hardcoded configuration with two key dates: June 22, 2023 (borrowing: 10% revenue, liquidation: 100% revenue, trading: 10% revenue) and August 10, 2023 (borrowing: 10% revenue, liquidation: 100% revenue, trading: 35% revenue). Missing dates are forward-filled using the most recent percentage values. These percentages represent the protocol's revenue share, with the remainder going to liquidity providers.
- **Key fields**: `borrowing_revenue_percentage`, `liquidation_revenue_percentage`, `trading_revenue_percentage` (all as decimal values)

### Final aggregation
- **Combining components**: Each fee type is joined with the revenue percentage table using daily truncated timestamps to match fees with the appropriate percentage splits active on that date
- **Supply-side calculation**: For each fee type, supply-side fees are calculated as: fee_amount × (1 - revenue_percentage). This gives the portion that flows to liquidity providers rather than protocol revenue
- **Time aggregation**: All fees are aggregated to daily boundaries using timestamp truncation to the day level
- **Final calculation**: The three fee streams (borrowing, liquidation, and trading supply-side fees) are combined using union operations, then processed through standardization macros to ensure consistent formatting and zero-filling for missing dates

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

Portion of fees distributed to service providers or supply-side participants.

HMXHMX

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown