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

Merkle Trade is a non-custodial perpetual exchange protocol built on Aptos.

MKL tokenholders own and govern the protocol. They do currently take a cut of the total trading fees paid by traders (revenue). Merkle Trade's investors include Arrington Capital, Hashed, etc.

twitter

discord

website

github

Derivative exchanges

Merkle Trade

# Merkle Trade Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who have actively traded on Merkletrade within any 30-day rolling window. This metric answers the business question: "How many distinct traders are engaging with the platform over monthly periods?" The calculation uses HyperLogLog probabilistic counting to efficiently aggregate daily active users across 30-day sliding windows, providing multiple dimensional breakdowns for analysis.

## 2. Data sources

- **Aptos blockchain events**: Parsed `Trading_PositionEvent_event` logs from the merkletrade_v1_aptos schema containing trader interactions
- **Transaction metadata**: Aptos transaction records including block timestamps, transaction hashes, and event indexes for timing and deduplication
- **Chain availability data**: Configuration data ensuring only periods with complete data coverage are included in calculations

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identifies all trader addresses that executed trades on each day
- **Logic**: Extracts trader addresses from Aptos `Trading_PositionEvent_event` logs, focusing on actual order executions rather than just order placements. Each event contains a trader address (`user` parameter) and is classified as 'Trader' user type. The system deduplicates by transaction hash and event index to ensure each unique trading action is counted once. Block timestamps are truncated to day granularity to group activities by calendar day.
- **Key fields**: `user_address` (trader wallet address), `block_timestamp` (execution time), `transaction_hash` (unique transaction identifier), `user_type` (always 'Trader'), `chain` (always 'aptos')

### Component B: Daily active user aggregation  
- **Purpose**: Counts unique daily active traders and prepares data for monthly window calculations
- **Logic**: Groups the extracted trader activities by day and creates daily snapshots of unique active users. The system applies chain availability filters to ensure only complete data periods are included. Each daily record contains the timestamp, user address, chain, and user type information needed for downstream aggregation.
- **Key fields**: `timestamp` (day-level granularity), `user_dau` (unique trader address), `chain` (blockchain identifier), `user_type` (trader classification), `product_id` (null for this protocol)

### Component C: HLL initialization and window preparation
- **Purpose**: Converts daily user data into HyperLogLog structures for efficient monthly counting
- **Logic**: Initializes HyperLogLog data structures with 15-bit precision for each daily user set, enabling probabilistic counting of distinct users across monthly windows. Creates a comprehensive datespine covering all days from the earliest data through yesterday, then generates 30-day rolling windows by cross-joining each day with its preceding 29 days using timestamp array functions.
- **Key fields**: `hll` (HyperLogLog structure containing daily users), `timestamp` (target day for MAU calculation), `joinday` (contributing days within the 30-day window)

### Component D: Monthly window aggregation
- **Purpose**: Merges daily HLL structures across 30-day windows to count monthly active users
- **Logic**: For each calendar day, collects all daily active user HLL structures from the current day plus the preceding 29 days, creating a 30-day rolling window. Joins the window framework with the daily HLL data to ensure complete coverage. This approach ensures that each MAU calculation includes exactly 30 days of user activity, regardless of whether users were active on consecutive days.
- **Key fields**: `hll` (daily HLL structures to be merged), `timestamp` (target date for MAU), `chain_id`, `user_type`, `product_id` (dimensional attributes)

### Component E: Dimensional breakdowns
- **Purpose**: Creates multiple views of MAU data across different analytical dimensions
- **Logic**: Generates four distinct dimensional breakdowns by grouping and aggregating the 30-day window data. Project-level breakdown aggregates all users regardless of other attributes. Chain-level breakdown maintains chain identity while nullifying other dimensions. User type breakdown preserves user classification. Product breakdown maintains product identity. Each breakdown merges the HLL structures within its grouping and extracts the final distinct user count.
- **Key fields**: `dimensions` (breakdown type identifier), `user_mau` (distinct monthly active users), dimension-specific fields (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple analytical perspectives of the same underlying MAU data
- **Currency conversion**: Not applicable - this metric counts users rather than monetary values
- **Time aggregation**: Each record represents a specific calendar day with its corresponding 30-day trailing MAU count, creating a daily time series of monthly active user metrics
- **Final calculation**: The final MAU value for any given day equals the count of distinct user addresses that had at least one trading activity within the 30-day window ending on that day, calculated using HyperLogLog merge and extract operations for computational efficiency

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

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

Merkle TradeMKL

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape