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

## 1. Overview

Perpetual Protocol revenue represents the portion of trading and liquidation fees that accrue to the protocol itself, rather than to liquidity providers. This metric measures the protocol's fee income from its derivatives trading platform across two versions: v1 on Gnosis Chain and v2 on Optimism. The calculation applies version-specific and component-specific revenue sharing rules to determine what percentage of collected fees constitute protocol revenue versus rewards distributed to liquidity providers.

## 2. Data sources

The methodology uses several key data sources:
- **Blockchain events**: Parsed Perpetual Protocol `PositionChanged` events from Gnosis Chain (v1) and Optimism (v2) containing trading fee data
- **Blockchain events**: Parsed Perpetual Protocol `PositionLiquidated` events from Gnosis Chain (v1) and Optimism (v2) containing liquidation fee data  
- **External data**: End-of-day token price feeds for USD conversion of fees paid in XDAI and USDC
- **Configuration data**: Static mapping of AMM/market contract addresses to their corresponding token symbols
- **Configuration data**: Time-based revenue percentage splits defining how fees are divided between protocol revenue and liquidity provider rewards

## 3. Step-by-step calculation

### Component A: Trading fee extraction
- **Purpose**: Captures all trading fees generated from position changes across both protocol versions
- **Logic**: Extracts fee data from `PositionChanged` events emitted by ClearingHouse contracts on both Gnosis Chain (v1) and Optimism (v2). The `fee` field from each event represents trading fees paid by users. Fee amounts are converted from 18-decimal precision to standard token units by dividing by 10^18. Events are tagged with version information, chain details, and component type as 'Trading'
- **Key fields**: `fee` amounts, `amm` addresses (v1) or `baseToken` addresses (v2) for market identification, block timestamps, and transaction details

### Component B: Liquidation fee extraction  
- **Purpose**: Captures all liquidation fees generated when positions are liquidated across both protocol versions
- **Logic**: Extracts fee data from `PositionLiquidated` events emitted by ClearingHouse contracts on both chains. The `liquidationFee` field represents fees collected during position liquidations. Like trading fees, amounts are converted from 18-decimal precision to standard units. Events are tagged with version information and component type as 'Liquidation'
- **Key fields**: `liquidationFee` amounts, AMM/market addresses for categorization, block timestamps, and account addresses

### Component C: Fee aggregation and USD conversion
- **Purpose**: Combines all fee data and standardizes it for revenue calculation
- **Logic**: Trading and liquidation fees are unioned together and joined with market dimension data to map contract addresses to token symbols. Daily aggregation is performed by truncating block timestamps to day boundaries. All fees are converted to USD using end-of-day price feeds, with v1 fees originally in XDAI and v2 fees in USDC. The system handles cases where new markets may not be in the dimension table by marking them as 'Unknown'
- **Key fields**: Daily aggregated `fees` in USD, `component` type (Trading/Liquidation), `version` (v1/v2), `token_symbol` for market identification

### Component D: Revenue percentage application
- **Purpose**: Applies protocol-specific revenue sharing rules to determine what portion of fees becomes protocol revenue
- **Logic**: Revenue calculation varies by protocol version and fee component type. For v1 Trading fees, 100% goes to the protocol as revenue. For all Liquidation fees (both v1 and v2), 0% goes to the protocol. For v2 Trading fees, a time-based percentage split is applied: 10% of fees went to protocol revenue from launch until June 22, 2022, then 20% afterwards. This is implemented through a temporal dimension table that maps dates to revenue percentages
- **Key fields**: `revenue_percentage` applied based on timestamp, calculated `revenue` amount after percentage application

### Final aggregation
- **Combining components**: All revenue amounts from trading and liquidation components are summed together at the daily level, grouped by chain, account, and market dimensions
- **Currency conversion**: USD conversion happens before revenue percentage application, using end-of-day price feeds matched to the fee generation date
- **Time aggregation**: Daily boundaries are established by truncating blockchain event timestamps to day precision, ensuring consistent daily totals
- **Final calculation**: The final revenue metric represents the sum of all protocol revenue across both versions, calculated as: (v1 Trading fees × 100%) + (v1 Liquidation fees × 0%) + (v2 Trading fees × time-based percentage) + (v2 Liquidation fees × 0%)

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

Perpetual ProtocolPERP

Revenue

Revenue

Competitive landscape

Chain breakdown