Validators process transactions and receive fees from users (supply-side fees).

Aptos is a smart contract platform for decentralized applications (a blockchain). Aptos was founded by Mo Shaikh and Avery Ching and launched in 2022.

APT token holders own and govern the protocol. They currently don’t take a cut of the total transaction fees paid by users (revenue). Aptos’ investors include Binance Labs, Jump Crypto, Apollo, etc.

governance

github

twitter

discord

website

Blockchains (L1)

Aptos

# Aptos Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Aptos measures the number of unique addresses that sent at least one transaction in any 7-day rolling period. This metric answers the question "How many distinct users were active on the Aptos blockchain in the past week?" and uses HyperLogLog algorithms for efficient distinct user counting across multiple dimensional breakdowns.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Aptos transaction records**: Complete transaction history from the Aptos blockchain including sender addresses, timestamps, gas usage, and transaction metadata
- **Genesis timestamp handling**: Special logic hardcodes genesis transactions to October 12th, 2022 to handle pre-mainnet data
- **Transaction metadata**: Gas consumption and pricing information for each transaction

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identifies unique transaction senders per day to create the foundation for WAU calculations
- **Logic**: Extracts all Aptos transactions and groups by daily timestamps. For each day, identifies distinct sender addresses that initiated transactions. Applies timestamp truncation to day boundaries and classifies all users as 'Transaction sender' type. Handles genesis period by hardcoding pre-2000 timestamp transactions to October 12th, 2022. Assigns market sector as 'blockchains_l1' and business segment as 'blockchain'
- **Key fields**: `block_timestamp` converted to daily `timestamp`, `sender` as `user_dau`, `user_type` as 'Transaction sender', `chain` as 'aptos'

### Component B: HyperLogLog initialization 
- **Purpose**: Converts daily user sets into HyperLogLog sketches for memory-efficient distinct counting
- **Logic**: Takes daily active user data and initializes HLL sketches with precision parameter 15. Groups by timestamp, chain, user type, and product dimensions. Creates HLL data structure that approximates distinct counts without storing individual user addresses
- **Key fields**: `hll` sketch containing compressed user set, dimensional grouping fields (`timestamp`, `chain_id`, `user_type`, `product_id`)

### Component C: Rolling window creation
- **Purpose**: Establishes 7-day rolling windows for each date to calculate weekly active users
- **Logic**: Creates a datespine covering all days from the earliest transaction date to current date minus 1 day. For each date in the spine, generates a 7-day window consisting of the current day plus the 6 preceding days. Uses timestamp array generation to create these rolling windows efficiently
- **Key fields**: `timestamp` for the reporting date, `joinday` representing each day within the 7-day window

### Component D: Window-based HLL aggregation
- **Purpose**: Merges daily HLL sketches across each 7-day window to calculate distinct weekly users
- **Logic**: Joins the rolling window structure with daily HLL data. For each reporting date, collects HLL sketches from all 7 days in the window. Applies HLL merge operations to combine sketches while maintaining distinct count accuracy. Preserves dimensional breakdowns throughout the aggregation process
- **Key fields**: Merged `hll` sketches representing 7-day user sets, dimensional grouping maintained from daily level

### Component E: Multi-dimensional breakdown
- **Purpose**: Calculates WAU across different analytical dimensions for comprehensive reporting
- **Logic**: Creates four separate dimensional views of the WAU data. Project level aggregation nullifies chain, product, and user type dimensions. Chain level breakdown maintains chain identity while nullifying others. User type breakdown focuses on user classification. Product level breakdown handles product-specific analysis. Each breakdown extracts final counts from merged HLL sketches using `hll_count.extract`
- **Key fields**: `user_wau` as the distinct count result, `dimensions` indicating the breakdown type ('project_dbt_tag', 'chain', 'user_type', 'product_id')

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily reporting with 7-day rolling windows, where each day represents the count of distinct users active in that day plus the preceding 6 days
- **Final calculation**: Applies the `finalize_metric_user_wau` macro with data ID 'aptos' and zero-fill strategy to standardize schema, handle missing dates with zeros, and ensure consistent metric formatting across the Token Terminal platform

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

Unique revenue-generating users over a rolling 7-day window.

AptosAPT

Active users (weekly)

Active users (weekly)

Competitive landscape