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 (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for MerkleTrace measures the count of distinct unique traders who executed at least one position during any 7-day rolling window period. This metric answers the business question: "How many unique users are actively trading on the MerkleTrace protocol each week?" The calculation uses HyperLogLog (HLL) data structures to efficiently count distinct users across overlapping 7-day windows while avoiding double-counting users who trade on multiple days within the same week.

## 2. Data sources

- **Blockchain events**: Parsed `Trading_PositionEvent` events from the MerkleTrace v1 protocol on Aptos blockchain, which capture when traders execute positions or trades
- **Transaction data**: Aptos blockchain transaction records containing event logs with trader addresses, timestamps, and transaction metadata
- **Chain availability data**: Configuration data that defines which blockchain networks are active and available for metric calculations

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identifies all user trading interactions from blockchain events to establish the base dataset of active traders
- **Logic**: Extracts distinct trading events from Aptos blockchain where users executed positions through the MerkleTrace protocol. Filters for `Trading_PositionEvent` events which represent actual trade executions rather than other protocol interactions. Each event contains the trader's address, transaction timestamp, and trading context. Only includes events where orders were actually executed (non-zero order IDs)
- **Key fields**: `user_address` (trader wallet address), `block_timestamp` (when the trade occurred), `chain` (blockchain network), `user_type` (classified as "Trader")

### Component B: Daily active user calculation  
- **Purpose**: Aggregates user interactions into daily distinct active user counts as the foundation for weekly calculations
- **Logic**: Groups all trading interactions by day using timestamp truncation to day level. Deduplicates user addresses within each day to ensure each trader is only counted once per day regardless of how many trades they made. Maintains dimensional breakdowns by chain and user type for downstream analysis
- **Key fields**: `timestamp` (day-level timestamp), `user_dau` (distinct user address for that day), `chain` (blockchain network), `user_type` (user classification)

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user lists into HyperLogLog data structures for efficient distinct counting across time windows
- **Logic**: Takes each day's list of distinct active users and initializes an HLL sketch with precision parameter 15. This allows for approximate distinct counting that can be efficiently merged across multiple days while maintaining high accuracy for cardinality estimation. Groups by all dimensional attributes to preserve breakdown granularity
- **Key fields**: `hll` (HyperLogLog sketch of daily users), `timestamp` (day), `chain_id`, `user_type`, `product_id`

### Component D: Rolling window generation
- **Purpose**: Creates 7-day rolling windows by generating a datespine and associating each day with its preceding 6 days
- **Logic**: Generates a complete datespine covering all days from the earliest user activity to yesterday. For each day in the datespine, creates joins to the current day plus the previous 6 days to form 7-day windows. This ensures every day gets evaluated as the end of a 7-day period, creating overlapping weekly windows that capture user activity patterns without gaps
- **Key fields**: `timestamp` (the end day of the 7-day window), `joinday` (each of the 7 days within that window)

### Component E: Window data aggregation
- **Purpose**: Combines daily HLL sketches across each 7-day window to prepare for distinct user counting
- **Logic**: Joins the rolling window structure with daily HLL data to associate each 7-day window period with the corresponding daily user sketches. This creates a dataset where each row represents one day within a 7-day window, with its associated HLL sketch of users who were active on that specific day
- **Key fields**: `timestamp` (window end date), `hll` (daily HLL sketch), dimensional attributes preserved from daily data

### Component F: Dimensional breakdowns
- **Purpose**: Calculates WAU across different business dimensions to support various analytical perspectives
- **Logic**: Aggregates the windowed HLL data across four different dimensional breakdowns: project-level (overall protocol WAU), chain-level (WAU per blockchain), user-type level (WAU by trader category), and product-level (WAU by specific products). For each breakdown, merges HLL sketches across the relevant dimensions and extracts the distinct count estimate. Sets non-relevant dimensions to null to maintain consistent schema structure
- **Key fields**: `dimensions` (breakdown type), `user_wau` (distinct weekly active user count), relevant dimensional fields populated while others set to null

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single result set with consistent schema structure, allowing for flexible analysis across different business perspectives
- **HLL merging and extraction**: Uses HLL merge_partial operations to combine daily sketches within each 7-day window, then extracts the final distinct count estimate using hll_count.extract function
- **Time aggregation**: Maintains daily granularity for the metric output, where each day represents the WAU for the 7-day period ending on that day
- **Final calculation**: The final WAU value represents the estimated count of distinct users who were active on at least one day within any given 7-day rolling window, calculated using probabilistic HyperLogLog algorithms for scalable distinct counting

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

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

Merkle TradeMKL

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape