twitter

discord

website

github

Blockchains (L2)

peaq

# peaq Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have initiated at least one transaction on the Peaq network within a rolling 30-day window. This metric answers the question "How many distinct users are actively transacting on Peaq each month?" For blockchain protocols like Peaq, active addresses are equivalent to active users since each transaction requires a unique wallet address. The calculation uses a rolling 30-day window approach with probabilistic counting methods to efficiently handle large datasets while maintaining accuracy.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **Native Peaq extrinsics**: Raw substrate blockchain transaction records containing user addresses in the `id` field, representing native Peaq network transactions
- **Peaq EVM events**: Ethereum Virtual Machine compatible event logs from the `ethereum` pallet with `Executed` method, where user addresses are extracted from JSON event data arrays
- **Peaq blockchain event logs**: Transaction event data with pallet and method classifications to identify EVM-compatible transactions

All data sources capture transaction-level activity with block timestamps and user address information from the Peaq Layer 2 blockchain network.

## 3. Step-by-step calculation

### Component A: User transaction extraction
- **Purpose**: Extract all user addresses that have initiated transactions on the Peaq network
- **Logic**: Combine two types of Peaq transactions: native substrate extrinsics where user addresses are stored directly in the `id` field, and EVM-compatible transactions where user addresses are parsed from JSON event data. Both transaction types are classified as "Transaction sender" user types and tagged with Peaq's chain identifiers (`peaq` for native, `Peaq EVM` for EVM transactions). All users are categorized under the "blockchains_l2" market sector and "blockchain" business segment
- **Key fields**: `block_timestamp` for timing, `id` for native user addresses, `event_data[0]` for EVM user addresses, `user_type` as "Transaction sender"

### Component B: Daily active user calculation  
- **Purpose**: Calculate the number of distinct users active each day
- **Logic**: Group all transaction records by daily timestamp boundaries using timestamp truncation to day level. Count distinct user addresses within each day across both native Peaq and EVM transaction types. Preserve dimensional information including chain identifiers, user types, and product classifications for downstream analysis
- **Key fields**: `timestamp` truncated to day, `user_address` for distinct counting, `chain` for network identification

### Component C: Rolling window preparation
- **Purpose**: Create a complete time series framework for calculating 30-day rolling windows
- **Logic**: Generate a datespine covering all days from the earliest transaction date to the current date minus one day. For each day in the datespine, create join relationships with the previous 30 days (including the current day) to establish rolling window boundaries. Convert daily active user counts to HyperLogLog sketches for efficient probabilistic distinct counting across window periods
- **Key fields**: `timestamp` for window end dates, `joinday` for window member dates, `hll` sketches for probabilistic counting

### Component D: Monthly active user aggregation
- **Purpose**: Calculate distinct users across rolling 30-day windows using probabilistic counting
- **Logic**: For each day, aggregate HyperLogLog sketches from all days within the 30-day window ending on that day. Merge partial HLL sketches and extract final distinct user counts. Generate separate breakdowns by dimension: overall project level (`project_dbt_tag`), individual chain level (`chain`), user type level (`user_type`), and product level (`product_id`). Each breakdown provides a different analytical perspective on user activity
- **Key fields**: `user_mau` containing distinct user counts, `dimensions` indicating breakdown level, `chain_id` and `user_type` for dimensional analysis

### Final aggregation
- **Combining components**: Union all dimensional breakdowns of MAU data into a single dataset, then filter to include only chain-level and project-level dimensions for the active addresses metric
- **Currency conversion**: Not applicable for this count-based metric
- **Time aggregation**: Use daily timestamp boundaries with rolling 30-day windows, where each day's value represents the distinct users active in the 30 days ending on that date
- **Final calculation**: Rename the `user_mau` field to `active_addresses_monthly` since for blockchain protocols, monthly active users are equivalent to monthly active addresses. Apply zero-filling logic for any missing time periods to ensure complete time series coverage

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

Unique addresses active over a rolling 30-day window.

peaqPEAQ

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown