Felix issues feUSD and USDhl and deploys perpetual markets under the flx namespace on Hyperliquid's HyperCore order book.

Felix combines stablecoin issuance with USDC-settled perpetual contracts on equities, commodities, indices, and crypto.

Felix is a protocol and product suite on Hyperliquid that spans stablecoins and HIP-3 perpetual markets.

twitter

website

github

discord

Derivative exchanges

Felix

# Felix Revenue Methodology

## 1. Overview

Revenue measures the portion of trading fees retained by Felix across the protocol's perpetual markets. These earnings are represented by the protocol's share of transaction fees generated from trade executions, before operating expenses or token incentives are deducted. By capturing the realized deployer fees from perpetual contract fills, the direct economic value captured by the protocol is quantified. All revenue is collected in Hyper USD and utilized to evaluate the financial performance of the protocol.

## 2. Data sources

- **Blockchain events**: `node_fills` events from `hypercore` contracts, covering Hyperliquid
- **External data**: End-of-day price feeds for Hyper USD

## 3. Step-by-step calculation

### Component A: Perpetual trade fill extraction

- **Purpose**: Identify and extract trade fills executed across the protocol's perpetual markets
- **Logic**: Trade fill events are parsed from `node_fills` events on the Hyperliquid chain. Transactions are filtered to isolate Felix perpetual markets by identifying assets carrying the specific protocol prefix. Only trade fills settled in Hyper USD are included in the dataset.
- **Key fields**: `coin`, `fee_token`, `fee`, `deployer_fee`

### Component B: Protocol revenue calculation

- **Purpose**: Determine the protocol's share of fees from each trade fill
- **Logic**: Protocol revenue is calculated on a per-fill basis using the realized deployer fee. For historical fills where the explicit deployer fee is not populated, a fallback rate of 50% of the total transaction fee is applied, representing the protocol's standard take rate ceiling. These individual revenue values are then summed to determine the total daily revenue.
- **Key fields**: `deployer_fee`, `fee`

### Component C: Normalization and aggregation

- **Purpose**: Standardize revenue values and aggregate them to a daily granularity
- **Logic**: Revenue amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. The normalized values are aggregated by day, chain, and product using UTC day boundaries. Missing days within the time series are filled with zero values to ensure data continuity.

*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.

Felix

Revenue

Revenue

Competitive landscape

Chain breakdown