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

Moonbeam is an Ethereum-compatible smart contracts platform built as a Polkadot parachain.

GLMR holders own and govern the protocol. Moonbeam’s investors include IOSG Ventures, Coinbase Ventures, Fenbushi Capital, CoinFund, etc

website

github

twitter

discord

etherscan

Blockchains (L2)

Moonbeam

# Moonbeam Active addresses (monthly) Methodology

> **Archived 2026-07-31.** Token Terminal stopped tracking Moonbeam following the announced migration of GLMR to Base and the launch of the new Moonbeam Protocol. The methodology below describes how this metric was calculated while the chain was tracked; historical values remain accurate and accessible.

## 1. Overview

Monthly active addresses measures the number of unique addresses that have initiated at least one transaction on the Moonbeam network within a rolling 30-day period. This metric captures both native Substrate transactions and EVM-compatible transactions on Moonbeam's hybrid blockchain architecture. The calculation uses HyperLogLog sketches for efficient counting of unique addresses and provides breakdowns by chain, project, user type, and product dimensions.

## 2. Data sources

The calculation relies on two primary raw blockchain data sources from Moonbeam:

- **Native Substrate extrinsics**: Blockchain transaction records containing sender addresses and timestamps for native Substrate operations on Moonbeam
- **EVM transaction events**: Parsed events from Moonbeam's `ethereum` pallet, specifically `Executed` method events that capture EVM-compatible transaction activity with sender addresses extracted from event data
- **Blockchain metadata**: Chain identifiers, market sector classifications, and business segment categorizations for proper data labeling

## 3. Step-by-step calculation

### Component A: User identification and daily aggregation
- **Purpose**: Extract unique active addresses daily from all Moonbeam transaction activity
- **Logic**: The system processes both native Substrate extrinsics and EVM transaction events. For Substrate extrinsics, transaction sender addresses are extracted directly from the `id` field. For EVM transactions, sender addresses are parsed from `event_data[0]` within `ethereum` pallet `Executed` events. Each address is labeled as a "Transaction sender" user type and associated with appropriate chain identifiers (moonbeam for native, Moonbeam EVM for EVM). Block timestamps are truncated to day boundaries to create daily snapshots of unique active addresses.
- **Key fields**: `block_timestamp` for temporal grouping, `user_address` for unique address identification, `chain` for blockchain variant classification, `user_type` for activity categorization

### Component B: HyperLogLog sketch creation
- **Purpose**: Convert daily unique addresses into efficient counting structures for downstream aggregation
- **Logic**: Daily unique addresses are processed into HyperLogLog sketches using a precision parameter of 15 bits. This probabilistic data structure enables efficient counting and merging of unique values across large datasets. The sketches are grouped by timestamp, chain, user type, and product dimensions to maintain granular breakdowns while enabling efficient aggregation.
- **Key fields**: `timestamp` for temporal grouping, `chain_id` for blockchain identification, `hll` for the HyperLogLog sketch containing unique address counts

### Component C: Rolling window construction
- **Purpose**: Create a 30-day rolling window for monthly active address calculation
- **Logic**: A datespine generates continuous daily timestamps from the earliest data point to the current date minus one day. For each day, the system creates join keys for the preceding 30 days (including the current day). This ensures that every day has a complete 30-day lookback window, even when no transaction activity occurred on specific days. The datespine approach prevents gaps in the time series that could skew monthly calculations.
- **Key fields**: `timestamp` for the calculation date, `joinday` for the rolling window dates used in aggregation

### Component D: Monthly active user aggregation
- **Purpose**: Calculate 30-day rolling unique address counts using HyperLogLog merging
- **Logic**: The system joins the rolling window structure with daily HLL sketches to create 30-day aggregation windows. For each day, it merges HLL sketches from the current day plus the previous 29 days. The merged sketches are then extracted to produce unique address counts representing monthly active users. This calculation is performed across multiple dimensional breakdowns including project level, chain level, user type level, and product level to enable different analytical perspectives.
- **Key fields**: `user_mau` representing the 30-day unique address count, `dimensions` indicating the breakdown level, `chain_id` for chain-specific counts

### Final aggregation
- **Combining components**: The methodology combines all dimensional breakdowns (project, chain, user type, product) into a unified monthly active user dataset through union operations
- **Metric transformation**: The final step relabels `user_mau` values as `active_addresses_monthly` since the underlying calculation treats users and addresses equivalently in blockchain contexts
- **Time aggregation**: Monthly values are calculated using rolling 30-day windows updated daily, providing continuous monthly metrics rather than calendar month snapshots
- **Final calculation**: The metric represents the exact count of unique addresses that initiated at least one transaction within any 30-day rolling period, with dimensional flexibility for various analytical use cases

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

Unique addresses active over a rolling 30-day window.

MoonbeamGLMR

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown