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 Revenue Methodology

## 1. Overview

Camelot revenue represents the protocol's share of trading fees generated by its decentralized exchange (DEX) on Arbitrum. The calculation captures fees from both Camelot v2 and v3 liquidity pools, applying different protocol fee shares to determine the revenue retained by the protocol. This metric answers how much revenue Camelot generates from its trading activity by taking a percentage of the total trading fees collected from users.

## 2. Data sources

- **Swap events**: Parsed `Pair_Swap_event` logs from Camelot v2 contracts and `Pool_Swap_event` logs from Camelot v3 contracts on Arbitrum
- **Fee configuration events**: `Pair_FeePercentUpdated_event` logs for v2 dynamic fee changes and `Pool_Fee_event` logs for v3 fee tier updates
- **Factory events**: `Factory_PairCreated_event` and `Factory_Pool_event` logs that identify trading pairs and pools with their token compositions
- **Transaction data**: Arbitrum transaction records providing user addresses and transaction context
- **Price data**: End-of-day token price feeds for USD conversion of trading volumes
- **Token metadata**: Token decimals and symbol information for proper amount normalization

## 3. Step-by-step calculation

### Component A: Raw trade data extraction
- **Purpose**: Extract all swap transactions from Camelot v2 and v3 pools
- **Logic**: Parse swap events from both protocol versions on Arbitrum. For v2 swaps, calculate token amount changes as the difference between input and output amounts (`amountIn - amountOut`). For v3 swaps, use the direct amount values from the events. Each trade record includes the pool address, user address from transaction data, and token amounts involved in the swap.
- **Key fields**: `block_timestamp`, `account_address` (pool address), `user_address`, `token0_amount`, `token1_amount`, `version`

### Component B: Fee tier and percentage mapping  
- **Purpose**: Determine the applicable fee rate for each trade
- **Logic**: For v2 pools, use dynamic fee percentages from `FeePercentUpdated_event` logs, defaulting to 0.3% for newly created pairs. Fee changes are applied chronologically using block number ordering. For v3 pools, extract fee tiers from `Pool_Fee_event` logs, converting from basis points (divide by 10^6) to decimal percentages. Fee tiers can change per block, so trades are matched to the fee rate active at the time of the swap.
- **Key fields**: `fee_percentage` (for v2), `fee_tier` (for v3), `block_number`, `account_address`

### Component C: Trading pair metadata enrichment
- **Purpose**: Add token information and decimal precision for proper amount conversion
- **Logic**: Join trading pairs identified from factory events with token metadata to get decimal places for each token in the pair. Extract token addresses from `Factory_PairCreated_event` (v2) and `Factory_Pool_event` (v3) logs, then enrich with token decimals and symbols to create readable pair names. Convert raw token amounts to normalized amounts by dividing by 10 raised to the token's decimal places.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`

### Component D: USD conversion and volume calculation
- **Purpose**: Convert token amounts to USD values and calculate trading volume
- **Logic**: Join normalized token amounts with end-of-day price feeds for both tokens in each trading pair. Convert each token amount to USD by multiplying the normalized amount by the token's USD price. To filter out price manipulation attacks, use the minimum USD value between the two token amounts as the trading volume for each swap. This prevents inflated volumes from trades involving tokens with manipulated prices.
- **Key fields**: `trading_volume`, `token0_amount` (normalized), `token1_amount` (normalized), price feeds

### Component E: Fee calculation  
- **Purpose**: Calculate total fees collected from each trade
- **Logic**: Multiply the USD trading volume by the applicable fee rate for each swap. For v2, use the dynamic fee percentage determined from the fee mapping. For v3, use the fee tier associated with the pool at the time of the trade. This produces the total fees paid by traders for each swap transaction.
- **Key fields**: `fees` (calculated as trading_volume × fee_rate)

### Final aggregation
- **Combining components**: Sum all fee amounts by day, maintaining separation between v2 and v3 transactions
- **Protocol revenue calculation**: Apply version-specific protocol fee shares to calculate Camelot's revenue: multiply v2 fees by 40% (0.4) and v3 fees by 15% (0.15) to get the protocol's portion of total fees collected
- **Currency conversion**: All amounts are already in USD from the volume calculation step using end-of-day price feeds
- **Time aggregation**: Aggregate daily by truncating timestamps to day boundaries, ensuring all trades within a 24-hour period are summed together
- **Final calculation**: The final revenue equals the sum of (v2_fees × 0.4) + (v3_fees × 0.15) for each day

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

CamelotGRAIL

Revenue

Revenue

Competitive landscape

Chain breakdown