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 Fees Methodology

## 1. Overview

The DFX fees metric calculates the total trading fees generated by the DFX protocol across its automated market maker (AMM) pools. DFX is a decentralized exchange focused on stablecoin and foreign exchange trading, operating multiple curve-based liquidity pools with dynamic fee tiers. The metric multiplies daily trading volume by pool-specific fee rates to determine total fees collected, providing insight into the protocol's revenue generation from trading activity.

## 2. Data sources

The calculation relies on several key data sources:
- **Blockchain events**: Parsed `Trade` events from DFX's curve contracts across Ethereum, Polygon, and Arbitrum, including multiple contract versions (v1 `Curve_Trade_event`, v2 `CurveV2_Trade_event` and `CurveV22_Trade_event`)
- **Transaction data**: Ethereum, Polygon, and Arbitrum transaction records to identify trader addresses and transaction context
- **Contract creation events**: DFX curve factory `NewCurve` events and corresponding `newCurve` function calls to extract dynamic fee tier configurations from contract deployments
- **External data**: End-of-day token price feeds for USD conversion and token metadata including decimal specifications and symbols
- **Configuration data**: Manual fee tier specifications for specific pools that require hardcoded rates

## 3. Step-by-step calculation

### Component A: Trade event extraction
- **Purpose**: Collect all trading activity from DFX protocol contracts across supported chains and versions
- **Logic**: Extract `Trade` events from DFX curve contracts, capturing both legacy v1 contracts using `Curve_Trade_event` and newer v2 contracts using `CurveV2_Trade_event` and `CurveV22_Trade_event`. Events are sourced from Ethereum, Polygon, and Arbitrum networks. Each trade captures the pool address, origin token, target token, trade amounts, and transaction details. Transaction data is joined to identify the trader address from the transaction `from_address` field.
- **Key fields**: `address` (pool contract), `origin` and `target` (traded tokens), `originAmount` and `targetAmount` (raw token quantities), `block_timestamp`, `transaction_hash`, `from_address` (trader)

### Component B: Fee tier determination
- **Purpose**: Establish the fee rate applicable to each pool for accurate fee calculation
- **Logic**: Fee tiers are determined through two mechanisms. First, manual configurations specify exact fee rates for specific pool addresses on each chain. Second, dynamic fee tiers are extracted from DFX curve factory contract creation events by parsing the `epsilon` parameter from `newCurve` function calls during pool deployment. The `epsilon` value is converted from its raw 18-decimal format to a percentage by dividing by 10^18. This creates a comprehensive mapping of pool addresses to their respective fee rates.
- **Key fields**: `account_address` (pool address), `fee_tier` (calculated percentage), `chain`, `version`

### Component C: Volume calculation and USD conversion
- **Purpose**: Convert raw token amounts to standardized USD trading volumes for consistent fee calculation
- **Logic**: Raw token amounts from trade events are first normalized by dividing by 10 raised to the token's decimal count to get actual token quantities. These normalized amounts are then converted to USD using end-of-day price feeds. When both tokens in a trading pair have price data available, the system takes the minimum USD value of the two amounts to avoid double-counting volume. If only one token has price data, that token's USD value is used. If neither token has price data, the volume is recorded as zero. Results are aggregated daily by timestamp, chain, pool address, and business dimensions.
- **Key fields**: `token0_amount` and `token1_amount` (normalized quantities), `price_usd` (end-of-day prices), `trading_volume` (final USD volume)

### Component D: Fee tier application logic
- **Purpose**: Apply appropriate fee rates based on protocol evolution and pool-specific configurations
- **Logic**: Fee application follows time-based rules to account for protocol changes. For trades occurring before February 13, 2023, a standard initial fee tier of 0.0005 (0.05%) is applied across all pools. For trades on or after this date, pool-specific fee tiers are used as determined from the fee tier mapping. This approach reflects the protocol's evolution from uniform to dynamic fee structures.
- **Key fields**: `fee_tier` (applied rate), `block_timestamp` (for date comparison), `protocol_fee_start_date` (February 13, 2023 cutoff)

### Final aggregation
- **Combining components**: Trading volumes are joined with their corresponding fee tiers based on pool address and chain. The fee calculation multiplies each pool's daily trading volume by its applicable fee tier to determine fees generated.
- **Currency conversion**: All volume calculations are performed in USD using end-of-day price feeds, ensuring consistent currency denomination across all fee calculations.
- **Time aggregation**: Data is aggregated at daily boundaries using timestamp truncation, with all trades within a calendar day grouped together for volume and fee calculations.
- **Final calculation**: The final fees metric is calculated as the sum of (trading volume × fee tier) across all pools, chains, and time periods, representing total fees collected by the DFX protocol from trading activity.

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

Total value users pay to use a protocol (gross fees, user-paid fees).

DFX FinanceDFX

Fees

Fees

Competitive landscape

Chain breakdown