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

NeuroWeb is a decentralized Artificial Intelligence blockchain powered by Polkadot Relay chain.

NEURO holders own and govern the protocol.

website

github

twitter

etherscan

Blockchains (L2)

NeuroWeb

# NeuroWeb Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have been active on the Neuroweb blockchain within any 30-day rolling window, calculated on a daily basis. This metric provides insight into user engagement and network adoption by tracking distinct users over monthly periods. The calculation treats users as addresses since each user corresponds to a unique blockchain address, making active users equivalent to active addresses for blockchain protocols.

## 2. Data sources

The calculation relies on two primary Neuroweb blockchain data sources:

- **Neuroweb extrinsics**: Transaction records from the Neuroweb blockchain containing transaction metadata, block timestamps, and sender identifiers (`id` field)
- **Neuroweb events**: Blockchain event logs focusing specifically on Ethereum execution events (`ethereum` pallet, `Executed` method) where user addresses are extracted from JSON event data
- **Block timestamps**: Timing information for all transactions and events to enable daily and monthly aggregations

## 3. Step-by-step calculation

### Component A: User identification and daily aggregation
- **Purpose**: Extract and standardize user addresses from Neuroweb blockchain activity
- **Logic**: The system processes two types of Neuroweb activity. For standard Neuroweb transactions, it extracts the sender `id` directly from extrinsics data and labels the chain as 'neuroweb'. For Ethereum execution events on Neuroweb EVM, it extracts user addresses from the first element of JSON `event_data` arrays and labels the chain as 'NeuroWeb EVM'. All users are classified as 'Transaction sender' type and categorized under 'blockchains_l2' market sector and 'blockchain' business segment. The system truncates `block_timestamp` to daily boundaries and creates distinct daily records for each user address
- **Key fields**: `block_timestamp` for timing, `id` for Neuroweb transaction senders, `event_data[0]` for EVM user addresses, `chain` for network identification

### Component B: HyperLogLog sketch creation
- **Purpose**: Create efficient data structures for counting distinct users across time periods
- **Logic**: For each day, the system groups user addresses by timestamp, chain, user type, and product, then creates HyperLogLog sketches using a precision parameter of 15 bits. This probabilistic data structure enables efficient distinct counting and merging across time windows without storing individual addresses
- **Key fields**: `timestamp` at daily grain, `chain_id` for network, `user_type` and `product_id` for segmentation, `hll` sketch containing compressed user data

### Component C: Rolling window construction
- **Purpose**: Build 30-day rolling windows to calculate monthly active users
- **Logic**: The system creates a complete datespine covering all days from the earliest data point to yesterday, ensuring no gaps in the time series. For each day in the datespine, it generates a 30-day lookback window including that day and the previous 29 days. It then joins this window structure with the daily HLL sketches to create rolling window data, ensuring every day has access to the full 30-day historical context needed for MAU calculations
- **Key fields**: `timestamp` for the current day, `joinday` for days within the 30-day window, `hll` sketches from matching days

### Component D: Monthly active user calculation
- **Purpose**: Calculate distinct users across 30-day rolling windows using different dimensional breakdowns
- **Logic**: The system merges HLL sketches across each 30-day window and extracts the final distinct count. It creates four dimensional views: project-level aggregation (combining all chains and user types), chain-level aggregation (separate counts per chain), user type aggregation (separate counts per user type), and product-level aggregation (separate counts per product). Each aggregation uses HLL merge operations to combine sketches from different days within the window, then extracts the final distinct user count
- **Key fields**: `timestamp` for the calculation date, `dimensions` indicating the aggregation level, `user_mau` containing the distinct user count

### Final aggregation
- **Combining components**: The system unions all dimensional MAU calculations into a single dataset with different dimension values ('chain', 'project_dbt_tag', 'user_type', 'product_id')
- **Address conversion**: Monthly active users are directly converted to monthly active addresses since users and addresses represent the same entities on blockchain networks - each active user corresponds to one unique address
- **Time boundaries**: The calculation uses 30-day rolling windows calculated daily, where each day includes that day plus the previous 29 days of activity
- **Final calculation**: The metric selects MAU values specifically for 'chain' and 'project_dbt_tag' dimensions and renames `user_mau` to `active_addresses_monthly`. Chain availability filters are applied to ensure data quality, and the finalize macro applies standard formatting and fills missing periods with zeros

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

Unique addresses active over a rolling 30-day window.

NeuroWebNEURO

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown