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 Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Tokenlon measures the count of unique user addresses that executed at least one trade on the Tokenlon DEX aggregator platform within any 7-day rolling window. This metric provides insight into the platform's weekly user engagement and trading activity across its various smart contract versions and supported blockchains. The calculation uses HyperLogLog aggregation for efficient processing of large user datasets and provides breakdowns by chain, user type, and product dimensions.

## 2. Data sources

The calculation relies on several blockchain and external data sources:

- **Tokenlon smart contract events**: Parsed trading events from multiple Tokenlon contract versions including `Fill`, `Swapped`, `FillOrder`, and `LimitOrderFilledByProtocol` events from Ethereum and Arbitrum blockchains
- **Transaction records**: Ethereum and Arbitrum transaction data used to identify the actual user addresses (transaction initiators) for each trade
- **Token metadata**: Information for resolving token addresses and handling native token to wrapped token conversions (ETH to WETH)
- **Contract address filtering**: Specific Tokenlon contract addresses used to filter relevant trading events

The primary events captured include:
- Ethereum: `ZeroExchange_Fill_event`, `AMMWrapper_Swapped_event`, `AMMWrapperWithPath_Swapped_event`, `PMM_FillOrder_event`, `RFQ_FillOrder_event`
- Arbitrum: `LimitOrder_LimitOrderFilledByProtocol_event`

## 3. Step-by-step calculation

### Component A: Trade event processing
- **Purpose**: Extract and standardize trading activity from various Tokenlon smart contracts
- **Logic**: Parse multiple types of trading events from Tokenlon contracts across Ethereum and Arbitrum. Filter events by specific Tokenlon addresses (particularly `0xb9e29984fe50602e7a619662ebed4f90d93824c7`). Extract token addresses from encoded event data and convert native token addresses (`0x0000000000000000000000000000000000000000`) to their wrapped equivalents (WETH). Join with transaction data to identify the actual user address from `from_address` rather than event parameters.
- **Key fields**: `block_timestamp`, `transaction_hash`, `user_address`, `token0_address`, `token1_address`, `token0_amount`, `token1_amount`, `chain`

### Component B: Daily active users calculation  
- **Purpose**: Identify unique trader addresses for each day
- **Logic**: Group trading events by day using `timestamp_trunc` on `block_timestamp`. Extract distinct `user_address` values for each day, chain, and other dimensions. Classify all users as "Trader" user type since they executed trades. Apply chain availability filters to ensure data completeness.
- **Key fields**: `timestamp` (daily), `chain`, `user_type`, `product_id`, `user_dau`

### Component C: HyperLogLog aggregation preparation
- **Purpose**: Convert daily user sets into efficient HyperLogLog format for aggregation
- **Logic**: Transform daily active user lists into HyperLogLog sketches using `hll_count.init` with precision 15. This allows efficient storage and merging of user sets across time windows without storing actual user addresses. Group by timestamp, chain, user type, and product dimensions.
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component D: Rolling window creation
- **Purpose**: Generate 7-day rolling windows for each date
- **Logic**: Create a datespine covering all dates from the earliest data to current date. For each date in the datespine, generate 7 "joindays" representing the current day plus the 6 preceding days. This creates overlapping 7-day windows that slide forward one day at a time. Handle incremental processing by filtering based on table modification times.
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 7-day window)

### Component E: Window-based HLL aggregation
- **Purpose**: Aggregate unique users across 7-day rolling windows
- **Logic**: Join the rolling window structure with daily HLL data. For each target date, collect all HLL sketches from the corresponding 7-day window. This creates multiple rows per target date (one for each day in the window) that will be merged in the next step.
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll`

### Component F: Multi-dimensional breakdowns
- **Purpose**: Create user counts across different analytical dimensions
- **Logic**: Generate four separate dimensional views by grouping the windowed data differently:
1. Project-level: Aggregate across all chains and user types for overall platform WAU
2. Chain-level: Break down by individual blockchain (Ethereum, Arbitrum)  
3. User type-level: Break down by user classification (all "Trader" for Tokenlon)
4. Product-level: Break down by product categories (null for Tokenlon as it's a single product)

For each breakdown, merge HLL sketches using `hll_count.merge_partial` and extract final counts using `hll_count.extract`.
- **Key fields**: `dimensions`, `chain_id`, `user_type`, `product_id`, `user_wau`

### Final aggregation
- **Combining components**: Union all four dimensional breakdowns into a single result set with standardized schema including dimension type identifiers
- **Time aggregation**: Daily boundaries using `timestamp_trunc` to day level, with 7-day rolling windows applied
- **Final calculation**: The `user_wau` field contains the count of unique user addresses that traded within each 7-day rolling window, calculated by extracting the cardinality from merged HyperLogLog sketches
- **Output formatting**: Apply the `finalize_metric_user_wau` macro to standardize the output schema and fill missing dates with zero values to ensure complete time series

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

Unique revenue-generating users over a rolling 7-day window.

TokenlonLON

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown