Liquidity providers deposit funds into DODO and receive trading fees from traders (supply-side fees).

DODO is a non-custodial exchange protocol built on Ethereum and other blockchains. DODO launched in 2020.

DODO tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). DODO's investors include Pantera Capital, Three Arrows Capital, Binance Labs, etc.

github

twitter

discord

etherscan

website

Exchanges (DEX)

DODO

# DODO Average trading volume (per user) Methodology

## 1. Overview

Average trading volume (per user) is calculated as the mean trading volume generated per daily active user on the DODO decentralized exchange. User engagement depth is assessed by this metric, which shows the average volume generated per active trader. Total daily trading volume across all DODO pools is divided by the count of unique active users (daily), providing insight into trading behavior intensity and platform usage patterns.

## 2. Data sources

- **Blockchain events**: `BuyBaseToken` and `SellBaseToken` events from `NewBornDODO` and `USTPair` contracts, `DODOSwap` events from `VendingMachine`, `StablePool`, `PrivatePool`, and `GasSavingPool` contracts, `DODOBirth` events from `Zoo` contracts, and `NewDVM`, `NewDSP`, `NewDPP`, and `NewGSP` events from factory contracts, covering Ethereum, Arbitrum, Base, Polygon, and 3 other chains
- **External data**: End-of-day price feeds for traded assets

## 3. Step-by-step calculation

### Component A: Trade event extraction and processing

- **Purpose**: Extract and standardize all DODO trading activity across multiple chains and protocol versions
- **Logic**: Swap events are collected from DODO V1 and V2 contracts deployed across seven blockchain networks. For V1 pools, `BuyBaseToken` and `SellBaseToken` events are parsed to track base and quote asset exchanges. For V2 pools, `DODOSwap` events are parsed from `VendingMachine`, `StablePool`, `PrivatePool`, and `GasSavingPool` contracts. Asset amounts, pool addresses, and transaction metadata are extracted from each event. These events are joined with transaction records to identify the user address (`from_address`) executing each trade.
- **Key fields**: `fromAmount`, `toAmount`, `receiveBase`, `payQuote`, `payBase`, `receiveQuote`, `account_address`, `user_address`, `transaction_hash`, `block_timestamp`, and `log_index`

### Component B: Trading pair identification and asset normalization

- **Purpose**: Map pool addresses to their underlying asset pairs and normalize raw asset amounts using proper decimal places
- **Logic**: A registry of all DODO trading pairs is maintained by analyzing pool creation events, including `DODOBirth` events for V1, and `NewDVM`, `NewDSP`, `NewDPP`, and `NewGSP` events from factory contracts for V2. Mappings are created between pool addresses and their `token0_address` and `token1_address` values. For V2 swaps, since amounts are recorded in the trade direction, the incoming asset address (`fromToken`) is compared against the trading pair registry to correctly orient and assign the base (`token0_amount`) and quote (`token1_amount`) asset amounts. For each trade, asset amounts are normalized by decimal precision. Asset metadata is joined to provide decimal information and to generate human-readable pool names using asset symbols.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, normalized `token0_amount` and `token1_amount`, and `account_name`

### Component C: Fee tier tracking and time-based application

- **Purpose**: Track fee rates over time and apply the correct fee tier to each trade based on when it occurred
- **Logic**: Fee tier updates are monitored from multiple event and function sources, including pool creation functions (which set initial rates) and fee update events (which modify existing rates). Fee tiers include both LP and maintainer components, which are summed together. For most days, fee tiers are forward-filled using the most recent update. However, when multiple fee updates occur within a single day, block-level precision is applied to ensure trades use the correct fee tier based on their exact timing within that day. Special handling is applied for manually created pairs and initial states loaded from external sources.
- **Key fields**: `fee_tier`, `block_timestamp`, `id`, and `next_id`

### Component D: Volume calculation with price conversion

- **Purpose**: Convert normalized asset amounts to USD values and calculate trading volume with anti-manipulation measures
- **Logic**: For each trade, both asset amounts are converted to USD by multiplying normalized amounts by end-of-day asset prices. To prevent manipulation through fake assets or extreme price ratios, the minimum USD value between the two assets involved in each swap is selected. This approach ensures that manipulated assets with inflated prices do not artificially boost volume metrics. The calculation is performed as: `trading_volume = MIN(token0_amount * token0_price_usd, token1_amount * token1_price_usd)`.
- **Key fields**: `token0_price_usd`, `token1_price_usd`, and `trading_volume`

### Component E: Daily active user counting with deduplication

- **Purpose**: Count unique users who executed at least one trade each day across all chains and pools
- **Logic**: active users (daily) are identified by extracting unique `user_address` values from all trading activity within each day. Users are classified as 'Trader' type and deduplicated to ensure unique counts. The active users (daily) calculation spans all chains and pools, ensuring cross-chain users are counted only once per day. Multiple breakdowns are generated, including project-level, chain-level, user-type-level, and product-level aggregations.
- **Key fields**: `user_address`, `user_dau`, `timestamp`, `user_type`, and dimension breakdowns

### Component F: Final aggregation and average calculation

- **Purpose**: Combine trading volume and active user metrics to calculate the average trading volume per user
- **Logic**: Daily trading volumes are summed across all pools, chains, and assets for each day. Daily active user counts are aggregated using the project-level dimension to obtain total unique users across all DODO activity. Both metrics are joined on timestamp to create matched daily pairs. All volume calculations are performed in USD using end-of-day asset prices, with amounts normalized by decimal precision before price multiplication. Both trading volume and active users (daily) are calculated with daily boundaries using UTC day boundaries. Zero-filling strategies are applied to ensure complete time series coverage. Finally, the average trading volume per user is computed as total daily trading volume divided by active users (daily), with safe division applied to handle cases where active user counts are zero or null.
- **Key fields**: `trading_volume`, `user_dau`, and `trading_volume_avg_per_user`

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

Average trading volume (per user)

Trading volume divided by daily active users.

DODODODO

Average trading volume (per user)

Average trading volume (per user)

Competitive landscape