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

## 1. Overview

DODO revenue is measured as the portion of trading fees that is retained by the DODO protocol as revenue. DODO is operated as a decentralized exchange (DEX) utilizing proactive market maker (PMM) algorithms across multiple chains. The revenue metric is calculated as 20% of total trading fees collected, representing the protocol's share of the fees paid by traders. This metric is used to determine the volume of revenue generated by the DODO protocol from trading activities.

## 2. Data sources

On-chain and off-chain data sources are utilized for the calculation:

- **Blockchain events**: `DODOBirth`, `BuyBaseToken`, `SellBaseToken`, `UpdateLiquidityProviderFeeRate`, and `UpdateMaintainerFeeRate` events and `breedDODO` function calls from DODO contracts; `NewDVM`, `NewDSP`, `NewDPP`, `NewGSP`, `DODOSwap`, and `LpFeeRateChange` events and `createDODOStablePool` and `createDODOVendingMachine` function calls from DODO contracts, covering Ethereum, BSC, Polygon, Arbitrum, and 3 other chains
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Trading pair identification

- **Purpose**: Trading pairs and their asset configurations are identified.
- **Logic**: Trading pairs are extracted from pool creation events, including `DODOBirth` events from `Zoo` contracts and `BuyBaseToken` and `SellBaseToken` events from `USTPair` contracts for V1, and `NewDVM`, `NewDSP`, `NewDPP`, and `NewGSP` events from their respective factory contracts for V2. For each pair, the pool contract address, base asset address, quote asset address, and chain information are captured. These records are enriched with asset metadata to obtain decimal precision and symbols.
- **Key fields**: `account_address` (pool contract), `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name` (asset symbol pair)

### Component B: Fee tier tracking

- **Purpose**: Fee rates charged by each DODO pool are tracked over time.
- **Logic**: Fee tier information is collected from pool creation functions and fee update events. Fee rates are normalized by decimal precision. Both liquidity provider fees and maintainer fees are handled and summed together to determine the total fee rate. Forward-fill logic is used to propagate fee rates across time periods, with block-level granularity applied for days with intra-day updates.
- **Key fields**: `fee_tier` (normalized fee rate), `account_address`, `fee_type` (LP or maintainer), `block_timestamp`

### Component C: Trade event processing

- **Purpose**: Trading activity on DODO pools is captured.
- **Logic**: Swap events are extracted from DODO contracts (`BuyBaseToken` and `SellBaseToken` events) and DODO contracts (`DODOSwap` events from `VendingMachine`, `StablePool`, `PrivatePool`, and `GasSavingPool` contracts). For V2 swaps, asset amounts are oriented based on the trade direction by comparing the starting asset with the trading pair configuration, flipping the amounts when the swap starts from the quote asset. For each trade, asset amounts, pool addresses, and user addresses are recorded. Absolute values of asset amounts are used to ensure consistent volume calculations.
- **Key fields**: `token0_amount`, `token1_amount`, `account_address`, `user_address`, `block_timestamp`

### Component D: Volume calculation with fee tier application

- **Purpose**: USD trading volumes are calculated with appropriate fee tiers applied.
- **Logic**: Trade events are joined with trading pair data and fee tier information. Asset amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. Trading volume is calculated as the minimum USD value between the two assets to prevent price manipulation. Fee tiers are applied based on timing, where daily forward-filled rates are used for most trades, and block-level granularity is applied for days with intra-day fee updates.
- **Key fields**: `trading_volume` (USD), `fee_tier`, `token0_price_usd`, `token1_price_usd`

### Component E: Fee aggregation and revenue calculation

- **Purpose**: Trading fees are aggregated and the protocol's share is calculated as revenue.
- **Logic**: Trading volumes are aggregated by day and chain, then multiplied by their corresponding fee tiers to calculate total fees collected. Revenue is calculated by applying a 20% protocol take rate to the total fees collected. All values are converted to USD using end-of-day price feeds and aggregated to daily boundaries.
- **Key fields**: `fees` (USD), `revenue` (USD)

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

DODODODO

Revenue

Revenue

Competitive landscape

Chain breakdown