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 (monthly) Methodology

## 1. Overview

Monthly active addresses measures the count of unique wallet addresses that performed any activity on the Mythos ecosystem within a 30-day rolling window. This metric answers the question "How many distinct users are actively engaging with Mythos blockchain and its marketplace products each month?" The calculation uses HyperLogLog probabilistic counting to efficiently handle large-scale distinct address counting across multiple Mythos products and services.

## 2. Data sources

- **Mythos blockchain events**: Raw event logs from the Mythos blockchain containing pallet and method identifiers with JSON-encoded event data
  - `mythProxy.ProxyExecuted` events containing transaction sender addresses
  - `marketplace.OrderExecuted` events containing NFT buyer and seller addresses  
  - `dmarket.Trade` events containing marketplace buyer and seller addresses
- **Event metadata**: Block timestamps, extrinsic IDs, and event classification data from Mythos blockchain
- **Internal classifications**: Product categorizations (Mythos Substrate, marketplace, dmarket) and user type classifications (transaction sender, NFT buyer, NFT seller)

## 3. Step-by-step calculation

### Component A: Transaction senders identification
- **Purpose**: Identify users who send transactions on the Mythos blockchain
- **Logic**: Extract user addresses from `mythProxy.ProxyExecuted` events by parsing the first element of the `event_data` JSON array. These represent general blockchain transaction senders and are classified as "Transaction sender" user type with product ID "Mythos Substrate"
- **Key fields**: `user_address` from `event_data[0]`, `block_timestamp`, `product_id` as "Mythos Substrate"

### Component B: Marketplace participants identification  
- **Purpose**: Identify users who buy or sell NFTs on the Mythos marketplace
- **Logic**: Extract buyer and seller addresses from `marketplace.OrderExecuted` events by parsing `event_data[3]` for buyers and `event_data[2]` for sellers. Create separate records for buyers ("NFT buyer" user type) and sellers ("NFT seller" user type), both with product ID "marketplace"
- **Key fields**: `buyer` from `event_data[3]`, `seller` from `event_data[2]`, `block_timestamp`, `product_id` as "marketplace"

### Component C: Dmarket participants identification
- **Purpose**: Identify users who trade on the Mythos dmarket platform
- **Logic**: Extract buyer and seller addresses from `dmarket.Trade` events by parsing `event_data[0]` for buyers and `event_data[1]` for sellers. Create separate records for buyers ("NFT buyer" user type) and sellers ("NFT seller" user type), both with product ID "dmarket"  
- **Key fields**: `buyer` from `event_data[0]`, `seller` from `event_data[1]`, `block_timestamp`, `product_id` as "dmarket"

### Component D: Daily active users aggregation
- **Purpose**: Combine all user activity into daily distinct active users
- **Logic**: Union all three user sources and truncate timestamps to day granularity. Remove duplicates to ensure each user address appears only once per day per product, creating a foundation dataset of daily active users with their associated product and user type metadata
- **Key fields**: `timestamp` (day-truncated), `user_address`, `chain`, `user_type`, `product_id`

### Component E: Rolling window construction
- **Purpose**: Create 30-day rolling windows for monthly active user calculation
- **Logic**: Generate a complete datespine of daily timestamps from the earliest data to present. For each day, create joins with the previous 29 days to establish 30-day rolling windows. This ensures consistent monthly calculations even when some days have no activity
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 30-day window)

### Component F: HyperLogLog aggregation
- **Purpose**: Efficiently count distinct users across 30-day windows at scale
- **Logic**: For each day in the rolling window, initialize HyperLogLog sketches for user addresses and merge them across the 30-day period. Group by different dimensions including chain level, project level, user type, and product ID to create multiple analytical breakdowns
- **Key fields**: `hll` (HyperLogLog sketches), `dimensions` (breakdown level), `user_mau` (extracted distinct count)

### Final aggregation
- **Combining components**: Union MAU calculations across all dimension levels (chain, project_dbt_tag, user_type, product_id) to provide multiple analytical perspectives
- **Currency conversion**: Not applicable - this metric counts addresses, not financial values
- **Time aggregation**: Uses 30-day rolling windows calculated daily, with each day representing the distinct user count over the preceding 30 days
- **Final calculation**: Filter the multi-dimensional MAU results to include only 'chain' and 'project_dbt_tag' dimensions, then rename the `user_mau` field to `active_addresses_monthly` to reflect the final metric. Apply chain availability filters and standardization through the finalize metric process.

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

Unique addresses active over a rolling 30-day window.

MythosMYTH

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown