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 Average fees per user (AFPU) Methodology

## 1. Overview

Average fees per user (AFPU) measures the average amount of fees generated per daily active user on the Cap protocol. This metric is calculated by dividing total daily fees by the number of daily active users, providing insight into the revenue efficiency per user. Cap operates as a derivatives protocol offering perpetual trading on Arbitrum and Base chains across two versions (v3 and v4), and this metric captures the average fee contribution from each user engaging with the platform.

## 2. Data sources

The calculation relies on several types of blockchain data and external feeds:

- **Cap v3 events**: Parsed `PositionUpdated` and `ClosePosition` events from the Cap v3 Trading contract on Arbitrum, containing fee amounts and user addresses
- **Cap v4 events**: Parsed `FeePaid`, `PositionIncreased`, and `PositionDecreased` events from Cap v4 Positions contracts on both Arbitrum and Base chains
- **Transaction metadata**: Block timestamps and transaction hashes for temporal organization
- **End-of-day price feeds**: Token price data for USD conversion of fee amounts
- **Token metadata**: Decimal precision information for proper fee amount calculations
- **Historical configuration data**: Revenue percentage splits that changed over time for Cap v3 fee distribution

## 3. Step-by-step calculation

### Component A: User activity tracking
- **Purpose**: Identify and count daily active users across Cap v3 and v4 
- **Logic**: Extract user addresses from position-related events across both protocol versions and chains. For Cap v3 on Arbitrum, capture users from `PositionUpdated` events and non-liquidation `ClosePosition` events (filtering out events where `wasLiquidated` is true). For Cap v4 on both Arbitrum and Base, capture users from `PositionIncreased` and `PositionDecreased` events. All users are classified as "Trader" type since Cap focuses on derivatives trading. Aggregate these events to daily level using timestamp truncation and count distinct user addresses using HyperLogLog for scalable computation across different dimensional breakdowns.
- **Key fields**: `user` addresses from events, `block_timestamp` for daily aggregation, `wasLiquidated` flag for v3 filtering

### Component B: Cap v3 fee extraction
- **Purpose**: Extract and split fees from Cap v3 trading events
- **Logic**: Extract fee amounts from `PositionUpdated` and `ClosePosition` events on the Cap v3 Trading contract. Fee amounts are denominated in 8 decimals and need conversion. Replace null ETH addresses with the WETH contract address for standardization. Apply historical revenue percentage splits based on the event date: 50% revenue from November 2021 to January 2022, 80% revenue from January to February 2022, and 95% revenue from February 2022 onwards. Calculate both protocol revenue (fees × revenue_percentage) and supply-side fees (fees × (1 - revenue_percentage)) separately.
- **Key fields**: `fee` amounts in 8 decimals, `currency` token addresses, `productId` for token symbols, timestamps for revenue percentage application

### Component C: Cap v4 fee extraction  
- **Purpose**: Extract pre-separated fees from Cap v4 events
- **Logic**: Extract fee components from `FeePaid` events on Cap v4 Positions contracts on Arbitrum and Base. These events contain four fee types: `poolFee` (to liquidity providers), `keeperFee` (to oracles), `stakingFee` (to CAP stakers), and `treasuryFee` (to protocol treasury). Sum `poolFee` and `keeperFee` to create supply-side fees. Sum `stakingFee` and `treasuryFee` to create protocol revenue. Handle ETH address normalization by replacing null addresses with chain-specific WETH addresses.
- **Key fields**: `poolFee`, `keeperFee`, `stakingFee`, `treasuryFee` amounts, `asset` token addresses

### Component D: User activity aggregation
- **Purpose**: Count daily distinct active users with dimensional flexibility
- **Logic**: Take user addresses identified from position events and aggregate them to daily counts. Use HyperLogLog sketching algorithm to enable efficient counting across multiple dimensional breakdowns including total project level, by chain, by user type, and by product. This allows for scalable computation while maintaining accuracy for distinct user counts.
- **Key fields**: Distinct `user_address` values, aggregated by day with HyperLogLog

### Final aggregation
- **Combining components**: Sum protocol revenue and supply-side fees from both Cap v3 (calculated splits) and Cap v4 (explicit amounts) to create total daily fees. Join total fees with daily active user counts on timestamp and chain dimensions.
- **Currency conversion**: Apply decimal corrections using token metadata, then convert all fee amounts to USD using end-of-day price feeds matched by date and token address
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation to day level, ensuring consistent temporal alignment between fees and user metrics
- **Final calculation**: Divide total daily fees (in USD) by daily active user count to produce the average fees per user metric. Apply zero-filling strategy for days with missing data to maintain complete time series.

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

CapCAP

Archived

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape