website

twitter

Blockchains (L1)

Plasma

# Plasma Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses for Plasma measures the number of unique addresses that sent at least one transaction within any rolling 30-day period on the Plasma blockchain. This metric represents user engagement and adoption by tracking distinct transaction senders over monthly windows. The calculation uses HyperLogLog probabilistic data structures to efficiently count distinct addresses across large datasets and rolling time periods.

## 2. Data sources

- **Plasma transaction records**: Raw transaction data from the Plasma blockchain including timestamps, transaction hashes, and sender addresses
- **Complete date spine**: Generated date ranges ensuring no gaps in rolling window calculations
- **HyperLogLog probabilistic counters**: Efficient data structures for approximate distinct counting across large datasets

## 3. Step-by-step calculation

### Component A: User extraction from transactions
- **Purpose**: Identifies daily active users from raw transaction data
- **Logic**: Extracts all unique transaction sender addresses (`from_address`) from Plasma transaction records, truncating block timestamps to day level granularity. Each sender is classified as a "Transaction sender" user type within the "blockchains_l1" market sector and "blockchain" business segment. The component creates one record per unique address per day.
- **Key fields**: `block_timestamp` truncated to day, `from_address` as user address, constant values for chain ("plasma"), user type, and business segment classifications

### Component B: Daily active user aggregation  
- **Purpose**: Creates daily distinct user counts with HyperLogLog sketches
- **Logic**: Groups the daily user records by timestamp, chain, user type, and product dimensions. For each group, creates HyperLogLog sketches using the `hll_count.init` function with precision 15, which enables efficient approximate counting of distinct user addresses. This prepares the data for rolling window aggregations.
- **Key fields**: Daily `timestamp`, dimension groupings (`chain_id`, `user_type`, `product_id`), and HLL sketches containing distinct user counts

### Component C: Rolling window creation
- **Purpose**: Establishes 30-day rolling windows for monthly active user calculation
- **Logic**: Generates a complete date spine from the earliest transaction date to the current date minus one day. For each date in the spine, creates associations with the previous 29 days using array generation and unnesting operations. This ensures every day has a complete 30-day lookback window, even if some days had no transactions.
- **Key fields**: Base `timestamp` for each day and `joinday` representing each day within the 30-day window

### Component D: Monthly active user calculation
- **Purpose**: Computes distinct users across 30-day rolling windows
- **Logic**: Joins the rolling window structure with daily HLL sketches, then merges HLL sketches across each 30-day period using `hll_count.merge_partial`. Extracts final distinct counts using `hll_count.extract` to produce monthly active user values. The calculation is performed separately for different dimensional breakdowns: project level (`project_dbt_tag`), chain level, user type level, and product level.
- **Key fields**: Rolling window `timestamp`, dimension categories (`dimensions`), and extracted distinct user counts (`user_mau`)

### Final aggregation
- **Combining components**: All dimensional breakdowns (project, chain, user type, product) are combined using UNION ALL operations to create a comprehensive dataset with multiple aggregation levels
- **Schema standardization**: The `finalize_metric_user_mau` macro applies standard schema formatting, fills missing dates with zero values, and ensures consistent field naming and data types
- **Field renaming**: The final step renames `user_mau` to `active_addresses_monthly` to align with the metric's naming convention, while filtering for only chain-level and project-level dimensions
- **Final calculation**: The result represents the count of distinct addresses that sent transactions within each rolling 30-day period, providing a monthly active address metric that updates daily with new 30-day windows

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

Unique addresses active over a rolling 30-day window.

PlasmaXPL

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape