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 Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that interacted with the dYdX protocol within a 7-day rolling window. This metric captures user engagement across all dYdX protocol activities including general transactions and dYdX V4 trading activities. The calculation uses HyperLogLog sketches to efficiently count distinct addresses across different user interaction types while maintaining accuracy for large-scale address counting.

## 2. Data sources

The metric relies on the following raw data sources:
- **dYdX chain message events**: Blockchain events from the dYdX chain containing transaction message data with sender addresses extracted from JSON event attributes
- **dYdX dYdX V4 trading match events**: Trading match events from dYdX dYdX V4 containing maker and taker addresses extracted from JSON event attributes  
- **Chain metadata**: Configuration data for chain availability filtering and time boundary validation

## 3. Step-by-step calculation

### Component A: Daily active user identification
- **Purpose**: Extract and deduplicate all unique user addresses that interacted with dYdX on each day
- **Logic**: The calculation identifies three types of users from different event sources. First, transaction senders are extracted from dYdX chain message events where the `event_type` equals "message", with user addresses parsed from the `sender` field in the JSON `event_attributes`. Second, taker addresses are extracted from dYdX V4 match events where `event_type` equals "match", parsed from the `taker_subaccount` field. Third, maker addresses are extracted from the same dYdX V4 match events, parsed from the `maker_subaccount` field. All addresses are truncated to daily timestamps and deduplicated within each day across all interaction types.
- **Key fields**: `block_timestamp` for daily aggregation, `user_address` for distinct counting, `user_type` for categorization, `product_id` for version tracking

### Component B: HyperLogLog sketch creation  
- **Purpose**: Create memory-efficient probabilistic data structures for distinct address counting across large datasets
- **Logic**: Daily active user addresses are converted into HyperLogLog sketches using a precision parameter of 15 bits. These sketches enable approximate distinct counting with high accuracy while using minimal memory. Each day's unique addresses are grouped by timestamp, chain, user type, and product, with HyperLogLog initialization performed on the address field.
- **Key fields**: `timestamp` for grouping boundaries, `hll` sketch for efficient distinct counting, dimensional fields for breakdown analysis

### Component C: Rolling window construction
- **Purpose**: Create 7-day rolling windows to calculate weekly active addresses for each date
- **Logic**: A continuous datespine is generated covering the full time range of available data, ensuring no gaps in the time series. For each date in the datespine, a join is performed with the 6 preceding days (creating a 7-day window including the current date). This window join connects each date with its corresponding daily HyperLogLog sketches from the past week, enabling accurate weekly active user counting without double-counting addresses that appear on multiple days.
- **Key fields**: `timestamp` for window boundaries, `joinday` for historical date references, `hll` sketches from daily data

### Component D: Weekly active user aggregation
- **Purpose**: Calculate distinct weekly active addresses by merging HyperLogLog sketches across 7-day windows
- **Logic**: HyperLogLog sketches are merged across each 7-day window using probabilistic union operations that maintain distinct counting accuracy. The sketches are grouped by timestamp and various dimensional breakdowns including project level, chain level, user type level, and product level. The final distinct count is extracted from the merged HyperLogLog sketches, providing the weekly active user count for each dimension and date.
- **Key fields**: `user_wau` containing the final distinct weekly count, `dimensions` for breakdown categorization, `chain_id` for chain-specific analysis

### Final aggregation
- **Combining components**: The model filters the weekly active user results to include only 'chain' and 'project_dbt_tag' dimensional breakdowns, which represent chain-specific and overall project-level weekly active addresses respectively
- **Currency conversion**: No currency conversion is required as this is a count-based metric measuring unique addresses
- **Time aggregation**: Uses 7-day rolling windows calculated daily, where each date includes the count of distinct addresses active in that date plus the 6 preceding days
- **Final calculation**: The `user_wau` field is renamed to `active_addresses_weekly` to align with standard Token Terminal metric naming conventions, representing the final count of unique addresses active within each 7-day period

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Unique active addresses over a rolling 7-day window.

dYdXDYDX

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown