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

## 1. Overview

The DFX treasury metric measures the total USD value of all tokens held in DFX protocol's official treasury addresses. This metric tracks the protocol's financial assets across different tokens, providing insight into the protocol's financial health and resource availability. The calculation aggregates token balances from multiple treasury addresses, converts them to USD using daily price feeds, and maintains a continuous time series through forward-filling techniques.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Ethereum token transfer events**: Parsed `Transfer` events from ERC20 tokens on Ethereum that involve the treasury addresses
- **Ethereum transaction logs**: Raw blockchain event logs containing token transfer data
- **End-of-day token price feeds**: Daily USD price data for all tokens held in treasury addresses
- **Token metadata**: Information about token symbols, decimals, and contract addresses for proper identification and conversion

## 3. Step-by-step calculation

### Component A: Treasury balance tracking
- **Purpose**: Identifies and tracks balance changes for all tokens in DFX treasury addresses
- **Logic**: The system monitors two specific Ethereum addresses designated as DFX treasury wallets: `0x26f539a0fe189a7f228d7982bf10bc294fa9070c` and `0x27e843260c71443b4cc8cb6bf226c3f77b9695af`. For each address, the calculation processes all Ethereum token transfer events where these addresses appear as either sender or receiver. Incoming transfers increase the balance while outgoing transfers decrease it. The system tracks balance changes for each unique token separately, maintaining separate records for each `token_address`, `account_address`, and `timestamp` combination. This creates a detailed ledger of all token movements in and out of the treasury addresses.
- **Key fields**: `account_address` for treasury wallet identification, `token_address` for token type, `balance` for net change amount, `timestamp` for transaction timing

### Component B: Cumulative balance calculation  
- **Purpose**: Converts balance changes into running totals to show actual token holdings over time
- **Logic**: The system calculates cumulative balances using window functions that sum all balance changes for each treasury address and token combination over time. The calculation partitions data by `timestamp_grain`, `chain_id`, `account_address`, and `token_address`, then orders by `timestamp` to create running totals. This transforms the individual balance change records into actual token holdings at each point in time. For example, if an address received 100 tokens on day 1 and sent 30 tokens on day 2, the cumulative balances would show 100 tokens on day 1 and 70 tokens on day 2.
- **Key fields**: Cumulative `balance` representing total tokens held, partitioning dimensions for proper grouping

### Component C: Data continuity management
- **Purpose**: Ensures continuous time series data by filling gaps where no transactions occurred
- **Logic**: The system applies forward-filling logic to maintain continuous daily records even when no token transfers occur. For each combination of treasury address and token, if no transaction happens on a particular day, the system carries forward the last known balance from the previous day. This prevents gaps in the time series that would otherwise occur during periods of no activity. The forward-filling process maintains separate continuity for each unique combination of `timestamp_grain`, `chain_id`, `account_address`, and `token_address`.
- **Key fields**: Forward-filled `balance` values, dimension fields for proper grouping during gap-filling

### Component D: USD conversion
- **Purpose**: Converts all token balances to USD for aggregation across different token types
- **Logic**: The system joins the forward-filled balance data with end-of-day token price feeds to calculate USD values. For each token balance record, the system multiplies the token amount by the corresponding daily USD price from the price feed. The price matching occurs on `timestamp`, `chain_id`, and `token_address` to ensure accurate price application. Only positive balances are included in the conversion, and only records with available price data are processed. The system filters to use daily price grain specifically to maintain consistency in valuation timing.
- **Key fields**: `amount` as the USD-converted value, `price_usd` from price feeds, filtering on positive `balance` values

### Final aggregation
- **Combining components**: The USD-converted balances from all tokens and treasury addresses are summed together to create the total treasury value. Each record contributes its full `amount` value to the daily treasury total.
- **Currency conversion**: USD conversion happens at the token level using end-of-day prices before aggregation, ensuring all values use consistent daily pricing
- **Time aggregation**: The metric maintains daily granularity with forward-filling to ensure continuous daily records
- **Final calculation**: The total treasury value equals the sum of all USD-converted token balances across both treasury addresses for each day, representing the complete financial holdings of the DFX protocol treasury

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

Total value of a project's onchain treasury, including its native token.

DFX FinanceDFX

Treasury

Treasury

Competitive landscape

Chain breakdown