website

twitter

github

Blockchains (L2)

Aventus

# Aventus Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that executed at least one transaction on the Aventus network within a rolling 30-day period. This metric provides insight into user engagement and network adoption for both the native Aventus blockchain and its EVM compatibility layer. The calculation uses HyperLogLog probabilistic data structures for memory-efficient counting of distinct addresses across large datasets, then aggregates daily active users into monthly cohorts using rolling 30-day windows.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **Native Aventus extrinsics**: Transaction records from the native Aventus blockchain containing sender address information and block timestamps
- **Aventus EVM event logs**: Parsed event data from the Aventus EVM compatibility layer, specifically `evm` pallet events with `Executed` methods that contain transaction sender addresses
- **Block timestamp data**: Temporal information for all transactions used to organize data into daily and monthly periods

## 3. Step-by-step calculation

### Component A: User address extraction

- **Purpose**: Identifies unique user addresses from both native Aventus transactions and EVM compatibility layer
- **Logic**: Extracts transaction sender addresses from two distinct data sources. For native Aventus transactions, the sender address is directly available in the `id` field. For EVM compatibility layer transactions, addresses are parsed from JSON event data within `event_data[0]` field for events where the pallet is `evm` and method is `Executed`. Each address is labeled with its respective chain identifier (`aventus` for native, `aventusevm` for EVM) and categorized as a transaction sender user type
- **Key fields**: `block_timestamp` for temporal analysis, `id` for native addresses, `event_data[0]` for EVM addresses, chain identifiers for source tracking

### Component B: Daily active user calculation

- **Purpose**: Aggregates unique addresses into daily cohorts for efficient monthly window processing
- **Logic**: Groups all user addresses by day using timestamp truncation to daily granularity. Creates HyperLogLog sketches for each daily cohort to enable memory-efficient distinct counting. Each daily record contains the timestamp, chain information, user type classification, and the HLL sketch representing all unique addresses active on that day
- **Key fields**: `timestamp` truncated to day, `chain` identifier, `user_type` classification, `user_dau` containing the unique address

### Component C: Monthly rolling window construction

- **Purpose**: Creates 30-day rolling windows for monthly active user calculation
- **Logic**: Uses a datespine approach that generates all possible day combinations within rolling 30-day periods. For each target day, creates records for all 30 preceding days (including the target day). Joins this datespine with the daily HLL sketches to create a comprehensive window dataset that captures all user activity within each 30-day period
- **Key fields**: `timestamp` for the target date, `joinday` for each day within the 30-day window, HLL sketches from matching daily records

### Component D: HyperLogLog aggregation

- **Purpose**: Calculates distinct user counts across 30-day windows using probabilistic data structures
- **Logic**: Merges HLL sketches from all days within each 30-day window using HLL merge operations. Extracts the final distinct count from the merged sketch, providing an estimate of unique addresses active within the rolling 30-day period. This approach enables efficient processing of large address sets without maintaining exact lists
- **Key fields**: Merged HLL sketches, extracted `user_mau` counts representing distinct addresses

### Component E: Dimensional breakdowns

- **Purpose**: Provides multiple aggregation levels for analysis flexibility
- **Logic**: Creates four distinct dimensional views of the monthly active user data. Project-level aggregation combines all chains and user types. Chain-level breakdown separates native Aventus from EVM compatibility layer. User-type breakdown focuses on transaction sender classification. Product-level breakdown enables future product-specific analysis. Each dimension maintains the same temporal structure while providing different analytical perspectives
- **Key fields**: `dimensions` indicating breakdown type, `chain_id` for chain-specific analysis, `user_type` for behavioral classification, `product_id` for product-specific metrics

### Final aggregation

- **Combining components**: Monthly active user data is filtered to include only chain-level and project-level dimensions, which are most relevant for active address analysis
- **Address labeling**: The `user_mau` field is renamed to `active_addresses_monthly` to reflect that blockchain users are identified by their addresses
- **Time aggregation**: Data maintains monthly granularity with each record representing a 30-day rolling window ending on the specified date
- **Final calculation**: The metric value represents the estimated count of unique addresses that executed at least one transaction within the rolling 30-day period, calculated using HyperLogLog probabilistic counting for both native Aventus and EVM compatibility layer transactions combined

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

Unique addresses active over a rolling 30-day window.

AventusAVT

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown