Liquidity providers deposit funds into DFX and receive a share of trading fees (supply-side fees).

DFX is a decentralized foreign exchange protocol deployed on Polygon, Ethereum & Arbitrum. DFX was founded in 2021 by Kevin Zhang and Adrian Li.

DFX tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

governance

github

twitter

discord

etherscan

website

Exchanges (DEX)

DFX Finance

# DFX Finance Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for DFX Protocol measures the number of unique users who executed at least one trade within any 7-day period. This metric uses HyperLogLog approximation for efficient calculation and provides breakdowns across multiple dimensions including chain, user type, and product. The calculation creates rolling 7-day windows from daily active user data derived from trading activity across all DFX protocol versions and supported blockchains.

## 2. Data sources

- **DFX trading events**: Parsed `Trade` events from DFX v1 `Curve` contracts, DFX v2 `CurveV2` contracts, and DFX v2.2 `CurveV22` contracts across Ethereum, Polygon, and Arbitrum networks
- **Transaction records**: Ethereum, Polygon, and Arbitrum transaction data containing sender addresses (`from_address`) to identify the users initiating trades
- **Contract metadata**: DFX protocol version information and contract addresses for proper event classification

## 3. Step-by-step calculation

### Component A: Trade event collection
- **Purpose**: Aggregate all trading activity across DFX protocol versions and chains
- **Logic**: Extract trading events from multiple DFX contract versions including v1 `Curve_Trade_event`, v2 `CurveV2_Trade_event`, and v2.2 `CurveV22_Trade_event` across Ethereum, Polygon, and Arbitrum. Join each trade event with corresponding transaction records to obtain the user address (`from_address`) who initiated the trade. Classify all trades under the 'Exchange AMM' business line and 'dex' business segment. Include token pair information (`token0_address`, `token1_address`) and trade amounts for each swap
- **Key fields**: `user_address` (from transaction `from_address`), `block_timestamp`, `chain`, `account_address` (contract), `version`, `token0_address`, `token1_address`, `token0_amount`, `token1_amount`

### Component B: Daily active user calculation  
- **Purpose**: Identify unique users who traded each day
- **Logic**: Group trade events by day using `timestamp_trunc` on `block_timestamp` to daily granularity. Extract distinct `user_address` values for each combination of day, chain, market sector, business segment, and product. Classify all users as 'Trader' user type since the metric focuses on trading activity. Apply chain availability filtering to ensure data quality and completeness
- **Key fields**: `timestamp` (day), `chain`, `user_type` ('Trader'), `product_id`, `user_dau` (unique user address)

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user lists to efficient approximate counting structures  
- **Logic**: Initialize HyperLogLog sketches from the daily active user data using `hll_count.init` with 15-bit precision. Group sketches by day, chain, user type, and product to maintain dimensional breakdowns. This enables efficient merging of user sets across the 7-day rolling windows without storing individual user addresses
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component D: Rolling window creation
- **Purpose**: Create 7-day rolling windows for each day to calculate weekly active users
- **Logic**: Generate a complete date spine from the earliest trade date to yesterday using `generate_timestamp_array` with daily intervals. For each date in the spine, create associations with the current day plus the previous 6 days using nested array generation. This creates a join table mapping each target date to all dates in its 7-day window. Join this mapping with the daily HLL sketches to collect all sketches within each 7-day period
- **Key fields**: `timestamp` (target date), `joinday` (dates within 7-day window), `hll` (daily sketches)

### Component E: Weekly aggregation and dimensional breakdowns
- **Purpose**: Calculate unique weekly active users across multiple dimensions
- **Logic**: For each 7-day window, merge all HLL sketches using `hll_count.merge_partial` and extract the final count with `hll_count.extract` to get approximate unique users across the week. Create four separate dimensional breakdowns: (1) Overall project level with all dimensions set to null, (2) Chain-level breakdown grouping by `chain_id`, (3) User type breakdown grouping by `user_type`, (4) Product-level breakdown grouping by `product_id`. Each breakdown maintains the weekly timeframe while providing different analytical perspectives
- **Key fields**: `user_wau` (weekly unique user count), `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`

### Final aggregation  
- **Combining components**: Union all four dimensional breakdowns (project_dbt_tag, chain, user_type, product_id) into a single result set using `union all` operations
- **Time aggregation**: Maintain daily timestamp granularity where each day represents the end date of its corresponding 7-day window  
- **Final calculation**: Apply the `finalize_metric_user_wau` macro with 'fill_zeros' strategy to standardize the schema, add metadata fields like `data_id` ('dfx'), and fill any missing days with zero values to ensure complete time series coverage

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

Unique revenue-generating users over a rolling 7-day window.

DFX FinanceDFX

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown