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

dreamcash offers USDC-settled perpetual contracts on US equities (NVDA, TSLA, AMZN, MSFT, META, GOOGL, INTC, HOOD), indices (USA500, EWY, KWEB), and commodities (gold, silver, WTI). All 15 markets are deployed under the HIP-3 `cash` namespace and execute on Hyperliquid's HyperCore order book.

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

website

Derivative exchanges

dreamcash

# dreamcash Revenue Methodology

## 1. Overview

Revenue measures the portion of fees that dreamcash retains from trading activity across the protocol's perpetual markets. The portion of fees retained by the protocol is represented by this metric, before operating expenses and token incentives are deducted. Through the capture of realized deployer fees or a designated share of transaction fees, insight is provided into the protocol's financial sustainability and commercial traction. These earnings are denominated in stablecoins and aggregated to reflect the total protocol income.

## 2. Data sources

- **Blockchain events**: `node_fills` events on the Hypercore chain

## 3. Step-by-step calculation

### Component A: Perpetual market trade extraction

- **Purpose**: Extract trade execution data for the protocol's perpetual markets
- **Logic**: Node fill events are parsed from `node_fills` events on the Hypercore chain. Transactions are filtered to isolate the protocol's perpetual markets by identifying assets with the designated protocol prefix. Only fills settled in the designated settlement stablecoin are included in the dataset.
- **Key fields**: `block_timestamp` (timing), `fee` (transaction fee), `deployer_fee` (realized deployer fee), `fee_token` (settlement asset identification)

### Component B: Revenue attribution

- **Purpose**: Calculate the protocol's share of fees for each trade
- **Logic**: For each trade fill, revenue is determined using the realized deployer fee. If the deployer fee is not present, a fallback rate of 50% of the total transaction fee is applied as specified by the protocol's improvement proposals. These individual fee allocations are summed to calculate the total revenue per market.
- **Key fields**: `deployer_fee` (realized deployer fee), `fee` (transaction fee)

### Component C: Aggregation and normalization

- **Purpose**: Aggregate revenue into daily intervals and normalize the output
- **Logic**: The calculated revenue is aggregated by day, chain, and product. Amounts are normalized by decimal precision. A zero-filling strategy is applied to ensure continuous daily data, and a chain availability filter is applied to align the data with the active periods of the underlying chain.
- **Key fields**: `timestamp` (daily interval), `revenue` (aggregated daily 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.

dreamcash

Revenue

Revenue

Competitive landscape