Validators process transactions and receive fees from users (supply-side fees).

Kusama is a security & interoperability platform for blockchains and applications. Kusama was founded by Gavin Wood and launched in 2019.

KSM holders own and govern the protocol. They currently take a cut of the total transaction fees paid by users (revenue).

github

twitter

discord

etherscan

website

Blockchains (L1)

Kusama

# Kusama Active users (monthly) Methodology

## 1. Overview

The Kusama Monthly Active Users (MAU) metric measures the number of unique users who have performed at least one transaction (extrinsic) on the Kusama blockchain within a rolling 30-day window. This metric provides insight into user engagement and platform adoption for the Kusama network. The calculation uses HyperLogLog probabilistic data structures to efficiently count unique users across large datasets while maintaining accuracy. The metric is calculated daily and provides multiple dimensional breakdowns including project-level, chain-level, user type, and product-level views.

## 2. Data sources

- **Kusama extrinsic records**: Raw blockchain data containing all user transactions and operations performed on the Kusama network, including block timestamps, extrinsic identifiers, and user addresses
- **Kusama transaction metadata**: Block and timestamp information associated with each extrinsic to enable temporal analysis

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identifies unique users who performed transactions on each day
- **Logic**: Extracts user activity from Kusama extrinsic records by filtering for transaction senders. Each extrinsic record contains a user address (`id` field) and block timestamp. The data is truncated to daily boundaries to group activity by calendar day. Each unique user address that appears in extrinsic records on a given day is counted as a daily active user (DAU)
- **Key fields**: `block_timestamp` (converted to daily boundaries), `user_address` (the unique identifier for each user), `chain` (set to 'kusama'), `user_type` (classified as 'Transaction sender')

### Component B: HyperLogLog conversion
- **Purpose**: Converts daily active user data into HyperLogLog data structures for efficient unique counting
- **Logic**: Takes the daily active user data and initializes HyperLogLog (HLL) structures with precision parameter 15. Each day's unique users are converted into a single HLL structure that probabilistically represents the set of unique user addresses. This allows for efficient storage and later aggregation across time periods without losing accuracy in unique counts
- **Key fields**: `hll` (HyperLogLog structure containing compressed user data), `timestamp` (daily boundary), `timestamp_grain` (set to 'day')

### Component C: Rolling window generation
- **Purpose**: Creates a 30-day rolling window framework to ensure no missing dates in MAU calculations
- **Logic**: Generates a complete datespine covering all days in the analysis period, then creates join combinations where each day is associated with itself plus the previous 29 days (total 30-day window). Uses BigQuery's `generate_timestamp_array` function to create arrays of consecutive dates. For each target date, generates all dates from 29 days prior through the target date, creating the foundation for rolling MAU calculation
- **Key fields**: `timestamp` (target date for MAU calculation), `joinday` (each individual day within the 30-day window)

### Component D: Window-based HLL aggregation
- **Purpose**: Combines HyperLogLog structures across the 30-day rolling window
- **Logic**: Joins the rolling window framework with the daily HLL data to collect all HLL structures that fall within each 30-day period. For each target date, gathers the HLL structures from that date and the previous 29 days. This creates the raw material for MAU calculation while preserving dimensional breakdowns like chain, user type, and product
- **Key fields**: `timestamp` (target MAU date), `hll` (daily HLL structure), dimensional fields (`chain_id`, `user_type`, `product_id`)

### Component E: Dimensional MAU breakdown
- **Purpose**: Calculates MAU across different dimensional cuts of the data
- **Logic**: Creates four separate dimensional views by merging HLL structures within each 30-day window:
  - Project-level: Merges all HLL structures regardless of other dimensions to get overall Kusama MAU
  - Chain-level: Groups by chain (though Kusama is single-chain, maintains consistency with multi-chain projects)
  - User type-level: Breaks down by user classification (currently only 'Transaction sender')
  - Product-level: Allows for product-specific MAU calculation (currently null for Kusama)
Each breakdown uses `hll_count.merge_partial()` to combine HLL structures and `hll_count.extract()` to get the final unique count
- **Key fields**: `user_mau` (final unique user count), `dimensions` (breakdown type), relevant dimensional fields

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL to create a unified dataset with multiple views of the same underlying MAU data
- **Currency conversion**: No currency conversion required as this is a user count metric
- **Time aggregation**: Maintains daily granularity with each day representing a 30-day rolling window ending on that date
- **Final calculation**: The `finalize_metric_user_mau` macro applies schema standardization, fills any missing dates with zero values, and ensures consistent output format across all Token Terminal metrics. The final MAU value for each day represents the count of unique users who were active within the 30-day period ending on that date

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

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

KusamaKSM

Active users (monthly)

Active users (monthly)

Competitive landscape