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 (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have been active on the dYdX blockchain within any 30-day rolling window. This metric captures user engagement across both general blockchain activity (transaction sending) and specialized DEX trading operations (making and taking orders). The calculation uses a rolling 30-day window approach with HyperLogLog algorithms for efficient distinct address counting across large datasets.

## 2. Data sources

The calculation relies on the following raw data sources:
- **dYdX blockchain event logs**: Message events from the dYdX blockchain containing transaction and trading activity
- **General transaction events**: Events of type `message` that capture basic blockchain transaction activity with sender addresses
- **DEX trading events**: Events of type `match` that capture decentralized exchange trading activity including maker and taker subaccount identifiers
- **Subaccount metadata**: JSON-structured event attributes containing user addresses and subaccount identifiers for trading activity

## 3. Step-by-step calculation

### Component A: Daily active address collection
- **Purpose**: Identifies all unique addresses active each day across different types of blockchain activity
- **Logic**: Combines three distinct sources of user activity: transaction senders from general blockchain operations, maker addresses from DEX trading matches, and taker addresses from DEX trading matches. Each source extracts user addresses from JSON event attributes, truncates timestamps to daily boundaries, and deduplicates addresses within each day. The component uses UNION DISTINCT to combine all three address sources while preventing double-counting of addresses that appear in multiple activity types on the same day
- **Key fields**: `block_timestamp` truncated to daily boundaries, `user_address` extracted from event sender fields, `maker` and `taker` subaccount identifiers from trading events, `user_type` classifications (Transaction sender, maker, taker), `product_id` identifiers (dYdX Chain, dYdX V4), `chain` identifier (dydx)

### Component B: HyperLogLog daily sketch creation  
- **Purpose**: Creates memory-efficient daily sketches for distinct address counting across large datasets
- **Logic**: Groups daily active addresses by timestamp and dimensional attributes (chain, user type, product), then initializes HyperLogLog sketches with precision parameter 15 for each group. This approach enables efficient storage and computation of distinct counts without maintaining full address lists
- **Key fields**: Daily `timestamp`, `timestamp_grain` set to 'day', dimensional grouping fields (`chain_id`, `user_type`, `product_id`), `hll` sketch containing compressed address information

### Component C: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for each calendar day to enable monthly active user calculations
- **Logic**: Generates a complete datespine covering all days in the analysis period, then creates join tables that map each day to its preceding 29 days (forming 30-day windows). For each target day, the system identifies all days within the 30-day lookback period and joins them with the corresponding daily HLL sketches
- **Key fields**: `timestamp` as the target day, `joinday` representing each day within the 30-day window, temporal mapping relationships between target days and their lookback periods

### Component D: HyperLogLog sketch merging
- **Purpose**: Combines HLL sketches across 30-day windows to calculate unique address counts over rolling monthly periods  
- **Logic**: For each 30-day window, merges all daily HLL sketches using HyperLogLog merge operations, then extracts the distinct count estimate. This process efficiently calculates unique addresses over rolling 30-day periods without storing or processing complete address lists
- **Key fields**: Window `timestamp`, merged `hll` sketches, extracted distinct address counts representing monthly active users

### Component E: Dimensional breakdown
- **Purpose**: Provides multiple analytical perspectives on monthly active address data
- **Logic**: Creates separate views of the monthly active address data broken down by different dimensions: project-level aggregation (all activity combined), chain-level breakdown, user type breakdown (transaction senders, makers, takers), and product breakdown (dYdX Chain vs dYdX V4). Each breakdown maintains the same rolling 30-day calculation logic but groups results differently
- **Key fields**: `dimensions` field indicating breakdown type ('project_dbt_tag', 'chain', 'user_type', 'product_id'), `user_mau` containing the monthly active address count, dimensional identifier fields populated based on breakdown type

### Final aggregation
- **Combining components**: The dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple analytical perspectives
- **Currency conversion**: Not applicable as this metric counts addresses rather than monetary values
- **Time aggregation**: Uses rolling 30-day windows calculated daily, providing a continuous monthly active user series without traditional calendar month boundaries
- **Final calculation**: The target model selects the `user_mau` field (renamed to `active_addresses_monthly`) from the dimensional breakdowns, filtering for 'chain' and 'project_dbt_tag' dimensions only. The finalize_metric macro applies schema standardization and fills missing time periods with zeros to ensure complete time series data. Chain availability filtering is applied to respect data availability constraints.

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

Unique addresses active over a rolling 30-day window.

dYdXDYDX

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown