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 Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who have actively traded on Deri Protocol within a rolling 30-day window. This metric tracks engagement with the protocol's derivatives trading platform by identifying unique trader addresses that have executed at least one trade in the past 30 days. The calculation uses HyperLogLog approximation to efficiently handle large user datasets and provides dimensional breakdowns across chains, user types, and products.

## 2. Data sources

- **Blockchain events**: Parsed `Trade` events from Deri Protocol v3's `SymbolManager` contract on Arbitrum and BSC networks
- **Transaction data**: Blockchain transaction timestamps and transaction hashes for event correlation
- **Chain metadata**: Chain availability filters to ensure data quality and completeness

## 3. Step-by-step calculation

### Component A: User identification from trading events
- **Purpose**: Identify unique users who have executed trades on Deri Protocol
- **Logic**: Extract trader addresses from `Trade` events emitted by the `SymbolManager` contract across Arbitrum and BSC chains. Each event contains the `pTokenId` parameter and trader address from perpetual futures trading activities. Users are classified as 'address' type within the 'derivatives' market sector and 'perpetual' business segment. Chain availability filters are applied to ensure only complete and validated data is included.
- **Key fields**: `block_timestamp` for temporal tracking, `transaction_hash` for deduplication, `chain` identifier, and `user_address` (derived from the `pTokenId` parameter)

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily snapshots of unique active users
- **Logic**: Group trading events by day using timestamp truncation and identify distinct user addresses per day. This creates a foundation dataset showing which users were active on each specific day. The aggregation maintains dimensional attributes including chain, user type, market sector, business segment, and product identifiers.
- **Key fields**: `timestamp` truncated to day granularity, `chain` for network identification, `user_type` classification, and `user_dau` containing the unique user address

### Component C: HyperLogLog sketch preparation
- **Purpose**: Convert daily user data into probabilistic data structures for efficient MAU calculation
- **Logic**: Initialize HyperLogLog sketches with precision 15 for each day's unique user set. This approximation method enables efficient merging of user sets across time windows without storing individual user identifiers. Each daily user count is converted into an HLL sketch that can be combined with other sketches to calculate approximate distinct counts.
- **Key fields**: `hll` containing the HyperLogLog sketch representation of daily unique users

### Component D: Rolling 30-day window creation
- **Purpose**: Create overlapping 30-day periods for MAU calculation
- **Logic**: Generate a complete datespine covering all days from the earliest available data to the current date. For each date in the spine, create a 30-day lookback window by joining with the previous 29 days of HLL data. This ensures every day has a complete 30-day context for MAU calculation, handling gaps in the underlying data by using the datespine structure.
- **Key fields**: `timestamp` as the window end date, `joinday` representing each day within the 30-day window

### Component E: MAU calculation with dimensional breakdowns
- **Purpose**: Calculate MAU across multiple dimensional perspectives
- **Logic**: Merge HyperLogLog sketches within each 30-day window and extract the approximate distinct user count. Create four separate dimensional views: project-level (overall MAU), chain-level (MAU by blockchain), user-type-level (MAU by user classification), and product-level (MAU by product identifier). Each breakdown uses HLL merge operations to combine user sets appropriately, with null values for non-applicable dimensions.
- **Key fields**: `user_mau` containing the final distinct user count, `dimensions` indicating the breakdown type, relevant dimension identifiers (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project, chain, user type, product) into a single result set with consistent schema structure
- **Time aggregation**: MAU values represent rolling 30-day windows ending on each date, providing daily MAU metrics that reflect user activity over the trailing month
- **Final calculation**: Extract distinct user count from merged HyperLogLog sketches using `hll_count.extract(hll_count.merge_partial(hll))` to produce the approximate MAU value for each dimension and time period

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

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

Deri ProtocolDERI

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown