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

Deri Protocol is a non-custodial exchange for perpetual contracts built on BNB Chain and Arbitrum. Deri Protocol was founded by an anonymous team and launched in 2021.

DERI token holders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

governance

github

twitter

etherscan

website

Derivative exchanges

Deri Protocol

# Deri Protocol Revenue Methodology

## 1. Overview

The Deri Protocol revenue metric calculates the portion of trading fees that goes to the protocol rather than liquidity providers. This represents the protocol's earnings from perpetual derivatives trading on Arbitrum and BSC. The calculation takes total trading fees from perpetual trading activities and applies a revenue split percentage (80% to protocol, 20% to liquidity providers) that has been in effect since January 6, 2022.

## 2. Data sources

- **Blockchain events**: Parsed `SymbolManager_Trade_event` logs from Deri Protocol v3 contracts on Arbitrum and BSC containing trading fee data
- **Market events**: Parsed `Router_ExecuteTrade_event` logs from Deri Protocol v3 contracts providing symbol names for market identification  
- **External data**: End-of-day DERI token price feeds from Ethereum for USD conversion of DLT-denominated markets
- **Token metadata**: Manual symbol mappings for 14 specific trading pairs not available in blockchain events (primarily BSC markets like BTCUSD options and various perpetuals)

## 3. Step-by-step calculation

### Component A: Trading fee extraction
- **Purpose**: Extract raw trading fee data from Deri Protocol perpetual trading events
- **Logic**: Parse `SymbolManager_Trade_event` logs from Arbitrum and BSC to extract the `tradeFee` field (in 18 decimals), `symbolId` for market identification, and `account_address` for market type classification. Join with `Router_ExecuteTrade_event` logs using transaction hash to obtain `symbolName` for market identification. Apply negative fee filtering by setting any negative `tradeFee` values to zero. Convert 18-decimal fee amounts to standard format by dividing by 10^18.
- **Key fields**: `tradeFee` (converted from 18 decimals), `symbolId`, `symbolName`, `account_address`, `transaction_hash`

### Component B: Symbol mapping and market classification  
- **Purpose**: Map symbol identifiers to human-readable market names and classify market denomination types
- **Logic**: Apply two-tier symbol mapping approach. First, use contract-derived symbol names from `Router_ExecuteTrade_event` logs where available. Second, apply manual symbol mappings for 14 hardcoded trading pairs (including ETH options, BTC options, and various perpetual contracts) that don't appear in events. Classify markets by denomination type using account addresses - DLT-denominated markets use address `0x8bb7ec8fb31dd6d33d9b71c1bd407f883cac7a91` while USD markets use three specific addresses (`0x543a9fa25ba9a16612274dd707ac4462ed6988fa`, `0x28ed1dbdb9bc5b7fe67c27c1d767db42ae6f61f7`, `0x741c8e810cd1c7bab6565e850b775fc33c15c084`).
- **Key fields**: `symbol_name`, `token_symbol`, market denomination classification

### Component C: USD conversion and fee aggregation
- **Purpose**: Convert all fees to USD and aggregate by day for consistent reporting  
- **Logic**: Handle market denomination differences through separate processing paths. For DLT-denominated markets, multiply fee amounts by end-of-day DERI token prices from Ethereum to get USD values. For USD-denominated markets, use fee amounts directly without conversion. Aggregate all fees by day using timestamp truncation to daily boundaries. Group by chain, business line, market sector, product version, and token information for dimensional reporting.
- **Key fields**: USD-converted `amount`, daily `timestamp`, `chain`, dimensional attributes

### Component D: Revenue percentage application
- **Purpose**: Apply protocol revenue split to determine protocol earnings versus liquidity provider payments
- **Logic**: Apply time-based revenue percentage split using historical configuration. Since January 6, 2022 (the first day Deri Protocol generated fees), apply 80% (0.8) revenue percentage to all trading fees. Use forward-fill logic to ensure all days have the appropriate revenue percentage applied. The remaining 20% represents fees paid to liquidity providers.
- **Key fields**: `revenue_percentage` (0.8), effective date configuration

### Final aggregation  
- **Combining components**: Multiply aggregated daily fees by the revenue percentage (0.8) using the `safe_multiply` function to calculate protocol revenue share
- **Currency conversion**: All fees converted to USD either through DERI token price multiplication (DLT markets) or direct usage (USD markets)
- **Time aggregation**: Daily aggregation using timestamp truncation with zero-filling for missing days via the finalization macro
- **Final calculation**: Protocol revenue equals total trading fees multiplied by 80% revenue share, representing the portion of fees retained by the protocol rather than distributed to liquidity providers

*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.

Deri ProtocolDERI

Revenue

Revenue

Competitive landscape

Chain breakdown