Liquidity providers deposit funds into Cap and receive trading fees from traders (supply-side fees).

Cap is a non-custodial exchange for perpetual contracts built on Arbitrum. Cap was founded by an anonymous team and launched in 2021.

CAP token holders own and govern the protocol. They currently take a cut of trading fees paid by traders (revenue).

github

twitter

discord

etherscan

website

Derivative exchanges

# Cap Fees Methodology

## 1. Overview

The Cap fees metric measures the total fees paid by users of the Cap protocol for perpetual trading activities. This includes both protocol revenue (fees retained by Cap) and supply-side fees (fees paid to liquidity providers and keepers). The metric combines data from Cap v3 (Arbitrum only) and Cap v4 (Arbitrum and Base), with different fee structures between versions requiring distinct calculation approaches.

## 2. Data sources

- **Cap v3 smart contract events**: Parsed `PositionUpdated` and `ClosePosition` events from Arbitrum containing fee amounts in 8-decimal precision
- **Cap v4 smart contract events**: Parsed `FeePaid` events from Arbitrum and Base with explicit fee category breakdowns (`poolFee`, `keeperFee`, `stakingFee`, `treasuryFee`)
- **End-of-day token price feeds**: USD conversion rates for fee tokens
- **Token metadata**: Decimal precision information for proper amount scaling
- **Historical configuration data**: Time-based revenue percentage splits for Cap v3 fee allocation

## 3. Step-by-step calculation

### Component A: Cap v3 perpetual trading fees

- **Purpose**: Extract and categorize fees from Cap v3 trading activities on Arbitrum
- **Logic**: Parse `PositionUpdated` and `ClosePosition` events to extract fee amounts denominated in 8 decimals. Convert ETH addresses (`0x0000000000000000000000000000000000000000`) to WETH addresses (`0x82af49447d8a07e3bd95bd0d56f35241523fbab1`) for consistency. Scale amounts by dividing by 10^8 to correct for 8-decimal encoding. Apply time-based revenue percentage splits: 50% to protocol revenue from November 17, 2021; 80% from January 7, 2022; 95% from February 20, 2022 onwards. Calculate supply-side fees as the remainder (1 - revenue_percentage).
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `address` (account), `currency` (token address), `fee` (amount in 8 decimals)

### Component B: Cap v4 perpetual trading fees

- **Purpose**: Extract and categorize fees from Cap v4 trading activities on Arbitrum and Base
- **Logic**: Parse `FeePaid` events which contain explicit fee breakdowns. Categorize `poolFee` and `keeperFee` as supply-side fees (paid to liquidity providers and oracles). Categorize `stakingFee` and `treasuryFee` as protocol revenue (retained by Cap for stakers and treasury). Convert ETH addresses to chain-specific WETH addresses (Arbitrum: `0x82af49447d8a07e3bd95bd0d56f35241523fbab1`, Base: `0x4200000000000000000000000000000000000006`). No additional decimal scaling required as v4 amounts are already properly denominated.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `address` (account), `asset` (token address), `poolFee`, `keeperFee`, `stakingFee`, `treasuryFee`

### Component C: Revenue calculation

- **Purpose**: Aggregate protocol revenue from both v3 and v4 sources
- **Logic**: For v3, multiply fee amounts by time-appropriate revenue percentages using daily timestamp matching. For v4, sum `stakingFee` and `treasuryFee` amounts. Apply decimal correction using token metadata to ensure proper scaling. Convert amounts to USD using end-of-day price feeds. Aggregate daily by truncating timestamps to day boundaries and grouping by chain, account, and token.
- **Key fields**: `timestamp` (daily), `chain_id`, `token_address`, `revenue` amount in USD

### Component D: Supply-side fees calculation

- **Purpose**: Aggregate fees paid to liquidity providers from both v3 and v4 sources  
- **Logic**: For v3, multiply fee amounts by (1 - revenue_percentage) using time-appropriate percentages. For v4, sum `poolFee` and `keeperFee` amounts. Apply decimal correction and USD conversion following same process as revenue. Aggregate daily with same grouping dimensions.
- **Key fields**: `timestamp` (daily), `chain_id`, `token_address`, `fees_supply_side` amount in USD

### Final aggregation

- **Combining components**: Join revenue and supply-side fee components on `timestamp` and `chain_id` dimensions, then sum to calculate total fees
- **Currency conversion**: All amounts converted to USD using end-of-day token price feeds matched by token address and daily timestamp
- **Time aggregation**: All data aggregated to daily boundaries using timestamp truncation, with consistent daily granularity across components
- **Final calculation**: Total fees = protocol revenue + supply-side fees, representing the complete fee burden paid by Cap protocol users for perpetual trading activities

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

Total value users pay to use a protocol (gross fees, user-paid fees).

CapCAP

Archived

Fees

Fees

Competitive landscape

Chain breakdown