website

twitter

discord

Blockchains (L2)

Shape

# Shape Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Shape blockchain within a rolling 7-day period. This metric provides insight into user engagement and adoption by tracking distinct transaction senders over weekly windows. The calculation uses HyperLogLog probabilistic counting for efficient computation of distinct address counts across rolling time periods.

## 2. Data sources

The methodology relies on the following raw data sources:

- **Shape blockchain transaction logs**: Complete transaction history including transaction metadata, block timestamps, and sender addresses
- **Transaction metadata**: Block-level timing information (`block_timestamp`), transaction identifiers (`transaction_hash`), and sender addresses (`from_address`)

## 3. Step-by-step calculation

### Component A: User identification and daily activity
- **Purpose**: Identifies unique active addresses per day from Shape blockchain transactions
- **Logic**: Extracts transaction sender addresses (`from_address`) from Shape blockchain transaction logs. Each transaction represents user activity, with the sender address serving as the user identifier. Timestamps are truncated to day-level granularity using `block_timestamp`. Creates one record per unique address per day, effectively deduplicating multiple transactions from the same address within a single day.
- **Key fields**: `block_timestamp` for temporal grouping, `from_address` as the unique user identifier, along with metadata including `transaction_hash`, `chain`, `market_sector_id`, `business_segment_id`, and `user_type`

### Component B: Daily active user aggregation
- **Purpose**: Calculates daily distinct active users as the foundation for weekly calculations
- **Logic**: Takes the user identification data and creates daily aggregates by counting distinct user addresses per day. Applies timestamp truncation to ensure clean daily boundaries. Assigns standardized metadata including chain identifier and timestamp grain. Implements incremental processing strategy with daily partitioning for efficient updates.
- **Key fields**: `timestamp` (day-level), `timestamp_grain` (set to 'day'), `chain`, `user_type`, `product_id`, and `user_dau` (the distinct user address)

### Component C: HyperLogLog sketch creation
- **Purpose**: Converts daily user sets into probabilistic data structures for efficient set operations
- **Logic**: Creates HyperLogLog sketches from daily active user data using 15-bit precision. Groups data by timestamp, chain, user type, and product dimensions. HLL sketches enable efficient approximate counting of distinct elements and support merge operations for combining sets across time periods.
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, and `hll` (the HyperLogLog sketch)

### Component D: Rolling window construction
- **Purpose**: Creates 7-day rolling windows for weekly active user calculation
- **Logic**: Uses a datespine approach to ensure complete time coverage without gaps. For each day, generates a 7-day lookback period (current day plus 6 previous days). Creates join relationships between each target date and its corresponding 7-day window of source dates. This window approach ensures consistent weekly calculations even when certain days have no activity.
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 7-day window)

### Component E: Weekly aggregation using HLL merge
- **Purpose**: Calculates distinct users across 7-day windows using HyperLogLog operations
- **Logic**: Joins the rolling window structure with daily HLL sketches. For each target date, merges HLL sketches from all days within the 7-day window using `hll_count.merge_partial()`. Extracts final distinct counts using `hll_count.extract()`. This approach efficiently handles overlapping windows and provides approximate distinct counts with high accuracy.
- **Key fields**: `timestamp`, `timestamp_grain`, `chain_id`, `user_type`, `product_id`, and `user_wau` (weekly active users count)

### Component F: Dimensional breakdowns
- **Purpose**: Provides weekly active user metrics across different analytical dimensions
- **Logic**: Creates separate aggregations for different breakdown levels including project-level (`project_dbt_tag`), chain-level, user type-level, and product-level views. Each dimension uses the same HLL merge logic but groups data differently. Combines all dimensional views using union operations to create a comprehensive dataset.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, and `user_wau`

### Final aggregation
- **Combining components**: The weekly active user data is filtered to include only chain-level and project-level dimensions, then the `user_wau` field is renamed to `active_addresses_weekly` to reflect the blockchain context where users are represented by their addresses
- **Currency conversion**: Not applicable for this address-counting metric
- **Time aggregation**: Uses rolling 7-day windows calculated daily, providing a continuous time series of weekly active address counts
- **Final calculation**: The final metric represents the count of distinct addresses that initiated at least one transaction within any 7-day rolling period, calculated using HyperLogLog probabilistic counting for efficiency and accuracy

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

Unique active addresses over a rolling 7-day window.

ShapeSHAPE

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape