HyENA earns a deployer share of trading fees on the perpetual markets it has deployed under Hyperliquid's HIP-3 framework. Markets execute on Hyperliquid's HyperCore L1 order book; it does not operate its own matching engine. HyENA's deployerFeeScale is 0.1111, so its deployer share of each user-paid fee is reduced versus the standard HIP-3 split. Revenue is read from the realized on-chain deployerFee field per fill rather than assumed.

HyENA offers USDC-settled perpetual contracts on crypto-native assets (BTC, ETH, SOL, BNB, XRP, DOGE, HYPE, FARTCOIN, PUMP, LINK, SUI, LTC, BCH, ADA, ...) plus gold, silver, and XMR. All 24 markets are deployed under the HIP-3 `hyna` namespace and execute on Hyperliquid's HyperCore order book.

HyENA is a HIP-3 (builder-deployed perpetuals) deployer on Hyperliquid, deployed by wallet 0x53e655101ea361537124ef814ad4e654b54d0637. HyENA is operated as a private company; no token has been issued.

website

Derivative exchanges

HyENA

# HyENA Revenue Methodology

## 1. Overview

The portion of fees retained by the protocol from trade executions across its perpetual markets is measured by Revenue. These earnings are determined by the protocol's take rate, specifically the deployer fee share. The remaining fees are distributed to other ecosystem participants. The protocol's earnings before operating expenses, cost of revenue, and token incentives are represented by this metric.

## 2. Data sources

- **Blockchain events**: `node_fills` events from Hypercore, covering the Hypercore chain

## 3. Step-by-step calculation

### Component A: Node fill extraction and filtering

- **Purpose**: The identification and extraction of trade execution data for the protocol's perpetual markets.
- **Logic**: Trade execution data is parsed from `node_fills` events on the Hypercore chain. Fills are filtered to include only those associated with the protocol's perpetual markets, which are identified by a specific prefix. Only fills settled in the designated settlement asset are included.
- **Key fields**: `block_timestamp`, `coin`, `fee`, `fee_token`, `deployer_fee`

### Component B: Revenue calculation and fallback application

- **Purpose**: The determination of the protocol's share of fees for each trade.
- **Logic**: For each trade fill, the protocol revenue is determined. If an on-chain realized deployer fee is present, that value is directly used. If the deployer fee is not present (such as for pre-emission fills), a fallback rate of approximately 11.11% of the total fee is applied, calculated as `fee * 0.1111 / 1.1111` in accordance with the HIP-3 specification.
- **Key fields**: `deployer_fee`, `fee`

### Component C: Aggregation and normalization

- **Purpose**: The aggregation of calculated revenue into daily intervals.
- **Logic**: Calculated revenue values are aggregated by day, chain, and product. Product identifiers are generated by flattening the market identifiers into alphanumeric slugs. Missing days are filled with zeros to ensure a continuous daily time series.
- **Key fields**: `block_timestamp`, `product_id`, `revenue`

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

HyENA

Revenue

Revenue

Competitive landscape