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 Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the count of unique users who executed trading activities on the CAP protocol within a 30-day rolling window. This metric provides insight into user engagement and platform adoption for CAP's derivatives trading platform across Arbitrum and Base chains. The calculation uses HyperLogLog approximation to efficiently handle large-scale unique user counting while providing breakdowns by chain, user type, and product dimensions.

## 2. Data sources

The calculation relies on the following blockchain data sources:

- **CAP protocol event logs**: Parsed smart contract events from CAP v3 and v4 Trading and Positions contracts deployed on Arbitrum and Base chains
- **Position management events**: `PositionUpdated`, `PositionIncreased`, `PositionDecreased`, and `ClosePosition` events that capture all meaningful trading activities
- **Block timestamp data**: Ethereum-compatible chain block timestamps for daily time aggregation
- **Chain availability metadata**: Data quality filters to ensure consistent reporting across supported blockchain networks
- **Protocol metadata**: Business classification data identifying market sectors (derivatives) and business segments (perpetual trading)

## 3. Step-by-step calculation

### Component A: User activity extraction

- **Purpose**: Identifies all meaningful user trading activities from CAP protocol smart contract events
- **Logic**: The system processes events from CAP v3 Trading contracts and CAP v4 Positions contracts across Arbitrum and Base chains. For CAP v3, it captures `PositionUpdated` events from the Trading contract and `ClosePosition` events (excluding liquidations based on the `wasLiquidated` flag). For CAP v4, it captures `PositionIncreased` and `PositionDecreased` events from the Positions contract. Each event provides the user address from the `user` parameter, along with block timestamp, transaction hash, and chain context. All users are classified as 'Trader' type within the derivatives market sector and perpetual business segment.
- **Key fields**: `user` address from events, `block_timestamp` for temporal grouping, transaction context for deduplication, chain identifier, user type classification

### Component B: Daily active user calculation

- **Purpose**: Aggregates unique user addresses to daily active user counts across dimensional breakdowns
- **Logic**: The system groups user activity events by day using timestamp truncation, then takes distinct user addresses within each day. This creates daily snapshots of unique active users grouped by chain, user type, and product dimensions. Chain availability filters ensure data quality across supported networks. The result is a daily time series of unique user counts that serves as the foundation for rolling window calculations.
- **Key fields**: `timestamp` truncated to day granularity, distinct `user_address` for uniqueness, dimensional groupings for chain and user type

### Component C: Rolling window construction

- **Purpose**: Creates 30-day rolling windows for each date to calculate monthly active user counts
- **Logic**: A date spine generates all historical dates from the earliest available data through the previous day. For each date in the spine, the system creates a join table that connects that date with the previous 29 days, forming a complete 30-day window. This window is then joined with the daily active user data to capture all user activity within each 30-day period. The approach ensures complete coverage even when certain days have no activity, maintaining consistent window sizes for accurate MAU calculations.
- **Key fields**: Date spine `timestamp` values, `joinday` representing each day within the 30-day window, HLL-encoded user data for efficient processing

### Component D: HyperLogLog approximation

- **Purpose**: Efficiently counts unique users within each 30-day rolling window using probabilistic approximation
- **Logic**: The system initializes HyperLogLog sketches for daily user sets using a precision parameter of 15, providing high accuracy for unique counting. Within each 30-day window, it merges the daily HLL sketches using `hll_count.merge_partial()` to combine user sets across the window period. Finally, it extracts the estimated unique user count using `hll_count.extract()`. This approach enables efficient processing of large user datasets while maintaining statistical accuracy for unique user counting across overlapping time windows.
- **Key fields**: HLL-initialized daily user sketches, merged HLL sketches for 30-day windows, extracted unique user counts

### Final aggregation

- **Combining components**: The system generates four dimensional breakdowns of the MAU calculation: project-level totals (aggregating across all dimensions), chain-level breakdowns, user type breakdowns, and product-level breakdowns. Each breakdown uses the same underlying 30-day rolling window data but groups by different dimensional combinations, with unused dimensions set to NULL values.
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: MAU is calculated as a 30-day rolling window that updates daily, providing continuous monthly snapshots of unique user activity
- **Final calculation**: The metric represents the estimated count of unique user addresses that executed any trading activity (position updates, increases, decreases, or voluntary closes) within the 30-day period ending on each date, aggregated using HyperLogLog approximation and broken down by project, chain, user type, and product dimensions

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

Unique revenue-generating users over a rolling 30-day window.

CapCAP

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown