Liquidity providers deposit funds into Perpetual Protocol to earn a share of trading fees (supply-side fees). Perpetual Protocol leverages Uniswap v3's architecture as a pricing engine, enabling traders to access up to 10x leverage. Perpetual Protocol also offers Hot Tub vaults, which operate trading strategies that generate yield from arbitrage profits. 

Perpetual Protocol is an open-source and non-custodial exchange for perpetual contracts built on Optimism. Perpetual Protocol was founded by Shao-Kang Lee & Yenwen Feng and launched in 2019.

PERP token holders own and govern the protocol. Token holders can boost their governance power and earn 15% of trading fees paid by traders (revenue) by locking PERP into vote-escrowed PERP (vePERP). Perpetual Protocol's investors include CMS Holdings, Binance Labs, and Mechanism Capital.

governance

github

twitter

discord

etherscan

website

Derivative exchanges

Perpetual Protocol

# Perpetual Protocol Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Perpetual Protocol measures the count of unique users who have traded on the protocol within any rolling 30-day period. This metric captures trading activity across Perpetual Protocol's decentralized derivatives platform on Gnosis and Optimism networks. The calculation uses HyperLogLog data structures to efficiently count unique traders over rolling windows while providing breakdowns by chain, user type, and product dimensions.

## 2. Data sources

- **Blockchain events**: Parsed `ClearingHouse_PositionChanged` events from Perpetual Protocol v1 contracts on Gnosis and v2 contracts on Optimism
- **Event parameters**: Trader addresses extracted from the `trader` parameter in position change events
- **Chain data**: Transaction timestamps from Gnosis and Optimism blockchain event logs
- **Protocol versions**: Data from both Perpetual Protocol v1 (Gnosis) and v2 (Optimism) deployments

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Identify unique daily active traders from blockchain events
- **Logic**: Perpetual Protocol user activity is identified through `ClearingHouse_PositionChanged` events, which fire whenever a trader opens, modifies, or closes a position. The system processes events from both Gnosis (v1) and Optimism (v2) networks. Each event contains a `trader` parameter that identifies the user's wallet address. Events are filtered to only include legitimate trading activity and classified with metadata including chain, market sector as 'derivatives', business segment as 'perpetualprotocol', and user type as 'Trader'.
- **Key fields**: `trader` address for user identification, `block_timestamp` for timing, `chain` for network classification, `user_type` set to 'Trader'

### Component B: Daily active user aggregation
- **Purpose**: Convert event-level data into daily unique active users
- **Logic**: Raw blockchain events are aggregated by day using timestamp truncation to day boundaries. The system creates distinct combinations of timestamp, chain, user type, and user address to ensure each user is counted only once per day regardless of how many position changes they made. This daily aggregation serves as the foundation for the rolling monthly window calculation.
- **Key fields**: `timestamp` truncated to daily boundaries, `user_address` as the unique identifier, dimensional attributes for grouping

### Component C: HyperLogLog sketch creation
- **Purpose**: Prepare daily user data for efficient rolling window aggregation
- **Logic**: Daily active user data is converted into HyperLogLog sketches with precision 15, which allows for memory-efficient approximate counting of unique users across large datasets. Each day's unique users are initialized into HLL sketches grouped by timestamp, chain, user type, and product dimensions. This approach enables efficient merging of user counts across multiple days without storing individual user addresses.
- **Key fields**: HLL sketches containing daily unique user approximations, dimensional grouping fields

### Component D: Rolling window generation
- **Purpose**: Create 30-day rolling windows for each target date
- **Logic**: A datespine is generated covering all days from the earliest available data to yesterday. For each day in the datespine, a 30-day lookback window is created by generating an array of dates from 29 days prior through the target date. This creates a cross-join structure where each target date is associated with all 30 days in its rolling window, ensuring complete coverage even when some days have no activity.
- **Key fields**: Target date (`timestamp`), window date (`joinday`) for the 30-day lookback period

### Component E: Window-based HLL aggregation
- **Purpose**: Merge daily HLL sketches within each 30-day window
- **Logic**: The rolling windows are joined with daily HLL sketches to create the complete dataset for MAU calculation. For each target date and dimension combination, all HLL sketches from the 30-day window are merged using `HLL_COUNT.MERGE_PARTIAL`. This operation combines the approximate unique user counts from all days in the window while avoiding double-counting users who were active on multiple days.
- **Key fields**: Merged HLL sketches representing unique users over 30-day periods

### Component F: Dimensional breakdowns
- **Purpose**: Create MAU metrics across different analytical dimensions
- **Logic**: The merged HLL data is processed into four separate dimensional views: project-level (overall protocol MAU), chain-level (MAU per blockchain), user-type-level (MAU per user classification), and product-level (MAU per product if applicable). Each breakdown groups the data differently and extracts the final unique user count using `HLL_COUNT.EXTRACT`. Unused dimension fields are set to null to maintain consistent schema across all breakdowns.
- **Key fields**: `dimensions` field indicating the breakdown type, relevant dimensional fields populated while others are nulled, `user_mau` containing the final count

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a single comprehensive dataset containing MAU metrics across all analytical dimensions
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Each record represents MAU for a specific day calculated using a trailing 30-day window
- **Final calculation**: The final MAU value is extracted from merged HLL sketches using `HLL_COUNT.EXTRACT`, providing an approximate count of unique users who traded within any rolling 30-day period. Missing days are filled with zeros to ensure complete time series data.

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

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

Perpetual ProtocolPERP

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown