Collators aggregate parachain transactions block candidates and producing state transition proofs for validators based on those blocks.

Frequency is a blockchain specialized for digital identity, data ownership and online presence powered by Polkadot Relay chain.

FRQCY holders own and govern the protocol.

website

github

twitter

discord

Blockchains (L2)

Frequency

# Frequency Active users (weekly) Methodology

## 1. Overview

The Weekly Active Users (WAU) metric for Frequency measures the number of unique users who had any activity on the Frequency blockchain within a 7-day rolling window. This metric is calculated using probabilistic HyperLogLog aggregation for efficient processing of large user datasets. Unlike traditional blockchain analytics that track transaction senders, this methodology identifies actual users through Frequency's unique proxy account system by analyzing stateful storage events and mapping internal user IDs to blockchain account addresses.

## 2. Data sources

The calculation relies on several key data sources from the Frequency blockchain:

- **Frequency blockchain events**: Raw event logs from the Frequency blockchain, specifically events from various pallets that indicate user activity
- **statefulStorage pallet events**: Events from the statefulStorage pallet that contain user ID information indicating actual user activity (rather than proxy account transactions)
- **MSA creation events**: Message Source Account creation events from the msa pallet with method `MsaCreated` that establish mappings between internal user IDs and blockchain account addresses
- **Blockchain metadata**: Event metadata including block timestamps, event indices, pallet information, and success indicators

## 3. Step-by-step calculation

### Component A: Account creation mapping
- **Purpose**: Establishes the relationship between Frequency's internal user IDs and blockchain account addresses
- **Logic**: Extracts account creation records from MSA (Message Source Account) creation events on the Frequency blockchain. Filters events where the event pallet is `msa` and event method is `MsaCreated`. Parses the event data JSON array to extract the `user_id` from the first element and `account_address` from the second element, creating a lookup table for user identification
- **Key fields**: `user_id` and `account_address` extracted from the event data array

### Component B: Raw event processing  
- **Purpose**: Cleanses and structures raw Frequency blockchain events for analysis
- **Logic**: Processes raw blockchain events from the Frequency network, truncating timestamps to daily granularity for consistent aggregation. Filters and structures event data including block information, event details, pallet information, and success indicators. Applies incremental processing logic to handle only new or updated events based on configured lookback periods
- **Key fields**: `timestamp` (truncated to day), `event_data`, `event_method`, `event_pallet`, `event_type`, and `extrinsic_id`

### Component C: User activity identification
- **Purpose**: Identifies actual user activity by combining events with account mappings
- **Logic**: Focuses specifically on events from the `statefulStorage` pallet, which indicate genuine user activity rather than proxy account transactions that Frequency uses internally. Extracts user IDs from the event data JSON array and classifies all users as "Transaction sender" type. Enriches user activity records with blockchain metadata including chain identifier, market sector, and business segment classifications. Joins with the account creation mapping to link internal user IDs to blockchain account addresses
- **Key fields**: `user_id` extracted from event data, `account_address` from the lookup, `chain`, `user_type`, and timestamp information

### Component D: Daily active users calculation
- **Purpose**: Aggregates unique daily active users from the processed activity data  
- **Logic**: Calculates daily active users by counting distinct account addresses per day, grouped by various dimensions including chain, user type, and product ID. Truncates timestamps to daily boundaries to ensure consistent daily aggregation. Creates a foundation dataset with distinct user counts that serves as input for the weekly rolling window calculation
- **Key fields**: `timestamp` (daily), `chain`, `user_type`, `product_id`, and `user_dau` (the distinct account address)

### Component E: HyperLogLog initialization
- **Purpose**: Prepares daily user data for efficient weekly aggregation using probabilistic counting
- **Logic**: Applies HyperLogLog probabilistic counting algorithm to the daily active user data, initializing HLL sketches with precision parameter 15 for each combination of timestamp, chain, user type, and product ID. Groups the daily user data and creates HLL sketches that can be efficiently merged across time windows without losing accuracy in unique user counting
- **Key fields**: `hll` sketch initialized from `user_dau` data, along with all dimensional grouping fields

### Component F: Date spine and rolling window generation
- **Purpose**: Creates a complete date range and generates 7-day rolling windows for WAU calculation
- **Logic**: Generates a continuous date spine covering the full analysis period to ensure no missing timestamps in the final results. For each date in the spine, creates a 7-day rolling window by generating timestamp arrays that include the current date plus the previous 6 days. Uses BigQuery's `GENERATE_TIMESTAMP_ARRAY` and `UNNEST` functions to create all necessary date combinations for the rolling window joins
- **Key fields**: `timestamp` (target date), `joinday` (each day within the 7-day window)

### Component G: Rolling window aggregation
- **Purpose**: Combines daily HLL sketches across 7-day windows to calculate weekly active users
- **Logic**: Joins the rolling window dates with the daily HLL data, matching each day in the 7-day window to its corresponding daily HLL sketch. Applies incremental processing filters to focus on recent data when running incremental updates. Creates the foundation for merging HLL sketches across the weekly window while maintaining all dimensional breakdowns
- **Key fields**: All HLL and dimensional fields joined across the 7-day window timeframe

### Component H: Dimensional breakdowns
- **Purpose**: Creates separate aggregations for different analytical dimensions
- **Logic**: Generates four distinct dimensional views of the weekly active users data: project-level aggregation (combining all dimensions), chain-level breakdown, user type breakdown, and product ID breakdown. Each breakdown merges the HLL sketches within the 7-day window according to its specific dimensional grouping, then extracts the final unique user count from the merged HLL sketch. Uses `HLL_COUNT.MERGE_PARTIAL` to combine sketches and `HLL_COUNT.EXTRACT` to get the final count
- **Key fields**: `user_wau` (extracted from merged HLL), `dimensions` (breakdown type), and relevant dimensional identifiers

### Final aggregation
- **Combining components**: The four dimensional breakdowns are combined using `UNION ALL` to create a unified dataset containing all analytical perspectives of the weekly active users metric
- **Currency conversion**: Not applicable for user count metrics - no currency conversion required
- **Time aggregation**: Daily granularity with 7-day rolling windows, where each day represents the count of unique users active in that day plus the previous 6 days
- **Final calculation**: The final WAU value is extracted from merged HyperLogLog sketches that probabilistically count unique account addresses across each 7-day window, with missing days filled with zero values and incremental processing applied to maintain data freshness

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

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

FrequencyFRQCY

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown