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

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one transaction on the Aptos blockchain within any rolling 30-day period. This metric serves as a proxy for user activity and adoption on the Aptos network, providing insights into the blockchain's usage patterns and growth trends. The calculation uses HyperLogLog (HLL) probabilistic counting to efficiently aggregate unique addresses across overlapping time windows, with results reported monthly.

## 2. Data sources

The metric relies on the following data sources:
- **Aptos transaction records**: Complete transaction history from the Aptos blockchain, including transaction senders, timestamps, gas usage, and transaction hashes
- **Chain availability configuration**: Internal configuration data used to filter results based on data availability windows
- **Table modification metadata**: Timestamps tracking when underlying data tables were last updated, used for incremental processing optimization

## 3. Step-by-step calculation

### Component A: Raw transaction processing
- **Purpose**: Extract and standardize transaction data from the Aptos blockchain
- **Logic**: Retrieve all transactions from Aptos blockchain data, including `block_timestamp`, transaction `hash`, `sender` address, `gas_used`, and `gas_unit_price`. Apply special handling for genesis transactions that have timestamps before 2000-01-01 by hardcoding their timestamp to October 12, 2022 (Aptos mainnet launch date). Normalize gas unit prices by dividing by 10^8 to convert from smallest unit to standard unit representation.
- **Key fields**: `block_timestamp` for temporal grouping, `sender` as the unique address identifier, `gas_used` and normalized `gas_unit_price` for transaction context

### Component B: Daily active user identification  
- **Purpose**: Identify unique transaction senders on each day
- **Logic**: Group transactions by day using timestamp truncation and extract distinct sender addresses for each day. Classify all senders as "Transaction sender" user type and assign them to the 'aptos' chain with 'blockchains_l1' market sector. Apply incremental processing logic to only process recent data when updating existing calculations.
- **Key fields**: `timestamp` (daily truncated), `user_dau` (unique sender address), `user_type` classification, and chain metadata

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily unique users into probabilistic counting data structures for efficient aggregation
- **Logic**: Transform daily active user data into HyperLogLog sketches with 15-bit precision using `hll_count.init()`. Group by timestamp, chain, user type, and product dimensions to create separate sketches for each combination. This enables efficient counting of unique users across overlapping time windows without storing individual addresses.
- **Key fields**: `hll` sketch containing probabilistic representation of unique users for each day and dimension combination

### Component D: Rolling 30-day window calculation
- **Purpose**: Create overlapping 30-day windows to calculate monthly active users
- **Logic**: Generate a continuous datespine covering all days from the earliest transaction date to yesterday. For each day in the datespine, create joins to the previous 29 days (30-day total window) to form rolling windows. Join these windows with the daily HLL sketches to aggregate user activity across each 30-day period. This approach ensures no days are skipped even if no transactions occurred.
- **Key fields**: `timestamp` for the window end date, `joinday` for dates within each 30-day window, merged `hll` sketches for user counting

### Component E: Multi-dimensional breakdown
- **Purpose**: Calculate monthly active users across different analytical dimensions
- **Logic**: Aggregate HLL sketches across four different dimensional breakdowns: 1) Chain level - grouped by `chain_id`, 2) Project level - grouped by 'project_dbt_tag' dimension, 3) User type level - grouped by `user_type`, 4) Product level - grouped by `product_id`. For each breakdown, merge HLL sketches using `hll_count.merge_partial()` and extract final counts using `hll_count.extract()`.
- **Key fields**: `dimensions` indicating the breakdown type, `user_mau` containing the extracted unique user count for each dimension

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (chain, project_dbt_tag, user_type, product_id) into a single result set with consistent schema structure
- **Currency conversion**: No currency conversion required as this metric counts addresses rather than monetary values
- **Time aggregation**: Results are calculated as rolling 30-day windows updated daily, then filtered to only include chain and project_dbt_tag dimensions for the final active addresses metric
- **Final calculation**: The `user_mau` field from the MAU calculation is directly aliased as `active_addresses_monthly`, representing the count of unique addresses that were active within any 30-day period ending on each date. The metric is finalized using the `finalize_metric_active_addresses_monthly` macro which applies schema standardization and fills missing periods with zeros.

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

Unique addresses active over a rolling 30-day window.

AptosAPT

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape