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

## 1. Overview

Cap's revenue metric measures the protocol's earnings from perpetual trading fees across Cap v3 (Arbitrum only) and Cap v4 (Arbitrum and Base). The metric captures the portion of trading fees that goes to CAP token stakers and the protocol treasury, excluding fees paid to liquidity providers and oracles. The calculation differs between versions due to changes in fee structure: Cap v3 uses a variable percentage of total fees, while Cap v4 explicitly separates revenue components from other fee types.

## 2. Data sources

- **Blockchain events**: Parsed `Trading_PositionUpdated_event` and `Trading_ClosePosition_event` from Cap v3 contracts on Arbitrum, and `Positions_FeePaid_event` from Cap v4 contracts on Arbitrum and Base
- **External data**: End-of-day token price feeds for USD conversion and token metadata for decimal standardization
- **Historical configuration**: Hardcoded revenue percentage changes for Cap v3 fee calculations

## 3. Step-by-step calculation

### Component A: Cap v3 perpetual trading fee revenue
- **Purpose**: Calculate protocol revenue from Cap v3 trading fees using time-varying revenue percentages
- **Logic**: Extract fee amounts from `Trading_PositionUpdated_event` and `Trading_ClosePosition_event` logs on Arbitrum. Convert null currency addresses to WETH address (0x82af49447d8a07e3bd95bd0d56f35241523fbab1). Decode hexadecimal `productId` fields to extract token symbols. Apply decimal correction by dividing raw `fee` amounts by 10^8. Multiply corrected fee amounts by the applicable revenue percentage based on the transaction date: 50% for dates from 2021-11-17 to 2022-01-06, 80% for dates from 2022-01-07 to 2022-02-19, and 95% for dates from 2022-02-20 onwards
- **Key fields**: `fee` (raw fee amount in 8 decimals), `currency` (token address with null converted to WETH), `productId` (hex-encoded token symbol), `block_timestamp` (for revenue percentage lookup)

### Component B: Cap v4 perpetual trading fee revenue  
- **Purpose**: Extract protocol revenue components directly from Cap v4 fee structures
- **Logic**: Parse `Positions_FeePaid_event` logs from Arbitrum and Base chains. Each event contains four fee components: `poolFee`, `keeperFee`, `stakingFee`, and `treasuryFee`. Sum `stakingFee` and `treasuryFee` to calculate revenue amount, as these components go to CAP stakers and protocol treasury. Convert null ETH addresses to chain-specific WETH addresses (Arbitrum: 0x82af49447d8a07e3bd95bd0d56f35241523fbab1, Base: 0x4200000000000000000000000000000000000006). Apply decimal correction using token metadata lookup
- **Key fields**: `stakingFee` and `treasuryFee` (revenue components), `poolFee` and `keeperFee` (LP components), `asset` (token address)

### Component C: Revenue percentage dimension for Cap v3
- **Purpose**: Provide time-varying revenue percentages for Cap v3 fee calculations
- **Logic**: Use hardcoded historical dates and percentages: 50% revenue starting 2021-11-17 (protocol launch), 80% revenue starting 2022-01-07, and 95% revenue starting 2022-02-20. Fill forward each percentage to all subsequent days until the next change occurs, creating a complete daily time series for joining with Cap v3 fee data
- **Key fields**: `timestamp` (daily dates), `revenue_percentage` (decimal percentage for multiplication)

### Final aggregation
- **Combining components**: Union Cap v3 revenue (fees × revenue percentage) with Cap v4 revenue (stakingFee + treasuryFee) to create total daily revenue by chain, token, and account
- **Currency conversion**: Convert all token amounts to USD using end-of-day price feeds, applying decimal correction based on token metadata before conversion
- **Time aggregation**: Truncate all timestamps to daily boundaries and aggregate revenue amounts by day, chain, token address, and account address
- **Final calculation**: Sum all daily revenue amounts across both protocol versions, maintaining dimensions for chain, business line (perpetual trading), market sector (derivatives), business segment (perpetual), version, account, and token. Apply zero-fill strategy to create complete time series coverage

*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.

CapCAP

Archived

Revenue

Revenue

Competitive landscape

Chain breakdown