Validators process transactions and receive validator rewards (supply-side fees).

AVAX is a smart contract platform for decentralized applications (a blockchain). Avalanche was founded by Emin Gün Sirer and launched in 2019.

AVAX holders own and govern the protocol. They currently take (burn) all of the total transaction fees paid by users (revenue). AVAXs investors include a16z, Polychain, Galaxy Digital, etc.

github

twitter

discord

etherscan

website

Blockchains (L1)

Avalanche

# Avalanche Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have sent at least one transaction on the Avalanche blockchain within a rolling 30-day window. This metric provides insights into network adoption and user engagement by tracking distinct addresses that actively participate in network activity each month. The calculation uses a rolling window approach where each day's value represents the count of unique addresses active in the current day plus the previous 29 days.

## 2. Data sources

- **Avalanche blockchain transactions**: Complete transaction records from the Avalanche network, including sender addresses, timestamps, and transaction hashes
- **Chain availability configuration**: Metadata used to filter results based on data quality and completeness across different time periods

## 3. Step-by-step calculation

### Component A: Transaction sender identification
- **Purpose**: Extract and classify all transaction senders from Avalanche blockchain
- **Logic**: All transactions from Avalanche blockchain are processed to identify the `from_address` field as transaction senders. Each sender is classified with user type as "Transaction sender", market sector as "blockchains_l1", business segment as "blockchain", chain as "avalanche", and null product ID. Transaction timestamps are preserved for temporal analysis.
- **Key fields**: `from_address` (transaction sender), `block_timestamp` (transaction time), `transaction_hash` (unique identifier)

### Component B: Daily active user aggregation  
- **Purpose**: Create daily snapshots of unique active addresses using memory-efficient counting
- **Logic**: Transaction senders are aggregated by day using timestamp truncation to day granularity. For each day, unique user addresses are counted using HyperLogLog sketches for memory-efficient distinct counting. Data is grouped by timestamp, chain, user type, and product ID. HyperLogLog sketches are initialized with precision parameter 15 for optimal memory usage while maintaining accuracy.
- **Key fields**: `timestamp` (day-level), `user_dau` (daily active address), `hll` (HyperLogLog sketch)

### Component C: Rolling 30-day window creation
- **Purpose**: Calculate monthly active users using rolling 30-day windows
- **Logic**: A complete datespine is generated covering the full time range of available data. For each day in the datespine, a 30-day window is created spanning the current day plus the previous 29 days using timestamp range generation. Daily HyperLogLog sketches are joined to each applicable day in the rolling window. HyperLogLog sketches within each 30-day window are merged and extracted to produce distinct user counts, accounting for address overlap across multiple days.
- **Key fields**: `timestamp` (window end date), `user_mau` (30-day unique address count)

### Component D: Multi-dimensional breakdown
- **Purpose**: Calculate monthly active users across different analytical dimensions
- **Logic**: The rolling window MAU calculation is performed separately for four dimension levels: project level (project_dbt_tag), chain level, user type level, and product level. Each breakdown uses the same 30-day rolling window logic but groups data differently. Results from all four breakdowns are combined using UNION ALL to create a comprehensive dataset with dimension-specific MAU values.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_mau`

### Final aggregation
- **Combining components**: The user MAU data is filtered to include only 'chain' and 'project_dbt_tag' dimensions, as these are the relevant breakdowns for the active addresses metric. The `user_mau` field is directly mapped to `active_addresses_monthly` since addresses and users are equivalent in blockchain context.
- **Currency conversion**: No currency conversion required as this is a count-based metric
- **Time aggregation**: Monthly values are calculated using 30-day rolling windows where each day represents the count of unique addresses active in that day plus the previous 29 days
- **Final calculation**: The final active addresses monthly value equals the distinct count of addresses that sent at least one transaction within the rolling 30-day window ending on each date, filtered for chain and project-level dimensions only

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

Unique addresses active over a rolling 30-day window.

AvalancheAVAX

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape