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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Aptos measures the count of unique addresses that have initiated transactions on the Aptos blockchain within rolling 30-day periods. This metric provides insight into user engagement and adoption by tracking distinct transaction senders over monthly windows. The calculation uses HyperLogLog probabilistic counting for efficient processing of large datasets and provides breakdowns across multiple dimensions including chain, user type, and product categories.

## 2. Data sources

- **Aptos blockchain transactions**: Complete transaction records from the Aptos blockchain including transaction hashes, sender addresses, block timestamps, gas usage, and gas unit prices
- **Table modification metadata**: Internal tracking data for incremental processing that records when underlying data was last updated

## 3. Step-by-step calculation

### Component A: Transaction data preparation
- **Purpose**: Extract and standardize raw Aptos transaction data with proper timestamp handling
- **Logic**: Retrieves all transactions from Aptos blockchain data, converting gas unit prices from raw integer values to decimal format by dividing by 10^8. Applies special handling for genesis transactions by hardcoding those with timestamps before 2000-01-01 to October 12th 2022 (the official Aptos mainnet launch date). Filters out any transactions with unrealistic timestamps before 2000-01-01 in the main query.
- **Key fields**: `block_timestamp`, `hash` as transaction identifier, `sender` address, `gas_used` amounts, `gas_unit_price` in decimal format

### Component B: Daily active user extraction  
- **Purpose**: Identify unique user addresses that initiated transactions each day
- **Logic**: Groups transaction data by day using timestamp truncation to day level. Extracts distinct sender addresses for each day, classifying them as "Transaction sender" user type. Assigns chain identifier as "aptos", market sector as "blockchains_l1", and business segment as "blockchain". Product identifier is left null since this tracks general blockchain usage rather than specific applications.
- **Key fields**: `timestamp` truncated to day, `chain` identifier, `user_type` classification, `user_dau` containing sender addresses

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user sets into HyperLogLog sketches for efficient approximate counting
- **Logic**: Takes the daily active user data and initializes HyperLogLog sketches with precision 15 for each day. Groups by timestamp, chain, user type, and product dimensions to maintain proper granularity. The HLL initialization enables probabilistic counting of unique users across time windows without storing individual addresses.
- **Key fields**: `timestamp`, `timestamp_grain`, `chain_id`, `user_type`, `product_id`, `hll` sketch data

### Component D: Date spine creation
- **Purpose**: Ensure complete daily coverage for rolling window calculations
- **Logic**: Generates a continuous sequence of timestamps from the earliest date in the daily active user data to yesterday (current date minus 1 day). Uses timestamp array generation with 1-day intervals to create a complete spine. For incremental processing, starts from 29 days plus incremental lookback days before the last modified time to ensure proper window coverage.
- **Key fields**: `timestamp` for each day in the range

### Component E: Rolling window generation
- **Purpose**: Create 30-day rolling windows by joining each day with its preceding 29 days
- **Logic**: For each day in the date spine, generates an array of the current day plus the previous 29 days (30 days total). Uses timestamp arithmetic to subtract 29 days and create daily intervals. Cross-joins the date spine with these generated day ranges to create the foundation for rolling window calculations.
- **Key fields**: `timestamp` for the window end date, `joinday` for each day within the 30-day window

### Component F: Window data assembly
- **Purpose**: Combine rolling window structure with HyperLogLog data from daily active users
- **Logic**: Joins the rolling window structure with the HLL-initialized daily data, matching on the join days. This creates a dataset where each row represents one day within a 30-day window, with the corresponding HLL sketch for that day. Applies incremental filtering with 60-day safety margin to ensure complete window coverage.
- **Key fields**: `timestamp` for window end, `timestamp_grain`, dimensional identifiers, `hll` sketches for merging

### Component G: Dimensional MAU breakdowns
- **Purpose**: Calculate MAU across different analytical dimensions
- **Logic**: Creates four separate dimensional views of the data:
  - Project level: Aggregates all data without dimensional splits, nulling out chain, product, and user type fields
  - Chain level: Groups by chain identifier while nulling product and user type  
  - User type level: Groups by user type classification while nulling chain and product
  - Product level: Groups by product identifier while nulling chain and user type
  
  For each breakdown, merges HLL sketches across the 30-day windows using `hll_count.merge_partial()` and extracts the final unique count using `hll_count.extract()`.
- **Key fields**: `timestamp`, `dimensions` indicating breakdown type, relevant dimensional fields, `user_mau` counts

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns (project, chain, user type, product) into a single result set, maintaining the dimensional structure through the `dimensions` field and appropriate null values for non-applicable dimension columns
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 30-day rolling windows where each day represents the count of unique users over the current day plus the previous 29 days. Monthly partitioning is applied for storage optimization
- **Final calculation**: Applies the `finalize_metric_user_mau` macro with "fill_zeros" strategy to standardize the metric format, handle missing data points, and ensure consistent schema. For incremental processing, filters final results to include only data from 29 days plus incremental lookback days before the last modified time

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

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

AptosAPT

Active users (monthly)

Active users (monthly)

Competitive landscape