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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average revenue generated per daily active user on the MerkleTrade platform. This metric is calculated by dividing total daily revenue by the number of daily active users. ARPU provides insight into revenue efficiency and user monetization effectiveness. The calculation uses a division approach where daily revenue (from trading fees and rebates) is divided by daily active user count (from order execution events).

## 2. Data sources

The calculation relies on several raw data sources from the Aptos blockchain:

- **Trading activity events**: Parsed Aptos `PositionEvent` events from the MerkleTrade trading contract that capture order executions and identify active traders
- **Fee distribution events**: Aptos `DepositFeeEvent` events from the MerkleTrade fee distributor contract containing developer fees and staking fees
- **Referral rebate events**: Aptos `RebateEvent` events from the MerkleTrade referral system capturing rebate payments to users  
- **End-of-day price feeds**: Token price data for converting lzUSDC amounts to USD values
- **Token metadata**: Token decimal information for proper amount normalization, specifically for lzUSDC (LayerZero USDC)

## 3. Step-by-step calculation

### Component A: Daily active users
- **Purpose**: Identifies and counts unique users who executed orders on each day
- **Logic**: Extracts trader addresses from Aptos `PositionEvent` events where order executions occurred. These events contain a `user` parameter identifying the trader address. Events are filtered to day boundaries and distinct user addresses are counted. HyperLogLog algorithms enable efficient distinct counting across multiple dimensions including chain, user type, and product breakdowns while maintaining scalability
- **Key fields**: `user` address from position events, `block_timestamp` for daily grouping, `user_type` classification as 'Trader'

### Component B: Daily revenue calculation  
- **Purpose**: Calculates total revenue generated from trading activities and referral programs
- **Logic**: Combines revenue from two sources. First, fee distributions from `DepositFeeEvent` events where `dev_amount` and `stake_amount` fields represent fees paid to developers and stakers respectively. Second, referral rebates from `RebateEvent` events where the `rebate` field represents payments made to referring users. All amounts are in lzUSDC token format. Revenue streams are aggregated by day and converted to USD using end-of-day price feeds
- **Key fields**: `dev_amount` and `stake_amount` from fee events, `rebate` amount from referral events, `block_timestamp` for daily aggregation, `token_address` identifying lzUSDC

### Component C: Currency conversion and standardization
- **Purpose**: Converts lzUSDC amounts to USD and applies proper decimal corrections
- **Logic**: Raw token amounts are converted to USD using end-of-day price feeds specific to the lzUSDC token. Decimal correction is applied based on the token's decimal configuration to ensure accurate value representation. The lzUSDC token address `0xf22bede237a07e121b56d91a491eb7bcdfd1f5907926a9e58338f964a01b17fa::asset::USDC` is used consistently across all revenue calculations
- **Key fields**: Raw token amounts converted to `revenue` in USD, `token_address` for price lookup, decimal precision adjustments

### Final aggregation
- **Combining components**: Daily active user counts and daily revenue totals are joined by timestamp to create matched pairs for each day. The join ensures both metrics exist for the same time periods
- **Currency conversion**: All revenue calculations use end-of-day USD conversion rates applied after lzUSDC amounts are aggregated
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation to day level, ensuring consistent time alignment between user counts and revenue totals
- **Final calculation**: ARPU is calculated by dividing total daily revenue (in USD) by the daily active user count. Days with zero users are handled with appropriate null or zero values to prevent division errors. Missing days are filled with zeros to maintain complete time series continuity

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

Merkle TradeMKL

Archived

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape