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

Mythos is a specialized gaming blockchain powered by Polkadot Relay chain.

MYTH holders own and govern the protocol.

website

github

twitter

etherscan

Blockchains (L2)

Mythos

# Mythos Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Mythos measures the count of unique users who have interacted with any Mythos ecosystem product within a rolling 30-day window. This metric captures user engagement across three main Mythos products: the Mythos Substrate blockchain infrastructure, the Mythos Marketplace for NFT trading, and DMarket for gaming asset trading. The calculation uses HyperLogLog data structures for efficient probabilistic counting of distinct users across multiple dimensions including chain, user type, and product breakdowns.

## 2. Data sources

- **Mythos blockchain event logs**: Core event data from the Mythos blockchain's native event system, containing structured events organized by pallets (blockchain modules) and methods (specific functions)
- **ProxyExecuted events**: Events from the `mythProxy` pallet capturing general blockchain transaction activity and user interactions with the Mythos Substrate infrastructure
- **OrderExecuted events**: Events from the `marketplace` pallet capturing NFT purchase and sale transactions on the Mythos Marketplace
- **Trade events**: Events from the `dmarket` pallet capturing gaming asset trades and transactions on the DMarket platform
- **Event metadata**: Blockchain timestamps, transaction identifiers (`extrinsic_id`), and JSON-structured event data containing user addresses, prices, fees, and item identifiers

## 3. Step-by-step calculation

### Component A: Mythos Substrate user extraction
- **Purpose**: Identifies users interacting with the core Mythos Substrate blockchain infrastructure
- **Logic**: Extracts `ProxyExecuted` events from the `mythProxy` pallet, parses JSON event data to retrieve the transaction sender address from the first data element, classifies users as "Transaction sender" type, and associates them with the "Mythos Substrate" product and "mythos" chain. Users represent addresses actively sending transactions through the proxy system.
- **Key fields**: `block_timestamp` for timing, `user_address` extracted from JSON event data, `user_type` as "Transaction sender", `product_id` as "Mythos Substrate"

### Component B: Marketplace user extraction  
- **Purpose**: Captures users engaged in NFT trading activities on the Mythos Marketplace
- **Logic**: Processes `OrderExecuted` events from the `marketplace` pallet, extracts buyer and seller addresses from JSON event data positions 3 and 2 respectively, creates separate records for buyers and sellers, classifies buyers as "NFT buyer" and sellers as "NFT seller" user types, and associates both with the "marketplace" product. Each marketplace transaction generates two user activity records.
- **Key fields**: `block_timestamp`, `buyer` and `seller` addresses from JSON parsing, `user_type` differentiated as "NFT buyer" or "NFT seller", `product_id` as "marketplace"

### Component C: DMarket user extraction
- **Purpose**: Identifies users trading gaming assets and items on the DMarket platform
- **Logic**: Analyzes `Trade` events from the `dmarket` pallet, extracts buyer and seller addresses from JSON event data positions 0 and 1, creates dual records for each trade transaction, assigns "NFT buyer" and "NFT seller" user types respectively, and links both to the "dmarket" product. Similar to marketplace, each trade creates two user activity entries.
- **Key fields**: `block_timestamp`, `buyer` and `seller` addresses from JSON positions, `user_type` as "NFT buyer" or "NFT seller", `product_id` as "dmarket"

### Component D: Daily active user aggregation
- **Purpose**: Consolidates all user activities into daily unique user counts across all Mythos products
- **Logic**: Unions user records from all three products (Mythos Substrate, Marketplace, DMarket), truncates timestamps to daily granularity, removes duplicate user-day combinations within the same chain-user_type-product_id grouping, and creates distinct daily user records. This ensures each unique user is counted only once per day per product-user_type combination.
- **Key fields**: `timestamp` truncated to day, `chain` as "mythos", `user_type`, `product_id`, `user_address` as distinct daily users

### Component E: HyperLogLog sketch creation
- **Purpose**: Creates probabilistic data structures for efficient distinct user counting across time windows
- **Logic**: Initializes HyperLogLog sketches for each day's unique users, groups by timestamp, chain, user type, and product dimensions, uses HLL precision of 15 bits for accuracy, and prepares sketches for merging across rolling time windows. HLL enables memory-efficient approximate distinct counting without storing actual user lists.
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` sketch containing user data

### Component F: Rolling window datespine generation
- **Purpose**: Creates a complete date range framework for consistent 30-day window calculations
- **Logic**: Generates timestamp arrays from the earliest data date to yesterday, creates daily intervals to ensure no missing dates, performs cross-join with 30-day lookback periods (current day minus 29 days to current day), and produces joinable timestamp pairs for window aggregation. This ensures consistent MAU calculation even for days with no activity.
- **Key fields**: `timestamp` as the target date, `joinday` as each day within the 30-day window

### Component G: MAU window aggregation
- **Purpose**: Merges HLL sketches across 30-day rolling windows to calculate monthly active users
- **Logic**: Joins the datespine with daily HLL data on matching timestamps, creates 30-day windows for each target date, merges HLL sketches across the window using `hll_count.merge_partial()`, groups by target timestamp and dimensional attributes, and extracts final distinct user counts using `hll_count.extract()`. This produces MAU values for each dimension combination.
- **Key fields**: `timestamp` as target date, dimensional groupings (`chain_id`, `user_type`, `product_id`), merged `hll` sketches, extracted `user_mau` counts

### Component H: Dimensional breakdowns
- **Purpose**: Creates separate MAU calculations for different analytical perspectives
- **Logic**: Generates four distinct dimensional views: project-level aggregation (all dimensions collapsed), chain-level breakdown (by chain), user-type breakdown (by user classification), and product-level breakdown (by individual products). Each breakdown nullifies non-relevant dimensions and aggregates HLL sketches accordingly, then unions all breakdowns into a comprehensive result set.
- **Key fields**: `dimensions` indicating breakdown type, relevant dimensional fields populated or nulled, `user_mau` as the final count

### Final aggregation
- **Combining components**: All dimensional breakdowns are unioned together to create a comprehensive dataset with multiple analytical perspectives, each record tagged with its dimensional focus
- **Time aggregation**: Uses 30-day rolling windows with daily precision, ensuring consistent month-over-month comparability regardless of calendar month boundaries
- **Final calculation**: Extracts probabilistic distinct user counts from merged HyperLogLog sketches, providing approximate but highly accurate MAU figures with memory efficiency for large-scale user bases
- **Output standardization**: Applies finalization macros to ensure consistent schema, fills missing periods with zeros where appropriate, and maintains incremental processing boundaries for efficient data updates

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

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

MythosMYTH

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown