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

## 1. Overview

The MerkleTrade Daily Active Users (DAU) metric measures the number of unique user addresses that executed trading positions on the MerkleTrade protocol each day. This metric provides insights into daily user engagement and platform adoption by counting distinct traders who performed position-related activities. The calculation identifies active users through their participation in trading events, specifically position executions captured in blockchain event logs.

## 2. Data sources

The DAU calculation relies on the following raw data sources:

- **Aptos blockchain event logs**: Parsed `Trading_PositionEvent_event` logs from the MerkleTrade v1 protocol on Aptos chain
- **Transaction metadata**: Block timestamps, transaction hashes, and event indices from Aptos transactions
- **Protocol events**: Position-related events that indicate user trading activity on the MerkleTrade platform
- **Chain availability data**: Information about supported chain coverage periods to ensure accurate historical reporting

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Identifies all trading-related user interactions from MerkleTrade protocol events
- **Logic**: Extracts user addresses from parsed `Trading_PositionEvent_event` logs on the Aptos blockchain. The system uses a configuration-driven approach that maps specific event types to user parameters. For Aptos, it processes position events where the `user` parameter identifies the trader address. Each event represents a position execution or trading activity by a user
- **Key fields**: Block timestamp (`block_timestamp`), user address (`user`), transaction hash, event index for unique identification, and chain identifier

### Component B: User type classification
- **Purpose**: Categorizes users based on their interaction type with the protocol
- **Logic**: Classifies all users extracted from `Trading_PositionEvent_event` logs as 'Trader' type users, since these events specifically represent trading activities. The user type classification is determined by the source event type, allowing for potential expansion to other user categories in the future
- **Key fields**: User type (`user_type` = 'Trader'), user address converted to string format for consistency, chain identifier

### Component C: Deduplication and event processing
- **Purpose**: Ensures each unique user interaction is counted only once per transaction
- **Logic**: Applies distinct selection across user address, transaction hash, and event index to prevent double-counting of the same trading event. This handles cases where the same position event might be recorded multiple times within the same transaction, ensuring accurate user activity representation
- **Key fields**: Distinct combination of `user_address`, `transaction_hash`, and `event_index`

### Final aggregation
- **Combining components**: Processes the deduplicated user activity data by truncating block timestamps to daily boundaries using day-level granularity
- **Time aggregation**: Groups all user activities by calendar day, creating daily snapshots of active users. The timestamp truncation ensures consistent daily boundary handling across different time zones
- **Chain filtering**: Applies chain availability filtering to exclude data from periods when chain coverage was incomplete or unavailable, ensuring accurate historical DAU reporting
- **Final calculation**: Counts distinct user addresses per day, chain, and user type combination. Each unique user address that performed at least one trading activity during a given day contributes exactly one to the DAU count for that day, regardless of how many transactions or position events they generated

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

Unique revenue-generating users over a fixed 24-hour window.

Merkle TradeMKL

Archived

Active users (daily)

Active users (daily)

Competitive landscape