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 Tradeable assets Methodology

## 1. Overview

The tradeable assets metric measures the cumulative number of unique tokens available for trading on Camelot DEX, categorized by liquidity cohorts. This metric answers the question "How many tokens can users trade on Camelot, and how are they distributed by liquidity depth?" The calculation tracks all tokens that appear in trading pairs across Camelot v2 and v3 protocols, then classifies them based on their total liquidity across all pairs.

## 2. Data sources

- **Trading pair creation events**: Parsed `Factory_PairCreated_event` logs from Camelot v2 and `Factory_Pool_event` logs from Camelot v3 on Arbitrum, containing token addresses for each trading pair
- **Reserve update events**: Parsed `Pair_Sync_event` logs from Camelot v2 pairs on Arbitrum, tracking reserve amounts for both tokens in each pair
- **Liquidity provider events**: Parsed `Pool_Mint_event` and `Pool_Collect_event` logs from Camelot v3 pools on Arbitrum, capturing deposit and withdrawal amounts
- **Trading events**: Parsed `Pair_Swap_event` logs from Camelot v2 and `Pool_Swap_event` logs from Camelot v3 on Arbitrum, tracking token amount changes from trades
- **Transaction data**: Arbitrum transaction records providing user addresses and transaction metadata
- **Token metadata**: Token information including decimal places and symbols for proper amount calculations
- **Price data**: End-of-day token price feeds for USD conversion of liquidity amounts

## 3. Step-by-step calculation

### Component A: Trading pair identification
- **Purpose**: Identify all unique tokens available for trading by extracting them from trading pair creation events
- **Logic**: Extract token addresses from Camelot v2 `Factory_PairCreated_event` logs using the `pair` field to get the pair contract address, and from Camelot v3 `Factory_Pool_event` logs using the `pool` field. Each event contains `token0` and `token1` addresses representing the two tokens in the trading pair. Join with token metadata to get decimal places and symbols for each token. Create a comprehensive list of all trading pairs with their token addresses, decimals, and creation timestamps.
- **Key fields**: `pair` or `pool` contract addresses, `token0` and `token1` addresses, `block_timestamp` for creation time, token `decimals` and `symbol` from metadata

### Component B: Asset flow tracking
- **Purpose**: Track all token movements (deposits, withdrawals, trades) to calculate liquidity changes over time
- **Logic**: For v2 pairs, extract reserve changes from `Pair_Sync_event` logs containing `reserve0` and `reserve1` amounts, then calculate daily reserve differences using lag functions. For v3 pools, combine liquidity provider deposits from `Pool_Mint_event` logs, withdrawals from `Pool_Collect_event` logs (with negative amounts), and trading activity from `Pool_Swap_event` logs. All amounts are corrected for token decimals by dividing by 10 raised to the power of each token's decimal places. Aggregate all flows on a daily basis by timestamp truncation.
- **Key fields**: `reserve0` and `reserve1` amounts from sync events, `amount0` and `amount1` from mint/collect events, swap amounts from trade events, corrected by `decimals`

### Component C: Net deposit calculation
- **Purpose**: Calculate the net USD value of liquidity for each token across all trading pairs
- **Logic**: Apply DEX-specific net deposit calculations to the aggregated asset flows using the `calculate_dex_net_deposits` macro. This combines deposits, withdrawals, and trading impacts to determine the net change in liquidity for each token in each pair on each day. Convert token amounts to USD by multiplying corrected amounts with end-of-day token prices. Sum the USD values across all pairs for each unique token to get total token liquidity.
- **Key fields**: Calculated `net_deposits` in USD, `token0_address` and `token1_address`, daily `timestamp`, `price_usd` from price feeds

### Component D: Liquidity cohort classification
- **Purpose**: Categorize tokens based on their total liquidity depth to create meaningful groupings
- **Logic**: For each token, calculate the sum of net deposits across all trading pairs where the token appears. Classify tokens into cohorts based on total liquidity: greater than 1 million USD, 500 thousand to 1 million USD, 100 thousand to 500 thousand USD, 25 thousand to 100 thousand USD, 5 thousand to 25 thousand USD, and less than 5 thousand USD. Count the number of tokens in each cohort for each day.
- **Key fields**: `total_liquidity` sum across pairs, `liquidity_cohort` classifications, token counts by cohort

### Final aggregation
- **Combining components**: The tradeable assets count starts with cumulative counting of all tokens that have ever appeared in trading pairs, then applies liquidity-based corrections. For each cohort above 5 thousand USD, count the tokens in that specific cohort. For the lowest cohort (less than 5 thousand USD), start with the cumulative count of all tokens and subtract those that qualify for higher cohorts to avoid double counting.
- **Currency conversion**: USD conversion occurs at the net deposit level using end-of-day price feeds matched by timestamp, token address, and chain
- **Time aggregation**: Daily boundaries are set using timestamp truncation to day level, with cumulative counting over time using window functions
- **Final calculation**: The final metric represents the number of unique tradeable tokens in each liquidity cohort, with the total being the sum across all cohorts. The calculation ensures no token is counted in multiple cohorts simultaneously through the correction logic that subtracts higher-cohort tokens from the base cumulative count.

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

Number of unique tokens tradeable on the exchange.

CamelotGRAIL

Tradeable assets

Tradeable assets

Competitive landscape

Chain breakdown