Liquidity providers deposit funds into Camelot and receive trading fees from traders (supply-side fees).

Camelot is a non-custodial exchange protocol built on Arbitrum. Camelot was founded by the pseudonymous Myrddin and launched in 2022.

GRAIL tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

github

twitter

discord

etherscan

website

Exchanges (DEX)

Camelot

# Camelot Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who conducted at least one trade on the Camelot DEX within any 7-day period. This metric provides insight into user engagement and platform activity over a rolling weekly window. The calculation uses HyperLogLog (HLL) data structures for efficient distinct user counting across time windows and provides breakdowns across multiple dimensions including chain, user type, and product level.

## 2. Data sources

The WAU calculation relies on the following raw data sources:

- **Arbitrum blockchain events**: Parsed `Swap` events from Camelot V2 (`Pair_Swap_event`) and Camelot V3 (`Pool_Swap_event`) smart contracts on Arbitrum, containing swap transaction details including amounts, timestamps, and contract addresses
- **Arbitrum transaction data**: Transaction records from the Arbitrum blockchain that provide user addresses (`from_address`) for each swap transaction, linking trading activity to specific users
- **Blockchain timestamp data**: Block timestamps from Arbitrum for temporal ordering and daily aggregation of trading activity

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identify unique traders for each day based on Camelot swap activity
- **Logic**: Extract all swap events from both Camelot V2 and V3 protocols on Arbitrum. Join swap events with Arbitrum transaction data to obtain the user address (`from_address`) for each trade. Truncate block timestamps to day boundaries to group trading activity by calendar day. Classify all users as 'Trader' type since the metric focuses specifically on trading activity rather than other protocol interactions.
- **Key fields**: `block_timestamp` truncated to day for temporal grouping, `user_address` from transaction `from_address` for user identification, `chain` set to 'arbitrum', `user_type` set to 'Trader'

### Component B: HyperLogLog initialization
- **Purpose**: Convert daily user sets into efficient data structures for distinct counting across time windows
- **Logic**: Transform the daily active user data into HyperLogLog (HLL) sketches with precision parameter 15. Group users by day, chain, user type, and product dimensions. Initialize one HLL sketch per day containing all unique users who traded that day. This probabilistic data structure enables efficient merging and distinct counting across multiple days without storing individual user identifiers.
- **Key fields**: `timestamp` for daily grouping, `hll` containing the HyperLogLog sketch of users, dimensional fields for `chain_id`, `user_type`, and `product_id`

### Component C: Time coverage datespine
- **Purpose**: Ensure complete temporal coverage for rolling window calculations
- **Logic**: Generate a continuous sequence of daily timestamps from the earliest trade date to yesterday using timestamp array generation. This datespine prevents gaps in the time series that could occur when no trading activity happened on specific days. The spine covers the full historical period and handles incremental updates by extending from the last modified time minus a safety margin.
- **Key fields**: `timestamp` representing each calendar day in the complete time range

### Component D: Rolling window construction  
- **Purpose**: Create 7-day rolling windows for each date to calculate weekly active users
- **Logic**: For each date in the datespine, generate a 7-day window consisting of that date plus the previous 6 days. Use the `jointables` CTE to create mappings between each target date and all days in its corresponding 7-day lookback period. This approach ensures every day has a complete 7-day window for WAU calculation, even when some days within the window had no trading activity.
- **Key fields**: `timestamp` as the target date, `joinday` representing each day within the 7-day window

### Component E: Window aggregation
- **Purpose**: Combine daily user data across 7-day windows using HyperLogLog operations
- **Logic**: Join the rolling window mappings with the daily HLL data to bring together all user sketches within each 7-day period. For each target date, merge the HLL sketches from all 7 days in its window using `hll_count.merge_partial()` operations. Extract the final distinct count using `hll_count.extract()` to get the number of unique users who traded at least once during the 7-day period.
- **Key fields**: `timestamp` for the target date, merged `hll` sketches across the 7-day window, dimensional grouping fields

### Component F: Dimensional breakdowns
- **Purpose**: Calculate WAU across different grouping levels for analytical flexibility
- **Logic**: Compute four separate dimensional views of WAU data. First, project-level WAU aggregates all users across all dimensions. Second, chain-level WAU groups by blockchain (though Camelot only operates on Arbitrum). Third, user-type-level WAU groups by user classification (all 'Trader' type). Fourth, product-level WAU groups by specific product or version identifiers. Each breakdown uses HLL merge operations to combine user sketches appropriately, then applies UNION ALL to combine all dimensional views into a single output table.
- **Key fields**: `dimensions` indicating the grouping level, `chain_id`, `user_type`, `product_id` populated based on the specific dimensional breakdown, `user_wau` containing the final count

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project-level, chain-level, user-type-level, product-level) into a single comprehensive dataset using UNION ALL operations
- **Time aggregation**: Daily boundary logic based on truncating block timestamps to day level, with rolling 7-day windows calculated for each calendar day
- **Final calculation**: The `user_wau` value represents the count of distinct users who executed at least one trade within any 7-day rolling window, calculated by merging daily HyperLogLog sketches and extracting the final distinct count. The `finalize_metric_user_wau` macro applies standardized formatting, fills missing dates with zero values, and ensures consistent schema output across all Token Terminal metrics.

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

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

CamelotGRAIL

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown