Infrastructure

Maestro

# Maestro Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Maestro measures the number of unique users who actively traded and paid fees on the Maestro protocol within a 30-day rolling window. This metric provides insight into user engagement and platform adoption by tracking traders who generate fee revenue. The calculation uses HyperLogLog approximation for efficient computation of unique user counts across large datasets and provides breakdowns by chain, user type, and product dimensions.

## 2. Data sources

- **Solana native token transfers**: SOL transfer events on the Solana blockchain, specifically capturing transfers to Maestro fee collection addresses
- **Transaction data**: Solana transaction records including transaction signers, timestamps, and transfer amounts
- **Blockchain timestamps**: Block-level timestamps from Solana for accurate temporal aggregation

## 3. Step-by-step calculation

### Component A: Fee collection identification
- **Purpose**: Identifies users who paid fees to the Maestro protocol
- **Logic**: Extracts SOL transfers from Solana blockchain data where the recipient address is the Maestro fee account `MaestroUL88UBnZr3wfoN7hqmNWFi3ZYCGqZoJJHE36`. Filters out transfers where the transaction signer is the fee account itself to avoid counting internal transactions. Captures the transaction signer as the user, transfer amount, block timestamp, and transaction identifier.
- **Key fields**: `transaction_signer` (user address), `block_timestamp` (transaction time), `amount` (fee paid), `transaction_id` (unique identifier)

### Component B: Daily active user calculation  
- **Purpose**: Converts fee payments into daily unique active users
- **Logic**: Groups fee transactions by day using timestamp truncation to identify unique users per day. Classifies all users as 'Trader' user type since they are engaging with the protocol through fee-generating activities. Maintains chain identifier as 'solana' and preserves product identification for dimensional analysis.
- **Key fields**: `timestamp` (day boundary), `user_dau` (unique user address), `user_type` (set to 'Trader'), `chain` (blockchain identifier)

### Component C: HyperLogLog preparation
- **Purpose**: Converts daily user sets into HyperLogLog sketches for efficient approximate counting
- **Logic**: Creates HLL sketches from daily active user data with precision parameter of 15, enabling scalable computation of unique counts. Groups data by timestamp, chain, user type, and product dimensions while maintaining the underlying user information in HLL format.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp_grain` (aggregation level), dimensional grouping fields

### Component D: Rolling window creation
- **Purpose**: Establishes 30-day rolling windows for MAU calculation
- **Logic**: Generates a complete datespine covering all days from the earliest data point to yesterday. For each day in the datespine, creates joins to the previous 29 days (30 days total) using timestamp array generation. This ensures comprehensive coverage without gaps in the time series, allowing for accurate rolling window calculations even when some days have no activity.
- **Key fields**: `timestamp` (target day), `joinday` (days within 30-day window)

### Component E: Window aggregation
- **Purpose**: Combines HLL sketches across 30-day windows
- **Logic**: Joins the rolling window framework with daily HLL data, matching each target day with its corresponding 30-day historical period. For each combination, retrieves the HLL sketch containing that day's unique users. Applies incremental loading filters to optimize processing by focusing on recently modified data periods.
- **Key fields**: Window `timestamp`, daily `hll` sketches, dimensional breakdowns

### Component F: Multi-dimensional MAU calculation
- **Purpose**: Calculates MAU across different analytical dimensions
- **Logic**: Processes four separate dimensional breakdowns: project-level (all dimensions collapsed), chain-level (preserving chain identifier), user type-level (preserving user classification), and product-level (preserving product identifier). For each dimension, merges HLL sketches across the 30-day window using HyperLogLog merge operations and extracts the approximate unique count. Sets non-relevant dimensional fields to null for clean data structure.
- **Key fields**: `user_mau` (approximate unique user count), `dimensions` (breakdown type), dimensional identifier fields

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project_dbt_tag, chain, user_type, product_id) into a single result set, preserving the appropriate dimensional identifiers for each breakdown type
- **Currency conversion**: Not applicable - this is a user count metric rather than a financial metric
- **Time aggregation**: Uses daily timestamps with 30-day rolling windows, partitioned by month for efficient storage and querying
- **Final calculation**: Applies the `finalize_metric_user_mau` macro to standardize the schema, set data identifiers to 'maestro', and implement fill strategy with zeros for missing periods. The final metric represents the approximate number of unique users who paid fees to Maestro within any 30-day period ending on the given date.

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

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

Maestro

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown