Paragon 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. The default HIP-3 fee split allocates 50% of each user-paid fee to Hyperliquid and 50% to the deployer; deployerFeeScale is 1.0, so the standard split applies.

Paragon offers USDC-settled perpetual contracts on crypto index and basket products (BTC dominance, TOTAL2, OTHERS) and AVGO. All 4 markets are deployed under the HIP-3 `para` namespace and execute on Hyperliquid's HyperCore order book.

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

website

github

Derivative exchanges

Paragon

# Paragon Revenue Methodology

## 1. Overview

Revenue is measured as the portion of fees that is retained by the protocol, as determined by its take rate. For Paragon, this is represented by the deployer fees generated from trading activity across the protocol's perpetual markets. These fees are collected in USDC and are classified as protocol earnings before operating expenses, token incentives, and cost of revenue. This metric is utilized to assess the financial sustainability and commercial traction of the protocol's perpetual markets.

## 2. Data sources

- **Blockchain events**: `node_fills` events from Hypercore nodes, covering Hypercore

## 3. Step-by-step calculation

### Component A: Fill event extraction and filtering

- **Purpose**: To extract and filter trade fill events associated with Paragon perpetual markets.
- **Logic**: Trade fill events are parsed from `node_fills` events on Hypercore. Events are filtered to include only those where the market identifier carries the `para:` prefix, isolating Paragon perpetual markets. Transactions are further filtered to only include those where the fee asset is USDC.
- **Key fields**: `block_timestamp`, `coin`, `fee`, `fee_token`, `deployer_fee`

### Component B: Revenue calculation

- **Purpose**: To calculate the protocol revenue generated from each trade fill.
- **Logic**: For each filtered fill event, the revenue is determined by extracting the realized deployer fee. If the deployer fee is not present, a fallback rate of 50% of the total transaction fee is applied, representing the HIP-3 specification ceiling for pre-emission fills. These values are then summed to calculate the total revenue.
- **Key fields**: `deployer_fee`, `fee`

### Component C: Temporal aggregation and normalization

- **Purpose**: To aggregate calculated revenue into daily intervals.
- **Logic**: Calculated revenue values are aggregated by day using UTC boundaries. The final values are normalized by decimal precision and mapped to the respective product identifiers. Missing days are filled with zero values to ensure a continuous time series.
- **Key fields**: `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.

Paragon

Revenue

Revenue

Competitive landscape