DEX aggregators

Oku Trade

# Oku Trade Revenue Methodology

## 1. Overview

Oku Trade's revenue metric tracks income generated from advance orders on their Uniswap v3-style DEX. Currently, since no advance orders exist, the revenue is always zero regardless of trading activity or fees generated. The metric is built on the underlying fee calculation structure but explicitly sets revenue to zero for all time periods.

## 2. Data sources

The revenue calculation (though resulting in zero) is built upon:
- **Blockchain events**: Parsed XDC blockchain events including `Factory_PoolCreated`, `Pool_Swap`, and `Pool_Flash` events from Oku Trade's Uniswap v3-style contracts
- **Transaction data**: XDC transaction records to identify user addresses and transaction context
- **External data**: End-of-day token price feeds for USD conversion and token metadata including symbols and decimal places
- **Pool data**: Trading pair information including fee tiers, token addresses, and pool configurations

## 3. Step-by-step calculation

### Component A: Trading pair identification
- **Purpose**: Identifies all Uniswap v3-style trading pairs and their associated fee structures
- **Logic**: Extracts `Factory_PoolCreated` events from XDC blockchain to identify pool addresses, token0 and token1 addresses, and fee tiers. Fee tiers are converted from raw values to decimal percentages by dividing by 10^6. Token metadata is joined to get decimal places and symbols for proper pair naming
- **Key fields**: `pool` address as account_address, `token0` and `token1` addresses, `fee` tier for commission rates, token `decimals` for amount adjustments

### Component B: Trading volume calculation
- **Purpose**: Calculates daily USD trading volumes from regular swap transactions
- **Logic**: Processes `Pool_Swap` events from XDC blockchain, joins with trading pair data to get token decimals and fee information. Raw token amounts are converted to proper decimal representation by dividing by 10^token_decimals. Both token amounts are converted to USD using end-of-day price feeds. To prevent price manipulation, the calculation takes the minimum USD value between token0 and token1 amounts for each swap. Results are aggregated daily
- **Key fields**: `amount0` and `amount1` representing token swap amounts, `block_timestamp` for daily aggregation, `sender` for contract interaction tracking

### Component C: Flash loan volume calculation
- **Purpose**: Calculates daily USD volumes from flash loan transactions
- **Logic**: Processes `Pool_Flash` events from XDC blockchain using the same token decimal adjustments and USD conversion as regular trades. However, unlike regular swaps, flash loan volumes sum both token USD values rather than taking the minimum, as flash loans represent temporary borrowing rather than price-sensitive trading. Results are aggregated daily by trading pair
- **Key fields**: `amount0` and `amount1` representing flash loan amounts, `sender` for tracking flash loan initiators

### Component D: Fee calculation
- **Purpose**: Calculates fees that would be generated from trading and flash loan activity
- **Logic**: Multiplies daily trading volumes by their respective fee tiers to calculate fees from regular swaps. Similarly multiplies flash loan volumes by fee tiers to calculate flash loan fees. Combines both fee sources and aggregates by day, chain, and product. These fees represent what would be collected by liquidity providers in the protocol
- **Key fields**: `trading_volume` and `flash_loan_volume` multiplied by `fee_tier` percentages

### Final aggregation
- **Combining components**: The model references the complete fee calculation structure but explicitly overrides all fee amounts with zero for revenue purposes
- **Currency conversion**: All underlying calculations use end-of-day USD price feeds for consistent valuation
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation
- **Final calculation**: Revenue is hardcoded to 0 for all records, regardless of the underlying fee structure, because Oku Trade's revenue model is based on advance orders which are not currently implemented

*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.

Oku Trade

Revenue

Revenue

Competitive landscape

Chain breakdown