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 trade) Methodology

## 1. Overview

The trading volume average per trade count metric measures the average USD value per trade on the Camelot decentralized exchange. This metric is calculated by dividing the total daily trading volume (in USD) by the total number of unique trades for the same day. It provides insight into the typical trade size and trading behavior on the platform, helping assess whether the exchange attracts high-value or retail trading activity.

## 2. Data sources

The calculation draws from several blockchain and external data sources:

- **Swap events**: Parsed `Swap` events from Camelot v2 (`Pair_Swap_event`) and v3 (`Pool_Swap_event`) smart contracts on Arbitrum, containing token amounts and trading pair addresses
- **Factory events**: Parsed `PairCreated` events from Camelot v2 factory and `Pool` events from Camelot v3 factory contracts, identifying valid trading pairs and their token compositions
- **Fee events**: Parsed `Fee` events from Camelot v3 pool contracts, tracking fee tier updates for accurate volume calculations
- **Transaction data**: Arbitrum transaction records providing user addresses, timestamps, and block information
- **Token metadata**: Token registry data containing decimal places, symbols, and other token properties for proper amount formatting
- **External data**: End-of-day token price feeds providing USD conversion rates for supported tokens

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract individual swap transactions from Camelot v2 and v3 contracts
- **Logic**: The system processes `Swap` events from both Camelot versions on Arbitrum. For v2 contracts, it calculates net token amounts by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For v3 contracts, it uses the direct `amount0` and `amount1` values from swap events. Each trade is assigned a unique identifier using block number and log index formatting. Transaction data is joined to capture the `from_address` as the user address and block timestamp for temporal ordering.
- **Key fields**: Block timestamp, transaction hash, log index, contract address, user address, `token0_amount`, `token1_amount`, version identifier

### Component B: Trading pair enrichment
- **Purpose**: Identify valid trading pairs and enrich trades with token metadata
- **Logic**: Valid trading pairs are identified from factory creation events - `PairCreated` events for v2 and `Pool` events for v3. Each pair contains `token0_address` and `token1_address` fields. Token metadata is joined to retrieve decimal places for both tokens in each pair, along with token symbols to construct human-readable pair names. This enrichment enables proper decimal correction and volume calculation.
- **Key fields**: Trading pair contract address, `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, pair name

### Component C: Fee tier integration
- **Purpose**: Capture fee tier information for v3 pools to enable accurate fee calculations
- **Logic**: Fee tier updates are extracted from v3 `Fee` events, which record changes in fee percentages for specific pools at specific block numbers. The fee value from `feeOtz` field is divided by 1,000,000 to convert from basis points to decimal percentage. These fee tiers are matched to trades based on account address, block number, and version identifier.
- **Key fields**: Account address, block number, `fee_tier` (decimal percentage)

### Component D: Volume calculation with manipulation protection
- **Purpose**: Convert token amounts to USD values while preventing price manipulation
- **Logic**: Token amounts are first corrected for decimals by dividing absolute amounts by 10 raised to the token's decimal places. Each corrected amount is then multiplied by the corresponding token's end-of-day USD price from external price feeds. To prevent price manipulation attacks, the system takes the minimum USD value between `token0_amount` multiplied by token0 price and `token1_amount` multiplied by token1 price. If either price is unavailable, the trade volume is set to zero. This approach ensures that artificially inflated token prices cannot inflate reported volumes.
- **Key fields**: Corrected `token0_amount`, corrected `token1_amount`, `price_usd` for both tokens, final `trading_volume` (minimum USD value)

### Component E: Trade count calculation  
- **Purpose**: Count unique trades for denominator calculation
- **Logic**: The system processes the same enriched trade data but focuses on counting distinct transaction hashes rather than calculating volumes. Trades are grouped daily and deduplicated by transaction hash to count unique trading transactions. This ensures that complex trades involving multiple events within the same transaction are counted as a single trade.
- **Key fields**: Block timestamp truncated to day, transaction hash, distinct trade count

### Final aggregation
- **Combining components**: Daily trading volumes and trade counts are calculated separately from the same underlying trade data, then joined on timestamp and grain fields
- **Currency conversion**: USD conversion occurs at the individual trade level using end-of-day price feeds, with manipulation protection applied before aggregation
- **Time aggregation**: All timestamps are truncated to day boundaries for daily metrics, with separate aggregation for volume (sum) and trade count (distinct transaction hash count)
- **Final calculation**: The average volume per trade is calculated using safe division of total daily trading volume by total daily trade count, with zero-fill strategy applied for days with no trading activity

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

CamelotGRAIL

Average trading volume (per trade)

Average trading volume (per trade)

Competitive landscape