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 Fees Methodology

## 1. Overview

Total fees represents the complete fee revenue generated by Pika Protocol from perpetual derivatives trading activities on Optimism. This metric combines both protocol revenue (fees retained by the protocol) and supply-side fees (fees distributed to liquidity providers). The calculation aggregates fees from position opening, closing, and liquidation events across all Pika Protocol contract versions, applying a 50/50 revenue split between the protocol and liquidity providers.

## 2. Data sources

The methodology relies on the following data sources:
- **Pika Protocol smart contract events**: Parsed `NewPosition`, `ClosePosition`, and `PositionLiquidated` events from PikaPerp contracts on Optimism across versions v2, v3, and v4
- **USDC token metadata**: Contract address and symbol information for fee denomination
- **End-of-day price feeds**: Token price data for USD conversion of USDC-denominated fees
- **Revenue split configuration**: Hardcoded protocol configuration defining the percentage split between protocol revenue and liquidity provider fees

## 3. Step-by-step calculation

### Component A: Perpetual trading fees extraction
- **Purpose**: Captures fees generated from opening and closing perpetual trading positions
- **Logic**: Extracts fee data from `NewPosition` and `ClosePosition` events emitted by PikaPerp contracts across versions v2, v3, and v4 on Optimism. Each event contains a `fee` field representing the trading fee in USDC with 8 decimal places. The system processes events from all contract versions to ensure complete fee coverage as the protocol evolved. Events are deduplicated using transaction hash and log index to prevent double-counting.
- **Key fields**: `fee` amounts are converted from 8-decimal USDC format to standard decimal format, transaction metadata for deduplication, and contract version tracking

### Component B: Liquidation fees extraction  
- **Purpose**: Captures fees generated from position liquidation events
- **Logic**: Extracts liquidation fee data from `PositionLiquidated` events across all PikaPerp contract versions. Each liquidation event contains two fee components: `remainingReward` (protocol's share) and `liquidatorReward` (liquidator's incentive). These amounts are summed together to get the total liquidation fee, then converted from 8-decimal USDC format. Liquidation events are processed across all contract versions and deduplicated by transaction hash and log index.
- **Key fields**: `remainingReward` and `liquidatorReward` fields summed for total liquidation fees, converted from 8-decimal format to standard decimals

### Component C: Revenue percentage application
- **Purpose**: Applies the protocol's revenue split configuration to separate protocol revenue from liquidity provider fees
- **Logic**: Uses a time-based revenue percentage configuration that defines how fees are split between the protocol and liquidity providers. Starting from 2022-01-22, the split is set at 50% to the protocol (revenue) and 50% to liquidity providers (supply-side fees). This percentage is applied to both trading and liquidation fees by joining on the daily timestamp. The configuration uses a fill-forward approach to handle any gaps in the configuration timeline.
- **Key fields**: `revenue_percentage` applied via temporal joins, with forward-filling for continuous coverage

### Component D: Revenue calculation
- **Purpose**: Calculates the protocol's revenue portion of total fees
- **Logic**: Combines perpetual trading fees and liquidation fees, then multiplies each by the applicable revenue percentage for the transaction date. Daily timestamps are truncated to aggregate fees by day. The revenue calculation processes both fee streams (trading and liquidation) separately, applies the revenue percentage split, then unions the results. USDC amounts are converted to USD using end-of-day price feeds, and the final results are aggregated daily with zero-filling for missing periods.
- **Key fields**: Daily aggregated `revenue` amounts in USD, with business line classification as "Perpetual trading"

### Component E: Supply-side fees calculation
- **Purpose**: Calculates the liquidity provider portion of total fees
- **Logic**: Mirrors the revenue calculation but applies (1 - revenue_percentage) to determine the liquidity provider share. Both trading and liquidation fees are processed with the complementary percentage split, ensuring that revenue plus supply-side fees equals total fees. Daily timestamp truncation aggregates fees by day, USDC amounts are converted to USD, and results include zero-filling for consistent daily metrics.
- **Key fields**: Daily aggregated `fees_supply_side` amounts in USD, representing liquidity provider distributions

### Final aggregation
- **Combining components**: Revenue and supply-side fees are combined by joining on timestamp, creating the total fees metric as the sum of both components
- **Currency conversion**: All USDC-denominated fees are converted to USD using end-of-day price feeds, with decimal correction from 8-decimal format to standard precision
- **Time aggregation**: Fees are aggregated daily using timestamp truncation, with consistent daily boundaries across all components
- **Final calculation**: Total fees equals the sum of protocol revenue plus supply-side fees distributed to liquidity providers, representing complete fee capture from all Pika Protocol trading and liquidation activities

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

Total value users pay to use a protocol (gross fees, user-paid fees).

Pika ProtocolPIKA

Fees

Fees

Competitive landscape