website

twitter

Infrastructure

Trojan

# Trojan Active users (monthly) Methodology

## 1. Overview

The Trojan Monthly Active Users (MAU) metric measures the number of unique users who actively engaged with the Trojan protocol on Solana over rolling 30-day periods. The metric identifies active users by tracking fee payments to the protocol's designated fee collection account, using HyperLogLog aggregation to efficiently calculate approximate unique user counts across multiple dimensions including project-level, chain-level, user type, and product breakdowns.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Solana native token transfers**: Records of SOL token transfers on the Solana blockchain, containing transaction details, signer addresses, timestamps, amounts, and recipient addresses
- **Fee account transactions**: Specific transfers directed to Trojan's designated fee collection account, indicating active protocol usage
- **Solana transaction logs**: Blockchain transaction records that capture user interactions and protocol fee payments

## 3. Step-by-step calculation

### Component A: Fee transaction identification
- **Purpose**: Identify users who actively engaged with the Trojan protocol through fee payments
- **Logic**: The system filters Solana native token transfer records to capture only transfers sent to Trojan's specific fee collection account (`9yMwSPk9mrXSN7yDHUuZurAh1sjbJsfpUqjZ7SvVtdco`). Each qualifying transaction represents active protocol usage, with the transaction signer identified as the active user. The token address is standardized to SOL's canonical identifier.
- **Key fields**: `block_timestamp` for timing, `transaction_signer` as the user identifier, `amount` for transfer value, and `to_address` for fee account filtering

### Component B: Daily active user aggregation
- **Purpose**: Transform fee transactions into daily unique user counts
- **Logic**: Fee transactions are grouped by day using timestamp truncation to daily boundaries. Within each day, unique transaction signers are identified as daily active users and classified with a user type of 'Trader'. The system applies chain availability filtering to ensure data completeness and quality across supported blockchain networks.
- **Key fields**: `timestamp` truncated to day granularity, `user_type` set to 'Trader', `chain` identifier, and `signer` as the unique user identifier

### Component C: HyperLogLog sketch preparation
- **Purpose**: Convert daily user data into efficient approximate counting structures
- **Logic**: Daily active user data is transformed into HyperLogLog sketches using an initialization function with 15-bit precision. This allows for efficient approximate distinct counting when aggregating across multiple time periods. The sketches are grouped by timestamp, chain, user type, and product dimensions.
- **Key fields**: `hll` sketch containing approximate user counts, dimensional grouping fields for aggregation boundaries

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling time windows for MAU calculation
- **Logic**: A complete date spine is generated covering the full data range, then expanded to create rolling 30-day windows. For each target date, the system generates a 30-day lookback period (29 previous days plus the current day) using timestamp arrays. This ensures comprehensive coverage without gaps in the time series.
- **Key fields**: `timestamp` for the target date, `joinday` for each day within the 30-day window

### Component E: Window-based HLL aggregation
- **Purpose**: Combine daily HLL sketches across 30-day rolling windows
- **Logic**: The rolling windows are joined with daily HLL sketches to aggregate user data across each 30-day period. This creates a comprehensive view of unique users active within each rolling monthly window, maintaining dimensional breakdowns for chain, user type, and product attributes.
- **Key fields**: `timestamp` for the window end date, `hll` sketches aggregated across the window period, dimensional grouping fields

### Component F: Multi-dimensional breakdowns
- **Purpose**: Calculate MAU across different analytical dimensions
- **Logic**: The system creates four separate MAU calculations: project-level aggregation (combining all dimensions), chain-level breakdown (grouping by blockchain), user type breakdown (grouping by user classification), and product-level breakdown (grouping by product identifier). Each breakdown uses HLL merge operations to combine sketches and extract final approximate unique user counts.
- **Key fields**: `dimensions` indicating breakdown type, `chain_id`, `user_type`, `product_id` for dimensional grouping, `user_mau` containing final counts

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive MAU dataset with multiple analytical perspectives
- **Time aggregation**: Rolling 30-day windows ensure each date reflects MAU for the preceding month period, with daily granularity for trend analysis
- **Final calculation**: HyperLogLog merge operations combine user sketches across time windows, with extract functions providing final approximate unique user counts. The `finalize_metric_user_mau` macro standardizes the output schema and fills missing periods with zero values to maintain complete time series continuity

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

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

Trojan

Active users (monthly)

Active users (monthly)

Competitive landscape