twitter

discord

website

Blockchains (L1)

Movement

# Movement Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Movement blockchain during a rolling 7-day period. This metric provides insights into user engagement and network activity by tracking distinct transaction senders over weekly intervals. The calculation uses probabilistic counting through HyperLogLog algorithms to accurately handle overlapping users across the rolling time window while maintaining computational efficiency.

## 2. Data sources

- **Movement blockchain transaction records**: Complete transaction history including sender addresses, transaction hashes, block timestamps, gas consumption, and gas pricing data
- **Transaction metadata**: Additional transaction details and validation information from the Movement blockchain
- **Chain availability configuration**: Token Terminal's internal chain availability filters to ensure data quality and completeness

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and prepare raw Movement blockchain transaction data for user activity analysis
- **Logic**: Pull all transactions from Movement blockchain including sender addresses, transaction hashes, block timestamps, gas usage, and gas unit prices. Apply timestamp filtering to exclude pre-2000 dates (likely test data) while including a special hardcoded genesis transaction from December 5, 2024. Convert gas unit prices from 8-decimal precision to standard units by dividing by 10^8. Filter for valid timestamps and transaction data
- **Key fields**: `block_timestamp` for temporal analysis, `sender` addresses as user identifiers, `transaction_hash` for uniqueness, `gas_used` and `gas_unit_price` for transaction cost analysis

### Component B: Daily active user identification  
- **Purpose**: Identify unique active users on a daily basis by tracking transaction senders
- **Logic**: Group transactions by day using timestamp truncation to daily granularity. Extract distinct sender addresses for each day, classifying them as 'Transaction sender' user type. Associate each user with Movement chain metadata including market sector ('blockchains_l2') and business segment ('blockchain') classifications. Create daily user records with temporal, chain, and user type dimensions
- **Key fields**: `timestamp` truncated to day, `user_dau` containing unique sender addresses, `chain` identifier, `user_type` classification, and dimensional metadata

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily active users into probabilistic data structures for efficient weekly aggregation
- **Logic**: Transform daily active user addresses into HyperLogLog sketches with 15-bit precision to enable approximate distinct counting. Group daily users by timestamp, chain, user type, and product dimensions. Create HyperLogLog sketches for each group to prepare for rolling window aggregation while maintaining accuracy for large user sets
- **Key fields**: `hll` sketches containing compressed user data, dimensional grouping fields, and daily timestamps

### Component D: Weekly rolling window generation
- **Purpose**: Create 7-day rolling windows for weekly active user calculation
- **Logic**: Generate a complete datespine covering the entire analysis period from minimum timestamp to current date minus one day. For each date in the datespine, create a 7-day lookback window by generating timestamps for the current day plus the previous 6 days. Join this window structure with daily HyperLogLog sketches to create overlapping 7-day periods that capture all user activity within each rolling window
- **Key fields**: `timestamp` for window end dates, `joinday` for window component dates, joined `hll` sketches from daily data

### Component E: Multi-dimensional weekly aggregation
- **Purpose**: Calculate weekly active users across different analytical dimensions
- **Logic**: Merge HyperLogLog sketches within each 7-day window to count distinct users, then extract the final count estimate. Create separate aggregations for project-level (`project_dbt_tag`), chain-level (`chain`), user type level (`user_type`), and product level (`product_id`) analysis. Each dimension provides different analytical perspectives while maintaining user uniqueness through probabilistic counting
- **Key fields**: `user_wau` containing weekly active user counts, `dimensions` indicating aggregation level, dimensional identifier fields (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: Weekly active user counts are calculated independently for each dimension (project, chain, user type, product) and combined into a unified result set through union operations
- **Currency conversion**: No currency conversion required as this is a count-based metric measuring user activity rather than financial values
- **Time aggregation**: Uses 7-day rolling windows where each date represents the count of unique users active in that date plus the previous 6 days, providing smooth trending without artificial weekly boundaries
- **Final calculation**: The `user_wau` field is renamed to `active_addresses_weekly` to align with Token Terminal's naming conventions for address-based activity metrics. Chain availability filters are applied to ensure data quality and exclude periods with incomplete data coverage

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

Unique active addresses over a rolling 7-day window.

MovementMOVE

Archived

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape