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 Notional trading volume Methodology

## 1. Overview

Cap's notional trading volume measures the total USD value of perpetual derivative trading activity across all versions of the Cap protocol. This metric combines position opens, closes, and liquidations from both Cap v3 (Arbitrum only) and Cap v4 (Arbitrum and Base) to provide a comprehensive view of trading activity. The calculation handles the different event structures between protocol versions and includes forced liquidations as part of the total trading volume.

## 2. Data sources

The metric utilizes the following raw blockchain data sources:
- **Cap v3 events**: Parsed `ClosePosition` events from the Cap v3 Trading contract on Arbitrum
- **Cap v4 events**: Parsed `PositionIncreased`, `PositionDecreased`, and `PositionLiquidated` events from Cap v4 Positions and Processor contracts on Arbitrum and Base
- **Token metadata**: Token symbol and decimal precision information for proper amount normalization
- **End-of-day price feeds**: Daily USD price data for converting token amounts to USD values

## 3. Step-by-step calculation

### Component A: Cap v3 perpetual trading volumes
- **Purpose**: Extracts trading volume data from Cap v3 protocol on Arbitrum
- **Logic**: Processes `ClosePosition` events from the Cap v3 Trading contract. Since these events only capture position closes, the `size` amounts are doubled to estimate total trading volume (both opens and closes). Null token addresses (`0x0000000000000000000000000000000000000000`) are converted to WETH addresses (`0x82af49447d8a07e3bd95bd0d56f35241523fbab1`) for proper token identification. The `productId` field contains hex-encoded token symbols that are decoded to extract readable token symbols.
- **Key fields**: `size` (doubled and divided by 10^8 for decimal correction), `currency` (converted from null to WETH), `productId` (decoded to extract `token_symbol`)

### Component B: Cap v4 perpetual trading volumes
- **Purpose**: Extracts trading volume data from Cap v4 protocol on Arbitrum and Base
- **Logic**: Processes both `PositionIncreased` and `PositionDecreased` events from the Cap v4 Positions contract. Unlike v3, these amounts are not doubled since both position opens and closes are explicitly tracked. ETH addresses (`0x0000000000000000000000000000000000000000`) are converted to chain-specific WETH addresses for proper token identification. Raw amounts undergo decimal correction using token metadata to normalize to standard decimal precision.
- **Key fields**: `size` (raw amount requiring decimal correction), `asset` (converted from ETH to WETH), `market` (token symbol)

### Component C: Cap v4 liquidation volumes  
- **Purpose**: Captures forced position closures due to insufficient margin
- **Logic**: Processes `PositionLiquidated` events from the Cap v4 Processor contract on Arbitrum and Base. These represent involuntary position closures and are included in total trading volume. Similar address conversion logic is applied as with regular v4 trading events. Amounts undergo decimal correction using token metadata.
- **Key fields**: `size` (liquidation amount requiring decimal correction), `asset` (converted from ETH to WETH), `market` (token symbol)

### Final aggregation
- **Combining components**: All three components are combined using union operations, creating a unified dataset of trading events across all Cap protocol versions and chains
- **Currency conversion**: Raw token amounts are converted to USD using end-of-day price feeds matched by token address and date. The conversion process applies proper decimal correction based on token metadata before USD conversion
- **Time aggregation**: All events are aggregated to daily boundaries using timestamp truncation to the day level
- **Final calculation**: The metric sums all USD-converted trading amounts by day, account, token, and other dimensional attributes. Zero-filling is applied for missing data points, and chain availability filtering ensures only supported chains are included in the final results

## Critical guidelines

The methodology accounts for several protocol-specific considerations:
- Cap v3 only emits `ClosePosition` events, requiring amount doubling to estimate total volume
- Address normalization converts ETH null addresses to chain-specific WETH addresses
- Liquidations are treated as trading volume since they represent actual position closures
- Different decimal precision handling between v3 (fixed 8 decimals) and v4 (token-specific decimals)
- Cross-chain aggregation combines Arbitrum and Base data for comprehensive volume measurement

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

Total USD value of derivative contracts executed on the protocol.

CapCAP

Archived

Notional trading volume

Notional trading volume

Competitive landscape

Chain breakdown