Liquidity providers deposit funds into Pika Protocol and receive trading fees from traders (supply-side fees).

Pika Protocol is a non-custodial exchange for perpetual contracts built on Optimism. Pika Protocol was founded by an anonymous team and was launched in 2021.

PIKA tokenholders own and govern the protocol. Pika Protocol has no private investors.

github

twitter

discord

etherscan

website

Derivative exchanges

Pika Protocol

# Pika Protocol Active users (monthly) Methodology

## 1. Overview

The Pika Protocol Monthly Active Users (MAU) metric measures the number of unique users who have traded on the Pika Protocol platform within rolling 30-day periods. This metric captures user engagement by tracking addresses that have opened or closed perpetual positions across all versions of the protocol. The calculation uses HyperLogLog data structures to efficiently approximate unique user counts across time windows, providing breakdowns by chain, user type, and product dimensions.

## 2. Data sources

- **Pika Protocol contract events**: Parsed `NewPosition` and `ClosePosition` events from Pika Protocol versions 2, 3, and 4 deployed on Optimism
- **Optimism blockchain data**: Transaction timestamps from Optimism block data and transaction hash records
- **Contract event logs**: Optimism event logs containing user address parameters from perpetual trading contract interactions

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identifies all trading activity by extracting user addresses from Pika Protocol contract events
- **Logic**: Extracts user addresses from `NewPosition` and `ClosePosition` events across three protocol versions (v2, v3, v4) on Optimism. Each event represents a trading action where a user either opens a new perpetual position or closes an existing one. All identified users are classified as 'Trader' type since the protocol focuses on derivatives trading. The extraction captures the `user` parameter from contract events along with transaction metadata including `block_timestamp` and `transaction_hash`
- **Key fields**: `user_address` from event parameters, `block_timestamp` for timing, `chain` identifier (Optimism), `user_type` (Trader), market classification fields

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates user activity to daily granularity and creates the foundation for rolling window calculations
- **Logic**: Groups user activity by day using timestamp truncation to day-level granularity. Counts distinct `user_address` values per day to create daily active user records. Maintains dimensional attributes including chain, user type, and product information. This creates a clean daily view of unique active users that serves as the base for monthly calculations
- **Key fields**: `timestamp` (day-level), `user_dau` (unique user address), `chain`, `user_type`, `product_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Converts daily active user data into HyperLogLog sketches for efficient approximate counting across time windows
- **Logic**: Transforms daily user counts into HyperLogLog data structures using `hll_count.init()` with precision parameter 15. This enables efficient merging of user sets across different time periods without double-counting users who are active on multiple days. The HLL sketches maintain the approximate uniqueness while being computationally efficient for large datasets
- **Key fields**: `hll` sketch containing user activity data, dimensional grouping fields

### Component D: Rolling window generation
- **Purpose**: Creates 30-day rolling windows for each day to calculate monthly active users
- **Logic**: Generates a date spine covering all days from the earliest available data to yesterday. For each day in the spine, creates join keys for that day and the previous 29 days (total 30-day window). Uses `generate_timestamp_array()` to create the rolling windows and `unnest()` to expand into individual join records. This ensures every day has a complete 30-day lookback window for MAU calculation
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 30-day window)

### Component E: Window data joining
- **Purpose**: Combines the rolling windows with daily HLL sketches to capture all user activity within each 30-day period
- **Logic**: Joins the rolling window structure with daily HLL sketches based on matching dates. This creates records where each target date is associated with all daily user activity from its 30-day lookback window. Maintains all dimensional attributes (chain, user type, product) throughout the join to enable proper grouping in subsequent steps
- **Key fields**: `timestamp` (target date), `hll` (daily user sketches), dimensional attributes

### Component F: HLL sketch merging and MAU calculation
- **Purpose**: Merges HLL sketches within each 30-day window to calculate approximate unique user counts
- **Logic**: Groups data by target date and dimensional attributes, then uses `hll_count.merge_partial()` to combine all HLL sketches within each 30-day window. Extracts the final approximate unique count using `hll_count.extract()`. This provides the Monthly Active User count for each day, representing unique users active in the trailing 30-day period
- **Key fields**: `user_mau` (approximate unique user count), grouping dimensions

### Component G: Dimensional breakdowns
- **Purpose**: Creates multiple views of MAU data broken down by different business dimensions
- **Logic**: Generates four distinct breakdowns of the MAU data: project-level (aggregated across all dimensions), chain-level (grouped by blockchain), user_type-level (grouped by user classification), and product_id-level (grouped by product). Each breakdown nullifies non-relevant dimension fields and sets a `dimensions` identifier. All breakdowns are combined using `union all` operations to create a comprehensive view
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`, `user_mau`

### Final aggregation
- **Combining components**: The dimensional breakdowns are unified through union operations, creating a single table with MAU values across all requested breakdown levels
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Data is calculated at daily granularity with each record representing a 30-day trailing window MAU value
- **Final calculation**: The `finalize_metric_user_mau` macro applies schema standardization, fills missing dates with zero values, and ensures consistent output formatting with proper project identification and metadata fields

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

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

Pika ProtocolPIKA

Active users (monthly)

Active users (monthly)

Competitive landscape