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 revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active trader on the DFX protocol. This metric is calculated by dividing daily protocol revenue by the number of daily active users. ARPU helps assess the monetization efficiency and value extraction per user, providing insight into the protocol's ability to generate sustainable revenue from its user base.

## 2. Data sources

The ARPU calculation relies on several raw blockchain and external data sources:

- **DFX protocol events**: Parsed `Trade` events from DFX v1 and v2 protocol contracts deployed on Ethereum, Polygon, and Arbitrum
- **Transaction data**: Transaction records from Ethereum, Polygon, and Arbitrum to identify user addresses initiating trades  
- **Contract creation events**: DFX contract creation events containing fee tier information for v2 pools
- **Token metadata**: Token contract information including decimal precision and symbols for proper amount calculations
- **External price data**: End-of-day token price feeds for USD conversion of trading volumes
- **Manual configuration**: Hardcoded fee tier data for specific Arbitrum pools not captured in contract events

## 3. Step-by-step calculation

### Component A: Trade data extraction
- **Purpose**: Collect all trading activity across DFX protocol versions and chains
- **Logic**: Extract `Trade` events from DFX protocol contracts across multiple versions (v1 using `Curve_Trade_event`, v2 using `CurveV2_Trade_event` and `CurveV22_Trade_event`) and chains (Ethereum, Polygon, Arbitrum). Join with transaction data to obtain the `from_address` as the user address. Each trade captures the origin and target token addresses, amounts, and associated pool contract address.
- **Key fields**: `block_timestamp`, `transaction_hash`, `address` (pool contract), `user_address` (trader), `originAmount`, `targetAmount`, `origin` (token0), `target` (token1)

### Component B: Trading volume calculation
- **Purpose**: Convert raw token amounts to USD trading volumes with proper decimal handling
- **Logic**: Apply decimal corrections to token amounts using token metadata. Convert corrected amounts to USD using end-of-day price feeds. When both tokens in a pair have price data available, use the minimum USD value between the two token amounts to avoid double-counting. If only one token has pricing data, use that token's USD value. Aggregate volumes daily at the transaction level.
- **Key fields**: `token0_amount`, `token1_amount` (decimal-corrected), `trading_volume` (USD value), `timestamp` (daily)

### Component C: Fee tier determination  
- **Purpose**: Apply appropriate fee rates to calculate protocol fees from trading volume
- **Logic**: Before February 13, 2023, apply a fixed 0.05% fee rate to all trades. After this date, use dynamic fee tiers determined from contract creation events or manual configuration. For v2 pools, extract the `_epsilon` parameter from contract creation functions and normalize by dividing by 10^18. For specific Arbitrum pools, use manually configured fee tiers (0.1% and 0.3%).
- **Key fields**: `fee_tier` (as decimal, e.g., 0.001 for 0.1%), `epsilon` parameter from contract creation

### Component D: Fee calculation
- **Purpose**: Calculate total protocol fees generated from trading activity
- **Logic**: Multiply daily trading volume by the applicable fee tier for each pool and day. Aggregate fees across all pools and chains on a daily basis. This represents the total fees collected by the protocol from trading activity.
- **Key fields**: `fees` (USD value calculated as trading_volume × fee_tier)

### Component E: Revenue calculation
- **Purpose**: Determine protocol revenue as the portion of fees retained by the protocol
- **Logic**: Before February 13, 2023, protocol revenue is zero as the protocol did not retain fees. After this date, apply a 50% protocol fee share to total fees collected. This represents the protocol's revenue from trading fees.
- **Key fields**: `revenue` (USD value calculated as fees × 0.5 after protocol launch)

### Component F: Daily active users calculation
- **Purpose**: Count unique traders active each day across the protocol
- **Logic**: Extract distinct `user_address` values from trade events, grouped by day. Use HyperLogLog data structure for efficient distinct counting across different dimensional breakdowns (project-level, chain-level, user-type-level, product-level). All users are classified as 'Trader' type since they originate from trading activity.
- **Key fields**: `user_dau` (distinct count of user addresses), `user_type` (always 'Trader')

### Final aggregation
- **Combining components**: The ARPU calculation divides daily protocol revenue by daily active users for the same time period
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds with fallback logic for missing price data
- **Time aggregation**: Both revenue and user metrics are aggregated to daily boundaries using timestamp truncation
- **Final calculation**: ARPU equals daily protocol revenue divided by daily active users, providing the average revenue generated per active trader per day

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

DFX FinanceDFX

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape