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 addresses (weekly) Methodology

## 1. Overview

Weekly active addresses for Mythos measures the distinct number of unique wallet addresses that participated in any activity across the Mythos ecosystem within a 7-day rolling window. This metric answers the question "How many unique users are engaging with Mythos products each week?" and serves as a key indicator of ecosystem health and user engagement. The calculation aggregates user activity across three main Mythos products: the Mythos blockchain itself, the NFT marketplace, and the DMarket digital asset trading platform.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Mythos blockchain event logs**: Structured event logs from the Mythos blockchain containing transaction and contract interaction data
- **ProxyExecuted events**: Events from the `mythProxy` pallet capturing transaction execution on the Mythos blockchain
- **OrderExecuted events**: Events from the `marketplace` pallet capturing NFT trading activity on the Mythos marketplace
- **Trade events**: Events from the `dmarket` pallet capturing digital asset trading activity on the DMarket platform
- **Event metadata**: Including block timestamps, extrinsic identifiers, and structured JSON event data arrays containing user addresses and transaction details

## 3. Step-by-step calculation

### Component A: Mythos blockchain user extraction
- **Purpose**: Identify active users from general blockchain transaction activity
- **Logic**: Extract transaction senders from Mythos blockchain events by filtering for `mythProxy` pallet events with method `ProxyExecuted`. Parse the first element of the JSON event data array to extract the user address. Each transaction sender is classified as a "Transaction sender" user type and associated with the "Mythos Substrate" product
- **Key fields**: `block_timestamp`, `user_address` (from `event_data[0]`), `user_type`, `product_id`

### Component B: NFT marketplace user extraction  
- **Purpose**: Identify active users from NFT marketplace trading activity
- **Logic**: Extract both buyers and sellers from NFT marketplace transactions by filtering for `marketplace` pallet events with method `OrderExecuted`. Parse the JSON event data array to extract seller address from element 2 and buyer address from element 3. Create separate records for buyers and sellers, each classified with their respective user types and associated with the "marketplace" product
- **Key fields**: `block_timestamp`, `buyer` (from `event_data[3]`), `seller` (from `event_data[2]`), `user_type`, `product_id`

### Component C: Digital marketplace user extraction
- **Purpose**: Identify active users from digital asset trading activity  
- **Logic**: Extract both buyers and sellers from digital asset trades by filtering for `dmarket` pallet events with method `Trade`. Parse the JSON event data array to extract buyer address from element 0 and seller address from element 1. Create separate records for buyers and sellers, each classified with their respective user types and associated with the "dmarket" product
- **Key fields**: `block_timestamp`, `buyer` (from `event_data[0]`), `seller` (from `event_data[1]`), `user_type`, `product_id`

### Component D: Daily active user aggregation
- **Purpose**: Create daily distinct active user counts across all Mythos products
- **Logic**: Combine user records from all three product sources and truncate timestamps to day granularity. Remove duplicate user addresses within each day, maintaining the chain identifier, user type, and product associations. Each unique combination of user address, day, and product context represents one daily active user record
- **Key fields**: `timestamp` (day-truncated), `chain`, `user_type`, `product_id`, `user_address`

### Component E: HyperLogLog sketch creation
- **Purpose**: Prepare efficient data structures for weekly deduplication
- **Logic**: Convert daily user data into HyperLogLog sketches grouped by timestamp, chain, user type, and product. HLL sketches enable efficient approximation of distinct counts when merging across multiple days without storing individual user addresses
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component F: 7-day rolling window construction
- **Purpose**: Create weekly active user windows for each day
- **Logic**: Generate a complete datespine covering all relevant dates, then for each day create a 7-day window by joining with the current day plus the 6 previous days. This creates overlapping windows where each day serves as the end date for a 7-day period. Join the window dates with the daily HLL sketches to gather all user activity within each 7-day period
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within window), `hll` sketches

### Component G: Weekly active user calculation
- **Purpose**: Calculate distinct weekly active users using HLL merge operations
- **Logic**: For each 7-day window, merge all HLL sketches within the window and extract the final distinct count. This provides the number of unique users who were active at least once during the 7-day period. Perform this calculation across multiple dimensional breakdowns including overall project level, chain level, user type level, and product level
- **Key fields**: `timestamp`, `dimensions` (aggregation level), `user_wau` (distinct weekly count)

### Final aggregation
- **Combining components**: Union weekly active user counts across all dimensional breakdowns (project, chain, user type, product level)
- **Dimensional filtering**: Filter results to include only chain-level and project-level dimensions, excluding user type and product-level breakdowns
- **Final calculation**: Rename the `user_wau` field to `active_addresses_weekly` to align with the final metric naming convention. Apply chain availability filtering to ensure data quality and completeness

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

Unique active addresses over a rolling 7-day window.

MythosMYTH

Archived

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown