Traders exchange funds through request for quotation system built on 0x protocol and aggregated AMMs. Tokenlon collects a trading fee (revenue) from trades.

Tokenlon is a non-custodial exchange protocol built on Ethereum. Tokenlon was founded by imToken team and launched in 2018.

LON tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). Tokelon's investors include IDG Capital, Qiming Venture Partners, Breyer Capital, etc.

governance

github

twitter

discord

etherscan

website

DEX aggregators

Tokenlon

# Tokenlon Trade count Methodology

## 1. Overview

The Tokenlon trade count metric measures the daily number of unique trades executed through the Tokenlon DEX aggregator protocol. This metric counts distinct transactions that resulted in token swaps across Tokenlon's various contract versions on Ethereum and Arbitrum. Each trade is identified by its unique transaction hash, ensuring that multi-step or complex trades within a single transaction are counted as one trade rather than multiple separate events.

## 2. Data sources

- **Blockchain events**: Parsed trade execution events from Tokenlon smart contracts across Ethereum and Arbitrum, including `Fill`, `Swapped`, `FillOrder`, and `LimitOrderFilledByProtocol` events from various contract versions (AMM wrappers, PMM, RFQ, limit orders)
- **Transaction data**: Ethereum and Arbitrum transaction records containing user addresses and transaction metadata
- **Token metadata**: Token information including symbols and decimal precision for proper amount conversion
- **External data**: End-of-day token price feeds for USD conversion and trade validation

## 3. Step-by-step calculation

### Component A: Raw trade event extraction
- **Purpose**: Extract and standardize trade events from multiple Tokenlon contract versions and chains
- **Logic**: Query blockchain event logs from six different Tokenlon contract types across Ethereum and Arbitrum. Filter events to include only those where Tokenlon's main contract address (`0xb9e29984fe50602e7a619662ebed4f90d93824c7`) is involved as either fee recipient or taker address. Extract token pair information, trade amounts, and transaction metadata from each event type. Handle different event schemas by mapping event-specific field names to standardized columns. Convert native token placeholder addresses (zero address) to their wrapped equivalents (WETH on Ethereum, WARB on Arbitrum). Join with transaction records to obtain user addresses for each trade.
- **Key fields**: `transaction_hash`, `log_index`, `block_timestamp`, token addresses, trade amounts, user addresses

### Component B: Trade volume calculation and validation
- **Purpose**: Convert raw trade data to USD values for validation and apply decimal corrections
- **Logic**: Join standardized trade events with token metadata to obtain decimal precision for each token in the trading pair. Apply decimal correction by dividing raw token amounts by 10 raised to the power of token decimals. Join with end-of-day price feeds for both tokens in each pair to convert decimal-corrected amounts to USD values. Apply anti-manipulation logic by taking the lesser of the two USD amounts (token0 amount × price vs token1 amount × price) to prevent inflated values from potential price manipulation. Group trades by transaction hash, log index, timestamp, chain, and business dimensions while summing amounts for any duplicate entries.
- **Key fields**: `token0_amount`, `token1_amount`, `trading_volume`, token symbols and decimals, USD prices

### Component C: Daily trade count aggregation  
- **Purpose**: Count unique trades per day across all chains and contract versions
- **Logic**: Truncate trade timestamps to daily boundaries and group by date, chain, market sector, business segment, and product dimensions. Use approximate count distinct function on transaction hashes to count unique trades per day, which treats all events within the same transaction as a single trade regardless of how many token transfers or events occurred. This approach ensures that complex multi-step trades or transactions with multiple log events are counted as one trade.
- **Key fields**: `timestamp`, `transaction_hash`, `chain_id`, business dimension fields

### Final aggregation
- **Combining components**: Trade events flow from raw extraction through volume validation to final counting without additional combining steps
- **Currency conversion**: USD conversion occurs during volume validation phase using end-of-day price feeds, though the final metric only counts trades rather than summing volumes
- **Time aggregation**: All trades are aggregated to daily level using timestamp truncation to day boundaries
- **Final calculation**: Apply finalization macro with 'fill_zeros' strategy to ensure consistent time series by filling missing dates with zero trade counts. Apply chain availability filtering to exclude data from chains during periods when they were not yet supported or tracked.

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

Number of trades executed on a decentralized exchange.

TokenlonLON

Trade count

Trade count

Competitive landscape

Chain breakdown