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 fees per user (AFPU) Methodology

## 1. Overview

AFPU (Average Fees Per User) measures the average fee revenue generated per daily active user on the DFX protocol. This metric provides insight into user monetization efficiency by dividing total daily fee revenue by the number of distinct users who traded that day. The calculation involves extracting trading activity from DFX's AMM contracts across multiple chains, calculating fees based on trading volumes and pool-specific fee rates, counting unique daily users, and computing the ratio.

## 2. Data sources

- **DFX trade events**: Parsed `Trade` events from DFX v1 and v2 contracts on Ethereum, Polygon, and Arbitrum, including `Curve_Trade_event`, `CurveV2_Trade_event`, and `CurveV22_Trade_event`
- **Transaction records**: Ethereum, Polygon, and Arbitrum transaction data to identify user addresses (`from_address`) for each trade
- **Contract creation events**: Parsed `CurveFactoryV22_NewCurve_event` events and corresponding function calls to extract pool-specific fee rates from the `epsilon` parameter
- **Token metadata**: Token symbol and decimal information for proper amount normalization
- **End-of-day price feeds**: Daily USD price data for tokens involved in trades
- **Manual configuration**: Hardcoded fee tiers for specific pool addresses on Arbitrum

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Collect all trading activity across DFX protocol versions and chains
- **Logic**: Extract trade events from multiple contract versions including DFX v1 (`Curve_Trade_event` on Ethereum and Polygon) and DFX v2 (`CurveV2_Trade_event` and `CurveV22_Trade_event` on Ethereum, Polygon, and Arbitrum). Each trade event contains `originAmount`, `targetAmount`, `origin` token address, `target` token address, and contract `address`. Join with transaction data to obtain the user address (`from_address`) who initiated each trade.
- **Key fields**: `originAmount` and `targetAmount` (raw token amounts), `origin` and `target` (token addresses), `from_address` (user identifier), `block_timestamp` (for daily aggregation)

### Component B: Fee tier determination
- **Purpose**: Establish the fee rate applicable to each trading pair
- **Logic**: Fee tiers are determined through two methods. For manually configured pools (primarily on Arbitrum), hardcoded fee rates are applied to specific contract addresses. For dynamically created pools, fee tiers are extracted from contract creation events where the `epsilon` parameter in `CurveFactoryV22_newCurve_function` calls represents the fee rate (divided by 10^18 to convert from wei). A temporal rule applies a default 0.05% (0.0005) fee tier for all trades before February 13, 2023, when protocol fees were introduced.
- **Key fields**: `epsilon` (raw fee rate in wei), `account_address` (pool contract), fee tier conversion and date-based logic

### Component C: Trading volume calculation
- **Purpose**: Convert raw token amounts to standardized USD trading volumes
- **Logic**: For each trade, correct the raw `originAmount` and `targetAmount` by dividing by 10^decimals using token metadata. Convert corrected amounts to USD values using end-of-day price feeds. When both tokens have available prices, take the minimum USD value between the two tokens to avoid double-counting volume. If only one token has price data, use that token's USD value. If neither token has price data, record zero volume.
- **Key fields**: `decimals` (for amount correction), `price_usd` (for USD conversion), logic for handling missing price data

### Component D: Daily user aggregation
- **Purpose**: Count distinct users who traded each day using scalable aggregation
- **Logic**: Extract unique `user_address` values from all trades, grouped by day using `timestamp_trunc`. Apply HyperLogLog (HLL) sketching for efficient distinct counting across multiple dimensions (project-level, chain-level, user-type-level, product-level). This allows for scalable aggregation without storing individual user addresses.
- **Key fields**: `user_address` (for uniqueness), `timestamp` (daily grouping), HLL functions for approximate distinct counting

### Component E: Fee calculation
- **Purpose**: Calculate total fee revenue from trading activity
- **Logic**: For each trade, multiply the USD trading volume by the applicable fee tier to determine fee revenue. Sum all fees by day to get total daily fee revenue. Fee calculation respects the temporal rule where trades before February 13, 2023 use the 0.05% default rate, while later trades use pool-specific rates.
- **Key fields**: `trading_volume` (USD amount), `fee_tier` (percentage rate), daily summation of fee amounts

### Final aggregation
- **Combining components**: Daily active user counts and daily fee totals are combined at the same time granularity (daily) and dimensional level (project-wide, chain-specific, etc.)
- **Currency conversion**: All fee calculations are performed in USD after token amount conversion using end-of-day price feeds
- **Time aggregation**: All metrics are calculated with daily boundaries using `timestamp_trunc` to ensure consistent time alignment
- **Final calculation**: AFPU is calculated by dividing total daily fees by the daily active user count, providing the average fee revenue generated per user per day

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

DFX FinanceDFX

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape