Market makers offer trades through order book & make money on bid-ask spreads (supply-side fees).

dYdX is a non-custodial trading and derivatives protocol initially built on Ethereum and later expanded to their own blcokchain built on top of the Cosmos SDK. dYdX was founded by Antonio Juliano and launched in 2017.

DYDX tokenholders own and govern the protocol. dYdX Trading Inc. currently takes all of the total trading fees paid by traders (revenue). dYdX’s investors include a16z, Polychain, The Spartan Group, etc.

governance

github

twitter

discord

etherscan

website

Derivative exchanges

dYdX

# dYdX Revenue Methodology

## 1. Overview

The dydx revenue metric measures the total trading fees collected by the dydx protocol across all its versions and implementations. This metric represents 100% of trading fees as revenue since all fees are collected by the protocol, while liquidity providers are incentivized through bid-ask spreads. The calculation combines fee data from multiple sources covering different time periods and product versions, excluding blockchain transaction fees which don't represent protocol revenue.

## 2. Data sources

The calculation relies on several key data sources:

- **dydx blockchain transaction records**: Native transaction data from the dydx blockchain including transaction fees and tips
- **dydx dYdX V4 match event logs**: Blockchain events capturing trading activity with embedded fee information from maker and taker orders
- **dydx API trading fee data**: Hourly aggregated fee data from the dydx trading API covering historical trading activity
- **Manual historical fee records**: Team-provided daily fee amounts for early 2023 when automated data collection wasn't available
- **Legacy Fivetran revenue data**: Historical revenue data for dYdX V3 implementation on Ethereum's StarkEx
- **End-of-day token price feeds**: Price data from CoinGecko for converting native token fees to USD
- **Token metadata**: CoinGecko identifiers and decimal precision information for proper token conversion

## 3. Step-by-step calculation

### Component A: Manual historical fees
- **Purpose**: Provides fee data for early 2023 period when automated collection wasn't available
- **Logic**: Uses hardcoded daily fee amounts provided by the dydx team for dates from 2023-01-01 through 2023-03-06. These values are stored as static configuration and converted to proper numeric format with daily timestamp boundaries.
- **Key fields**: `timestamp` (daily boundaries), `fee_amount` (USD-denominated fees)

### Component B: API trading fees with manual overrides
- **Purpose**: Calculates daily trading fees from hourly API data with selective manual corrections
- **Logic**: Aggregates hourly fee data to daily snapshots by taking fee values at 00:00, 01:00, or 02:00 UTC (representing 24-hour rolling totals). Manual fee corrections from Component A override API values for specific dates where data quality issues were identified. The logic preferentially selects fees in order: midnight, 1 AM, then 2 AM UTC.
- **Key fields**: `timestamp` (daily boundaries), `fee_amount` (aggregated daily fees)

### Component C: Legacy revenue data
- **Purpose**: Incorporates historical dYdX V3 fee data from previous data collection systems
- **Logic**: Uses pre-existing revenue data from Fivetran for the dYdX V3 implementation on Ethereum's StarkEx. Filters for Ethereum chain records and applies daily timestamp truncation.
- **Key fields**: `daily_timestamp` (date boundaries), `fees` (historical revenue amounts)

### Component D: Native blockchain fees
- **Purpose**: Calculates transaction fees collected on the dydx blockchain itself
- **Logic**: Aggregates transaction fees and tips from dydx blockchain transaction records. Sums `transaction_fee` and `transaction_tip` amounts, excludes failed transactions (those with null fees), groups by daily timestamps, and converts from native token amounts to USD using end-of-day price feeds and 18-decimal precision.
- **Key fields**: `transaction_fee` (native fees), `transaction_tip` (additional tips), `block_timestamp` (transaction timing)

### Component E: dYdX V4 trading fees
- **Purpose**: Extracts trading fees from dYdX V4 match events on dydx blockchain
- **Logic**: Parses `match` event logs to extract fee information from JSON attributes. Combines `taker_order_fee_quote_quantums` and `maker_order_fee_quote_quantums` fields, converts from USDC quantums to USD by dividing by 10^6, aggregates by daily timestamps, and filters for match event types.
- **Key fields**: `taker_order_fee_raw` and `maker_order_fee_raw` (extracted from event JSON), `block_timestamp` (event timing)

### Final aggregation
- **Combining components**: All fee sources are combined using union operations with consistent schema mapping: timestamps to daily boundaries, chain identifiers (starkex for dYdX V3, dydx for blockchain/dYdX V4), product identifiers (dYdX V3, dYdX Chain, dYdX V4), and version labels
- **Currency conversion**: Native token fees converted to USD using end-of-day CoinGecko price feeds; USDC-denominated fees used directly as USD amounts
- **Time aggregation**: All data normalized to daily boundaries using timestamp truncation; gaps filled with zero values to ensure complete time series
- **Final calculation**: Revenue equals the sum of all trading fees from Components A, B, C, and E, explicitly excluding blockchain fees from Component D since these don't represent protocol trading revenue. The business logic treats 100% of trading fees as revenue since the protocol collects all fees while market makers are compensated through spreads.

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

dYdXDYDX

Revenue

Revenue

Competitive landscape

Chain breakdown