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 revenue per user (ARPU) Methodology

## 1. Overview

Average revenue per user (ARPU) is calculated as the daily protocol revenue divided by the number of active users (daily). The average economic value generated per active user over a fixed 24-hour window is measured by this metric. The platform's capacity to monetize its user base across various DODO liquidity pools, including Vending Machine, Stable Pool, Private Pool, and Gas Saving Pool, is reflected in this calculation. Active users (daily) are defined as unique traders initiating transactions on the protocol.

## 2. Data sources

- **Revenue**: Derived from the Revenue metric
- **Active users (daily)**: Derived from the Active users (daily) metric

## 3. Step-by-step calculation

### Component A: Trade event extraction

- **Purpose**: Identify all trading activity and user addresses across DODO protocol versions
- **Logic**: Swap events are extracted from DODO contracts (`BuyBaseToken` and `SellBaseToken` events) and DODO contracts (`DODOSwap` events from `VendingMachine`, `StablePool`, `PrivatePool`, and `GasSavingPool` contracts). These events are joined with blockchain transaction records to capture the user address initiating the trade. For V2 contracts, the trade amounts are oriented into base and quote asset amounts by comparing the trade direction asset address with the pool's asset addresses from the trading pairs dimension. Unique transaction identifiers are generated using block numbers and log indexes.
- **Key fields**: `user_address`, `token0_amount`, `token1_amount`, `account_address`, `block_timestamp`, `transaction_hash`

### Component B: Fee tier tracking

- **Purpose**: Determine the applicable fee rates for each pool
- **Logic**: Fee tier information is collected from pool initialization functions and subsequent fee update events, including `UpdateLiquidityProviderFeeRate`, `UpdateMaintainerFeeRate`, and `LpFeeRateChange` events. Liquidity provider fees and maintainer fees are summed to calculate the total fee rate. Forward-fill logic is applied to ensure a valid fee tier is available for every operating day. Multiple updates within a single day are resolved by tracking block-level granularity.
- **Key fields**: `fee_tier`, `account_address`, `block_timestamp`

### Component C: Trading volume calculation

- **Purpose**: Convert raw asset amounts to USD trading volumes
- **Logic**: Trade events are joined with trading pair metadata to retrieve asset decimals. Asset amounts are normalized by decimal precision. Normalized amounts are multiplied by end-of-day asset prices from price feeds. To mitigate price manipulation effects, the minimum USD value between the two assets in each trade is selected as the trading volume. The appropriate fee tier is applied based on the trade timestamp and pool address.
- **Key fields**: `trading_volume`, `fee_tier`, `token0_amount`, `token1_amount`, `token0_price_usd`, `token1_price_usd`

### Component D: Fee and revenue calculation

- **Purpose**: Calculate total fees collected and protocol revenue
- **Logic**: Trading volume is multiplied by the applicable fee tier to calculate total fees collected. Fees are aggregated daily across all pools. Protocol revenue is calculated by applying a 20% allocation rate to the total fees collected, representing the portion retained by the protocol.
- **Key fields**: `fees`, `revenue`

### Component E: Daily active user counting

- **Purpose**: Count unique daily traders
- **Logic**: Distinct user addresses are extracted from daily trade events. Unique active users (daily) are aggregated to daily granularity with UTC day boundaries.
- **Key fields**: `user_dau`, `user_address`

### Component F: Average revenue per user calculation

- **Purpose**: Calculate the daily average revenue per user
- **Logic**: Daily protocol revenue is divided by the daily active user count. Zero-filling is applied for days with missing data to maintain a continuous time series.
- **Key fields**: `arpu`, `revenue`, `user_dau`

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

DODODODO

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape