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 Trade count Methodology

## 1. Overview

The daily number of unique trading transactions executed on the DODO decentralized exchange is measured by the trade count metric. Distinct transactions containing swap events from DODO V1 and V2 protocols are counted to provide insight into daily trading activity and user engagement. Swap events are aggregated by transaction hash to ensure each user transaction is counted only once, regardless of the number of individual swap events contained within it.

## 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; `NewDVM`, `NewDSP`, `NewDPP`, and `NewGSP` events from their respective factory contracts; and fee-related events and function calls (including `UpdateLiquidityProviderFeeRate`, `UpdateMaintainerFeeRate`, and `LpFeeRateChange` events, and `breedDODO`, `createDODOStablePool`, and `createDODOVendingMachine` function calls) from DODO V1 and V2 contracts, covering Ethereum, BSC, Polygon, Arbitrum, Base, and 2 other chains
- **External data**: End-of-day price feeds for traded assets, and asset metadata

## 3. Step-by-step calculation

### Component A: Raw trade event extraction

- **Purpose**: Extract all swap transactions from DODO contracts across supported chains
- **Logic**: Parsed contract events are queried from DODO V1 and V2 protocols. For V1, `BuyBaseToken` and `SellBaseToken` events are captured from `NewBornDODO` and `USTPair` contracts. For V2, `DODOSwap` events are captured from `VendingMachine`, `StablePool`, `PrivatePool`, and `GasSavingPool` contracts. To correctly orient base and quote asset amounts for V2 swaps, the `fromToken` field is matched against the trading pair configuration to assign `token0_amount` and `token1_amount` based on the trade direction. These events are joined with blockchain transaction records to identify user addresses. Transaction hashes, block timestamps, log indexes, contract addresses, and asset amounts are extracted for each swap.
- **Key fields**: `transaction_hash`, `block_timestamp`, `log_index`, `account_address`, `user_address`, `token0_amount`, `token1_amount`, `chain`

### Component B: Trading pair configuration

- **Purpose**: Map DODO pool contracts to their underlying asset pairs
- **Logic**: Trading pair configurations are extracted from DODO contract deployment events. For V1, `DODOBirth` events from `Zoo` contracts are used to identify base and quote assets, alongside manual configurations for specific pairs. For V2, pool creation events—including `NewDVM` from `VendingMachineFactory` contracts, `NewDSP` from `StablePoolFactory` contracts, `NewDPP` from `PrivatePoolFactory` contracts, and `NewGSP` from `GasSavingPoolFactory` contracts—are parsed to identify pool addresses and their underlying asset pairs. These configurations are joined with asset metadata to retrieve decimal precision and symbols for proper conversion and naming.
- **Key fields**: `account_address`, `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`, `chain`

### Component C: Fee tier processing

- **Purpose**: Track fee tier changes for accurate trade classification
- **Logic**: Fee tier updates are extracted from contract events and function calls, including liquidity provider fee rate changes and maintainer fee changes. Initialization is handled via pool creation functions, while runtime updates are captured via dedicated events. Fee tiers are forward-filled daily for pools with stable fees, whereas block-level precision is applied for days with multiple fee changes. Liquidity provider fees and maintainer fees are combined to calculate the total fee tier per pool.
- **Key fields**: `fee_tier`, `account_address`, `chain`, `timestamp`, `fee_type`

### Component D: Volume calculation and validation

- **Purpose**: Convert raw asset amounts to USD values with manipulation filtering
- **Logic**: Trades are joined with trading pair data to retrieve asset decimals, and asset amounts are normalized by decimal precision. These records are joined with end-of-day price feeds for both assets in each pair. USD values are calculated for both assets, and the lesser amount is used to filter out potential price manipulation attempts. Fee tier information is applied based on the exact timing of trades relative to fee changes.
- **Key fields**: `trading_volume`, `token0_price_usd`, `token1_price_usd`, `fee_tier`

### Component E: Trade aggregation

- **Purpose**: Combine processed trades with proper fee tier matching
- **Logic**: Trades from days with single daily fee updates are unioned with trades from days having multiple intraday fee updates. For intraday fee changes, each trade is matched to the correct fee tier based on block ranges. Data is grouped by trade-level dimensions, and the maximum fee tier is selected to handle potential duplicates arising from fee tier processing.
- **Key fields**: All trade fields plus validated `fee_tier` and USD `trading_volume`

### Component F: Final aggregation

- **Purpose**: Aggregate trade counts on a daily level and apply final filters
- **Logic**: Processed trades are grouped by daily timestamp, chain, and product dimensions. The distinct count of transaction hashes is calculated per day per grouping dimension. A zero-filling strategy is applied to ensure complete time series coverage. Chain availability filtering is applied to exclude periods when specific chains were not yet supported.
- **Key fields**: `timestamp`, `chain_id`, `product_id`, `trade_count`

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

Number of trades executed on a decentralized exchange.

DODODODO

Trade count

Trade count

Competitive landscape

Chain breakdown