website

twitter

Infrastructure

Helio

# Helio Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for heliopay measures the number of unique users who generated fee payments to heliopay over a rolling 30-day period. This metric answers the business question "How many distinct users actively used heliopay services in the past 30 days?" The calculation uses a rolling window approach, where each day's MAU represents unique users who paid fees during that day and the previous 29 days. The metric provides dimensional breakdowns by chain, user type, and product to enable detailed analysis of user engagement patterns.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **Solana native transfers**: Native SOL transfer events on the Solana blockchain, capturing transfers between addresses including transaction signers, recipients, amounts, and block timestamps
- **Solana SPL token transfers**: SPL token transfer events on Solana, including token addresses, amounts, sender/receiver information, and ownership details
- **Solana transaction records**: Transaction metadata including transaction signers (the addresses that initiated and signed transactions) and unique transaction identifiers
- **Solana block data**: Block timestamps providing precise timing information for when transactions occurred

## 3. Step-by-step calculation

### Component A: SOL fee collection identification
- **Purpose**: Identifies users who paid SOL fees to heliopay services
- **Logic**: Filters Solana native transfer events to capture transfers directed TO the heliopay fee collection account `FudPMePeNqmnjMX19zEKDfGXpbp6HAdW6ZGprB5gYRTZ`. The transaction signer represents the user who initiated the fee payment. Internal transfers are excluded by filtering out transactions where the signer is also the fee account itself, preventing double-counting of internal operations
- **Key fields**: `block_timestamp` for timing, `transaction_signer` as the user identifier, `amount` for fee value, and `token_address` set to the SOL token identifier

### Component B: SPL token fee collection identification  
- **Purpose**: Identifies users who paid SPL token fees to heliopay services
- **Logic**: Filters Solana SPL token transfer events to capture transfers where the destination owner address is the heliopay fee collection account. Similar to SOL fees, the transaction signer represents the fee-paying user, and internal transfers are excluded by filtering out transactions where the signer is the fee account
- **Key fields**: `block_timestamp` for timing, `transaction_signer` as the user identifier, `token_address` for the specific SPL token used for payment, and `amount` for fee value

### Component C: Daily active user aggregation
- **Purpose**: Combines SOL and SPL fee payers into daily unique user counts
- **Logic**: Unions the SOL and SPL fee data, then applies distinct aggregation to count unique users per day. Each user is classified with a `user_type` of "Payer" and grouped by timestamp truncated to daily granularity, chain identifier, and product identifier. The distinct operation ensures users who paid both SOL and SPL fees on the same day are counted only once
- **Key fields**: Daily `timestamp`, `user_type` set to "Payer", `chain` identifier, `product_id`, and `user_dau` containing the unique user identifier

### Component D: Rolling window creation
- **Purpose**: Establishes 30-day rolling windows for MAU calculation
- **Logic**: Creates a datespine covering all relevant dates, then generates joinday arrays spanning 30 days (current day plus previous 29 days) for each date. This creates the foundation for rolling window analysis by establishing which daily user data should be included in each day's MAU calculation
- **Key fields**: Primary `timestamp` for the MAU calculation date and `joinday` timestamps representing the 30-day window periods to include

### Component E: HyperLogLog aggregation within windows
- **Purpose**: Efficiently counts unique users across 30-day rolling windows
- **Logic**: Joins the rolling window structure with daily active user data, then applies HyperLogLog initialization and merging to count unique users within each 30-day period. HyperLogLog provides memory-efficient approximate counting for large user sets while maintaining accuracy suitable for business reporting
- **Key fields**: Window `timestamp`, dimensional identifiers (`chain_id`, `user_type`, `product_id`), and HLL sketch data for unique user counting

### Component F: Dimensional breakdown generation
- **Purpose**: Creates MAU calculations across different analytical dimensions
- **Logic**: Generates separate aggregations for project-level, chain-level, user-type-level, and product-level analysis. Each breakdown groups users by the relevant dimension while setting non-applicable dimensions to null. HyperLogLog merge operations combine user sketches within each dimensional grouping to produce final unique user counts
- **Key fields**: `timestamp`, `dimensions` indicating the breakdown type, relevant dimensional identifiers, and `user_mau` containing the final unique user count

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive dataset containing MAU values across all analytical dimensions for each date
- **Schema standardization**: The `finalize_metric_user_mau` macro applies consistent schema formatting, data type standardization, and fills missing dates with zero values using a "fill_zeros" strategy
- **Time boundaries**: Daily timestamps represent the end date of each 30-day rolling window, with incremental processing ensuring efficient updates while maintaining data consistency
- **Final calculation**: The final MAU value for each date and dimension combination represents the count of unique users who paid fees to heliopay during that date and the previous 29 days, providing a rolling 30-day view of active user engagement

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

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

Helio

Active users (monthly)

Active users (monthly)

Competitive landscape