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 Supply-side fees Methodology

## 1. Overview

The portion of trading fees that is distributed to liquidity providers on the DODO decentralized exchange is measured by supply-side fees. This metric is calculated as 80% of the total trading fees collected by DODO pools, with 80% of the collected fees being distributed to liquidity providers and the remaining 20% being allocated to the protocol. Trading volumes are aggregated across all DODO pools, and dynamic fee tiers that are subject to intra-day updates are applied.

## 2. Data sources

- **Blockchain events**: `BuyBaseToken`, `SellBaseToken`, `UpdateLiquidityProviderFeeRate`, and `UpdateMaintainerFeeRate` events from DODO contracts, `DODOSwap` and `LpFeeRateChange` events from DODO V2 `VendingMachine`, `StablePool`, `PrivatePool`, and `GasSavingPool` contracts, `DODOBirth` and `breedDODO` function calls from `Zoo` contracts, pool creation events from `VendingMachineFactory`, `StablePoolFactory`, `PrivatePoolFactory`, and `GasSavingPoolFactory` contracts, and `createDODOStablePool` and `createDODOVendingMachine` function calls from factory 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 event extraction

- **Purpose**: The capture of all swap transactions across DODO pools.
- **Logic**: Swap events are extracted from DODO V1 and V2 contracts. For V1, `BuyBaseToken` and `SellBaseToken` events are parsed to capture base and quote asset amounts. For V2, `DODOSwap` events are parsed from `VendingMachine`, `StablePool`, `PrivatePool`, and `GasSavingPool` contracts. For V2 swaps, asset amounts are oriented into base and quote directions by matching the swap's from-asset with the trading pair's asset configuration. Swap events are joined with transaction records for the identification of user addresses and the verification of transaction validity.
- **Key fields**: `token0_amount`, `token1_amount`, `account_address`, `block_timestamp`, `transaction_hash`, `user_address`

### Component B: Trading pair identification

- **Purpose**: The mapping of pool contract addresses to asset pairs and metadata.
- **Logic**: Trading pairs are identified by extracting asset addresses from pool creation events. For V1, `DODOBirth` events from `Zoo` contracts are used to retrieve base and quote asset addresses. For V2, pool creation events (such as `NewDVM`, `NewDSP`, `NewDPP`, and `NewGSP` events) from factory contracts are parsed to identify pool addresses and their associated assets. These addresses are joined with asset metadata to retrieve decimal precision and symbols, which are concatenated to create trading pair names.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`

### Component C: Fee tier tracking

- **Purpose**: The tracking of dynamic fee rates that are subject to updates over time.
- **Logic**: Fee tier updates are captured from initial pool deployments and subsequent fee rate change events. Initial fee rates are extracted from factory creation function calls and events. Subsequent updates are parsed from events such as `UpdateLiquidityProviderFeeRate`, `UpdateMaintainerFeeRate`, and `LpFeeRateChange`. LP fee rates and maintainer fee rates are tracked separately and summed to determine the total fee tier for each pool. For days with multiple fee updates, transaction ordering is used to apply the correct fee tier to each trade. For days without updates, fee rates are forward-filled.
- **Key fields**: `fee_tier`, `fee_type`, `block_timestamp`, `transaction_hash`, `account_address`

### Component D: Volume calculation and USD conversion

- **Purpose**: The calculation of trading volumes and their normalization to USD.
- **Logic**: Asset amounts are normalized by decimal precision. For days with multiple fee changes, trades are matched to the corresponding fee tier based on transaction ordering. For days with stable fees, forward-filled daily fee rates are applied. Normalized asset amounts are multiplied by end-of-day asset prices to determine USD values. To prevent price manipulation, the trading volume for each swap is calculated as the minimum USD value between the two swapped assets.
- **Key fields**: `trading_volume`, `fee_tier`, `token0_amount`, `token1_amount`, `token0_price_usd`, `token1_price_usd`

### Component E: Supply-side fee calculation and aggregation

- **Purpose**: The calculation of final supply-side fees and their aggregation.
- **Logic**: Total fees are calculated by multiplying the aggregated trading volume by the total fee tier for each pool. A 80% supply-side allocation factor is applied to the total fees to determine the portion distributed to liquidity providers, with the remaining 20% allocated to the protocol. Daily values are aggregated to UTC day boundaries.
- **Key fields**: `fees`, `fees_supply_side`, `timestamp`

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

Portion of fees distributed to service providers or supply-side participants.

DODODODO

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown