website

twitter

Infrastructure

Helio

# Helio Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Heliopay measures the number of unique users who made fee payments through the Heliopay protocol within a 7-day rolling window. The metric identifies active users based on their transaction signatures when making fee payments (either native SOL or SPL token payments) to Heliopay's designated fee collection address. This metric uses HyperLogLog (HLL) data structures for efficient distinct user counting across time periods and provides breakdowns by project level, blockchain, user type, and product dimensions.

## 2. Data sources

- **Solana native transfers**: Native SOL transfer events on the Solana blockchain, capturing all SOL movements between addresses
- **Solana SPL token transfers**: SPL token transfer events on Solana, recording all movements of fungible tokens built on the Solana blockchain
- **Solana transaction records**: Transaction metadata including signer information, timestamps, and transaction identifiers from Solana blockchain
- **Fee collection configuration**: Hardcoded fee collection address (`FudPMePeNqmnjMX19zEKDfGXpbp6HAdW6ZGprB5gYRTZ`) used to identify Heliopay fee payments

## 3. Step-by-step calculation

### Component A: SOL fee transaction identification
- **Purpose**: Identifies users making fee payments in native SOL to Heliopay
- **Logic**: Filters Solana native transfer events where the recipient address matches Heliopay's fee collection address. Excludes transactions where the fee collection address is also the transaction signer to avoid counting internal protocol transactions. Extracts the `transaction_signer` as the user identifier, representing the address that initiated and signed the fee payment transaction. Records the `amount` of SOL transferred and timestamps each transaction.
- **Key fields**: `block_timestamp` for timing, `transaction_signer` as user identifier, `amount` for SOL quantity, `transaction_id` for deduplication

### Component B: SPL token fee transaction identification  
- **Purpose**: Identifies users making fee payments using SPL tokens to Heliopay
- **Logic**: Filters SPL token transfer events where the recipient owner address matches Heliopay's fee collection address. Similar to SOL fees, excludes internal transactions where the fee account signs its own transactions. Captures the `transaction_signer` as the active user and includes `token_address` to identify which SPL token was used for the fee payment. Records transfer amounts as big numeric values to handle large token quantities with precision.
- **Key fields**: `block_timestamp` for timing, `transaction_signer` as user identifier, `token_address` for token type, `amount` for token quantity

### Component C: Daily active user aggregation
- **Purpose**: Combines SOL and SPL fee payers into daily unique user counts
- **Logic**: Unions the transaction signers from both SOL and SPL fee payments, truncating timestamps to day-level granularity. Applies distinct operations to ensure each user is counted only once per day, regardless of how many fee transactions they made. Classifies all users with the `user_type` of 'Payer' since they are identified through fee payment activity. Groups results by date, chain, user type, and product ID dimensions.
- **Key fields**: `timestamp` truncated to day, `user_dau` containing unique user addresses, `user_type` set to 'Payer'

### Component D: HyperLogLog sketch creation
- **Purpose**: Converts daily user lists into HLL data structures for efficient distinct counting
- **Logic**: Transforms daily active user data into HyperLogLog sketches using `hll_count.init()` with 15-bit precision. This probabilistic data structure enables efficient merging of user sets across multiple days without storing individual user addresses. Groups by timestamp, chain, user type, and product dimensions while creating HLL sketches from the daily user lists.
- **Key fields**: `hll` containing the probabilistic sketch of unique users for each day and dimension combination

### Component E: Rolling 7-day window construction
- **Purpose**: Creates overlapping 7-day windows for each date to calculate weekly active users
- **Logic**: Generates a complete date spine covering the analysis period, then creates join relationships between each target date and the 7 days ending on that date (including the target date itself). Uses `generate_timestamp_array()` to create daily intervals spanning from 6 days before each target date through the target date. This ensures every date has a complete 7-day lookback window for user activity calculation.
- **Key fields**: `timestamp` as target date, `joinday` representing each day in the 7-day window

### Component F: HLL sketch aggregation across windows
- **Purpose**: Merges daily HLL sketches within each 7-day window to count unique weekly users
- **Logic**: Joins the 7-day window structure with daily HLL sketches, matching each window day with its corresponding daily user data. Uses `hll_count.merge_partial()` to combine multiple daily HLL sketches within each 7-day window, then applies `hll_count.extract()` to convert the merged sketch back to an approximate distinct count. This produces the weekly active user count for each date and dimension combination.
- **Key fields**: `user_wau` containing the estimated count of unique users active within each 7-day window

### Component G: Dimensional breakdown generation
- **Purpose**: Creates separate WAU calculations for different analytical dimensions
- **Logic**: Generates four distinct breakdowns of the weekly active user data: project-level aggregation (combining all dimensions), chain-level breakdown, user type breakdown, and product ID breakdown. Each breakdown aggregates HLL sketches differently, setting irrelevant dimension fields to null while preserving the relevant grouping dimension. Uses union operations to combine all dimensional views into a single result set.
- **Key fields**: `dimensions` indicating the breakdown type, dimension-specific fields (`chain_id`, `user_type`, `product_id`) with nulls for irrelevant dimensions

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project-level, chain, user type, product ID) into a single comprehensive dataset using `union all` operations
- **Time aggregation**: Maintains daily granularity with each row representing WAU for a specific date, with the 7-day window calculation built into the HLL sketch merging process
- **Final calculation**: Applies the `finalize_metric_user_wau` macro to standardize schema, fill missing dates with zero values, and ensure consistent output format across all Heliopay metrics

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

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

Helio

Active users (weekly)

Active users (weekly)

Competitive landscape