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 Average trading volume (per user) Methodology

## 1. Overview

The DFX trading volume average per user metric measures the average USD trading volume generated per daily active user on the DFX protocol. This metric answers the question "How much trading volume does each active user generate on average?" and helps assess user engagement intensity and protocol efficiency. The calculation divides total daily trading volume by the number of daily active users, providing insight into per-user trading behavior patterns.

## 2. Data sources

- **Blockchain events**: Parsed `Trade` events from DFX Curve contracts on Ethereum, Polygon, and Arbitrum networks, including events from Curve, CurveV2, and CurveV22 contract versions
- **Transaction data**: Ethereum, Polygon, and Arbitrum transaction records providing user address identification through `from_address` fields
- **Contract creation events**: `NewCurve` events from DFX CurveFactory contracts containing fee tier information
- **External data**: End-of-day token price feeds for USD conversion and token metadata including symbols and decimal precision
- **Manual configurations**: Hardcoded fee tier mappings for specific Arbitrum contracts

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Collect all swap transactions from DFX AMM contracts across supported chains
- **Logic**: Extract `Trade` events from DFX Curve contracts spanning multiple versions (v1 Curve, v2 CurveV2, and v2 CurveV22) across Ethereum, Polygon, and Arbitrum. Join with transaction records to identify the user address through the `from_address` field. Filter for successful transactions and extract key trade details including token addresses, amounts, and contract addresses.
- **Key fields**: `transaction_hash`, `from_address` (user), `origin` and `target` (token addresses), `originAmount` and `targetAmount` (trade amounts), contract `address`

### Component B: Fee tier determination  
- **Purpose**: Apply appropriate fee tiers to each trade based on contract and timing
- **Logic**: Combine manual fee tier configurations for specific Arbitrum contracts with dynamic fee tiers extracted from CurveFactory contract creation events. For trades occurring before February 13, 2023, apply a hardcoded initial fee tier of 0.0005. For later trades, use the epsilon value from the contract creation function call, normalized by dividing by 10^18.
- **Key fields**: `account_address` (contract), `fee_tier`, creation date, `epsilon` parameter

### Component C: Amount normalization and USD conversion
- **Purpose**: Standardize token amounts and convert to USD values for aggregation
- **Logic**: Correct raw token amounts by dividing by 10 raised to the power of each token's decimal precision. Join with end-of-day token price feeds to obtain USD prices for both tokens in each trade pair. Apply intelligent price selection logic - when both tokens have available prices, use the lesser of the two USD values to avoid double-counting. When only one price is available, use that single conversion. If neither price is available, record zero volume.
- **Key fields**: `decimals` (token precision), `price_usd` (daily prices), normalized `token0_amount` and `token1_amount`

### Component D: Daily trading volume aggregation
- **Purpose**: Sum all trade volumes to daily totals across the entire protocol
- **Logic**: Group trades by day using timestamp truncation and sum the USD-converted trading volumes. Aggregate across all chains, contract versions, and trading pairs to produce protocol-level daily volumes. Include additional dimensions like chain, business line categorization, and version information for comprehensive tracking.
- **Key fields**: `timestamp` (daily), `trading_volume` (USD sum), `chain`, `business_line`, `version`

### Component E: Daily active user calculation
- **Purpose**: Count unique users who performed trades on each day
- **Logic**: Extract distinct user addresses from the trade data on a daily basis, categorizing all users as 'Trader' user type. Apply HyperLogLog algorithms for efficient distinct counting across multiple dimensional breakdowns including project-level, chain-level, user-type-level, and product-level aggregations. Use the project-level dimension ('project_dbt_tag') for the final calculation to capture total protocol DAU.
- **Key fields**: `user_dau` (distinct count), `user_type`, `dimensions`, HyperLogLog sketches

### Final aggregation
- **Combining components**: Join the daily trading volume metrics with the project-level DAU metrics using timestamp as the key, ensuring both datasets represent the same daily time periods
- **Currency conversion**: All volumes are already converted to USD using end-of-day price feeds during the intermediate processing stage
- **Time aggregation**: Both components use daily boundaries created by truncating timestamps to day precision
- **Final calculation**: Apply safe division of the total daily trading volume by the daily active user count, handling edge cases where DAU might be zero to prevent division errors. The result represents the average USD trading volume generated per active user on that day.

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

Average trading volume (per user)

Trading volume divided by daily active users.

DFX FinanceDFX

Average trading volume (per user)

Average trading volume (per user)

Competitive landscape