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 Trade count Methodology

## 1. Overview

Trade count measures the total number of unique trading transactions executed on the Camelot decentralized exchange (DEX) on Arbitrum per day. This metric answers the question "How many distinct trades occurred on Camelot?" and helps assess trading activity and user engagement. The calculation identifies unique trades by counting distinct transaction hashes that contain Camelot swap events, ensuring that transactions with multiple swap events are only counted once.

## 2. Data sources

The calculation uses the following raw data sources:
- **Camelot v2 swap events**: Parsed `Pair_Swap_event` logs from Camelot v2 pair contracts on Arbitrum containing trade execution data
- **Camelot v3 swap events**: Parsed `Pool_Swap_event` logs from Camelot v3 pool contracts on Arbitrum containing trade execution data  
- **Arbitrum transaction records**: Transaction metadata including user addresses and timestamps for contextual information
- **Trading pair metadata**: Parsed `Factory_PairCreated_event` and `Factory_Pool_event` logs from Camelot factory contracts containing token addresses and pair configurations
- **Fee tier data**: Parsed `Pool_Fee_event` logs from Camelot v3 pools providing trading fee percentages
- **Token metadata**: External token information including decimal places and symbols for amount calculations
- **End-of-day token price feeds**: Daily USD price data for tokens traded on Camelot

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extracts all individual swap events from both Camelot v2 and v3 exchanges
- **Logic**: Queries `Pair_Swap_event` logs from v2 pair contracts and `Pool_Swap_event` logs from v3 pool contracts on Arbitrum. For v2 events, calculates net token amounts by subtracting `amount0Out` from `amount0In` and `amount1Out` from `amount1In`. For v3 events, uses `amount0` and `amount1` directly. Joins with Arbitrum transaction data to identify the user address initiating each trade via the `from_address` field. Creates unique identifiers using block number and log index to ensure each event can be distinctly tracked.
- **Key fields**: `transaction_hash`, `log_index`, `block_timestamp`, `account_address` (pool/pair contract), `user_address`, `token0_amount`, `token1_amount`

### Component B: Trading pair enrichment  
- **Purpose**: Adds token metadata and trading pair information to enable proper amount calculations
- **Logic**: Combines trade events with trading pair data derived from factory contract events. Uses `Factory_PairCreated_event` logs for v2 pairs and `Factory_Pool_event` logs for v3 pools to map pair/pool addresses to their underlying token addresses. Joins with token metadata to retrieve decimal places for each token in the pair. For v3 trades, incorporates fee tier information from `Pool_Fee_event` logs that specify trading fees at the block level.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`, `account_name` (token pair symbol)

### Component C: Amount normalization and USD conversion
- **Purpose**: Converts raw token amounts to proper decimal-adjusted values and USD equivalent for validation
- **Logic**: Applies decimal corrections by dividing token amounts by 10 raised to the power of each token's decimal places. Joins with end-of-day price feeds to convert both token amounts in each trade to USD values. Takes the absolute value of amounts to handle the directional nature of swap events. Uses the lesser of the two USD values (minimum of token0 USD value and token1 USD value) to filter out potential price manipulation or erroneous trades where one token might have an inflated or incorrect price.
- **Key fields**: `token0_amount` (decimal-corrected), `token1_amount` (decimal-corrected), `trading_volume` (minimum USD value)

### Final aggregation
- **Combining components**: All processed trade data is grouped by day using timestamp truncation to the day boundary
- **Currency conversion**: USD conversion occurs during the amount normalization step using end-of-day price feeds joined on daily timestamps
- **Time aggregation**: Trades are aggregated by truncating `block_timestamp` to daily boundaries and grouping by the resulting date
- **Final calculation**: The trade count is calculated using `count(distinct transaction_hash)` within each daily grouping, ensuring that transactions containing multiple swap events are counted only once. The `finalize_metric_trade_count` macro standardizes the output format and applies a fill-zeros strategy to ensure missing days show zero trades rather than null values. Chain availability filtering is applied to ensure data completeness requirements are met.

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

Number of trades executed on a decentralized exchange.

CamelotGRAIL

Trade count

Trade count

Competitive landscape

Chain breakdown