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 Average trading volume (per user) Methodology

## 1. Overview

The trading volume average per user metric measures the average USD trading volume per daily active user on the Camelot decentralized exchange. This metric helps assess user engagement intensity by dividing the total daily trading volume by the number of unique daily active traders. It indicates how much volume each user generates on average and can reveal whether growth is driven by more users or higher per-user activity.

## 2. Data sources

The calculation relies on several raw blockchain data sources:
- **Swap events**: Parsed `Pair_Swap_event` logs from Camelot v2 and `Pool_Swap_event` logs from Camelot v3 on Arbitrum, containing token amounts and trading pair addresses
- **Factory events**: Parsed `Factory_PairCreated_event` logs from Camelot v2 and `Factory_Pool_event` logs from Camelot v3, providing trading pair creation data with token addresses
- **Fee events**: Parsed `Pool_Fee_event` logs from Camelot v3 pools, capturing fee tier updates
- **Transaction data**: Arbitrum transaction records linking swap events to user addresses through the `from_address` field
- **Token metadata**: Token information including decimals and symbols for amount normalization and pair naming
- **External data**: End-of-day token price feeds providing USD conversion rates for traded tokens

## 3. Step-by-step calculation

### Component A: Trade event processing
- **Purpose**: Extract and standardize swap events from both Camelot v2 and v3 protocols
- **Logic**: Raw swap events are collected from both protocol versions on Arbitrum. For v2 swaps, token amounts are calculated as the difference between `amount0In` minus `amount0Out` and `amount1In` minus `amount1Out`. For v3 swaps, the `amount0` and `amount1` values are used directly. Each trade is assigned a unique identifier using block number and log index. Transaction records are joined to identify the user address (`from_address`) executing each swap
- **Key fields**: `token0_amount`, `token1_amount`, `user_address`, `account_address` (trading pair), `block_timestamp`

### Component B: Trading pair enrichment  
- **Purpose**: Add token metadata and fee information to enable volume calculations
- **Logic**: Trading pair data is extracted from Factory creation events, mapping each pair address to its constituent token addresses. Token metadata is joined to provide decimal places for amount normalization and symbols for pair naming. For v3 pools, fee tier information is joined from fee update events based on matching account address, block number, and version
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`

### Component C: Volume calculation and USD conversion
- **Purpose**: Convert token amounts to USD trading volume with price manipulation protection
- **Logic**: Token amounts are normalized by dividing by 10 raised to the token's decimal places, then converted to absolute values. End-of-day token prices are joined for both tokens in each trading pair. Each token amount is multiplied by its respective USD price. To filter out potential price manipulation, the trading volume for each swap is set to the lesser of the two token USD values using the `least()` function. This approach ensures that artificially inflated prices on one side of a trade don't skew the volume calculation
- **Key fields**: `trading_volume` (in USD), calculated as the minimum of `token0_amount * token0_price` and `token1_amount * token1_price`

### Component D: Daily active user counting
- **Purpose**: Count unique daily traders using HyperLogLog for scalable distinct counting
- **Logic**: All swap events are grouped by day with timestamps truncated to day boundaries. For each day, unique user addresses are counted using HyperLogLog aggregation functions for memory-efficient distinct counting. Users are classified as 'Trader' type. The HyperLogLog approach allows for accurate distinct user counting even with large datasets while supporting various dimensional breakdowns
- **Key fields**: `user_dau` representing the count of distinct daily active users

### Final aggregation  
- **Combining components**: Daily trading volumes are summed across all swaps for each day. Daily active user counts are taken as the maximum value (since there's one aggregated count per day). Both metrics are joined on the same timestamp to ensure alignment
- **Currency conversion**: All trading volumes are already converted to USD during the volume calculation step using end-of-day token prices
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation to day level
- **Final calculation**: The average trading volume per user is calculated by dividing the total daily trading volume by the daily active user count using the `safe_divide()` function to handle cases where user count might be zero

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

Average trading volume (per user)

Trading volume divided by daily active users.

CamelotGRAIL

Average trading volume (per user)

Average trading volume (per user)

Competitive landscape