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 Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the portion of trading fees that flow to liquidity providers on the Camelot decentralized exchange. This metric captures the total daily USD value of fees earned by LPs across both Camelot v2 and v3 protocols on Arbitrum. The calculation applies protocol-specific fee shares to gross trading fees: 60% for v2 and 85% for v3, reflecting the different fee distribution mechanisms between versions.

## 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 update events**: Parsed `Pair_FeePercentUpdated_event` logs from Camelot v2 contracts tracking dynamic fee changes and `Pool_Fee_event` logs from Camelot v3 contracts tracking fee tier updates
- **Factory events**: Parsed `Factory_PairCreated_event` logs from Camelot v2 factory and `Factory_Pool_event` logs from Camelot v3 factory establishing trading pairs
- **Transaction data**: Arbitrum transaction records providing user addresses and transaction context
- **External data**: End-of-day token price feeds for USD conversion and token metadata including symbols and decimal places

## 3. Step-by-step calculation

### Component A: Trade event processing
- **Purpose**: Extract and standardize trade data from both Camelot v2 and v3 swap events
- **Logic**: Parse `Pair_Swap_event` logs from v2 contracts extracting `amount0In`, `amount0Out`, `amount1In`, and `amount1Out` fields. Calculate net token amounts as the difference between in and out amounts. For v3, parse `Pool_Swap_event` logs extracting direct `amount0` and `amount1` values. Join all trades with Arbitrum transaction records to obtain user addresses. Create unique trade identifiers by concatenating formatted block numbers and log indices
- **Key fields**: `block_timestamp`, `account_address` (trading pair), `user_address`, `token0_amount`, `token1_amount`, `version`

### Component B: Fee rate determination
- **Purpose**: Track dynamic fee percentages for v2 pairs and fee tiers for v3 pools
- **Logic**: For v2, start with default 0.3% fee rate at pair creation from `Factory_PairCreated_event`. Track fee changes through `Pair_FeePercentUpdated_event` logs, extracting `token0FeePercent` and `token1FeePercent` values, dividing by 10^5 for decimal conversion, and averaging the two percentages. Use range-based lookups with sequential ID ordering to apply correct fee rates to trades based on timing. For v3, extract fee tier updates from `Pool_Fee_event` logs, converting `feeOtz` values to decimal by dividing by 10^6
- **Key fields**: `fee_percentage` (v2), `fee_tier` (v3), effective date ranges for fee changes

### Component C: Trading pair metadata
- **Purpose**: Provide token addresses, decimals, and pair naming information
- **Logic**: Extract trading pair creation events from both v2 `Factory_PairCreated_event` and v3 `Factory_Pool_event` logs to identify `token0` and `token1` addresses for each pair. Join with token metadata to obtain decimal places for amount corrections and token symbols for pair naming. Create human-readable pair names by concatenating token symbols with hyphens
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`

### Component D: Volume calculation with price manipulation protection
- **Purpose**: Convert raw token amounts to USD trading volumes with safeguards against manipulation
- **Logic**: Correct token amounts by dividing by 10 raised to the token's decimal places and taking absolute values. Join with end-of-day price feeds for both tokens in each pair using daily timestamp truncation. Calculate USD values for both tokens by multiplying corrected amounts with respective token prices. Apply price manipulation protection by selecting the minimum USD value between the two tokens for each trade, defaulting to zero if either price is unavailable
- **Key fields**: `trading_volume` (USD value), `token0_amount` (corrected), `token1_amount` (corrected)

### Component E: Gross fee calculation
- **Purpose**: Calculate total fees generated from trading activity
- **Logic**: For v2 trades, multiply trading volume by the applicable dynamic fee percentage determined through range-based lookups. For v3 trades, multiply trading volume directly by the fee tier value. Handle timing of fee changes by matching trade timestamps with effective fee rate periods
- **Key fields**: `fees` (gross trading fees in USD)

### Final aggregation
- **Combining components**: Join processed trades with their corresponding fee rates, trading pair metadata, and USD-converted volumes
- **Supply-side fee calculation**: Apply protocol-specific fee shares to gross fees - multiply by 0.6 (60%) for v2 trades and by 0.85 (85%) for v3 trades to determine the portion flowing to liquidity providers
- **Time aggregation**: Truncate timestamps to daily boundaries and aggregate fees by day, chain, market sector, business segment, and product
- **Currency conversion**: All calculations performed in USD using end-of-day price feeds with daily granularity
- **Final calculation**: Sum supply-side fees across all trading pairs and versions, applying zero-filling strategy for days without trading activity and chain availability filters for data completeness

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

Portion of fees distributed to service providers or supply-side participants.

CamelotGRAIL

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown