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

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Avalanche blockchain within a 7-day rolling window. This metric answers the question "How many distinct addresses are actively transacting on Avalanche each week?" The calculation uses HyperLogLog probabilistic counting for memory-efficient computation of distinct addresses across overlapping time windows.

## 2. Data sources

The calculation relies on:
- **Avalanche blockchain transactions**: Raw transaction records from the Avalanche blockchain containing sender addresses, timestamps, and transaction hashes
- **Table modification metadata**: Timestamps tracking when underlying data tables were last updated, used for incremental processing optimization

## 3. Step-by-step calculation

### Component A: User identification
- **Purpose**: Identify all unique transaction senders from Avalanche blockchain data
- **Logic**: Extract all transaction sender addresses from Avalanche blockchain transaction records. Each transaction sender address (`from_address`) is captured along with the block timestamp (`block_timestamp`) and transaction hash. All senders are classified as "Transaction sender" user type and tagged with chain metadata including "avalanche" chain identifier, "blockchains_l1" market sector, and "blockchain" business segment.
- **Key fields**: `from_address` (renamed to `user_address`), `block_timestamp`, `transaction_hash`, and metadata fields for classification

### Component B: Daily active user aggregation  
- **Purpose**: Create daily distinct counts of active user addresses
- **Logic**: Aggregate transaction senders by day using timestamp truncation to day boundaries. Each unique user address is counted only once per day regardless of how many transactions they sent. The data is filtered using incremental processing logic that looks back a configurable number of days plus one additional day to ensure data completeness.
- **Key fields**: `timestamp` (truncated to day), `user_address` (renamed to `user_dau`), `timestamp_grain` (set to "day"), and classification metadata

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user data into probabilistic data structures for efficient distinct counting
- **Logic**: Transform daily active user data into HyperLogLog sketches using 15-bit precision. Each day's unique users are initialized into an HLL sketch that enables memory-efficient approximate distinct counting. This allows for efficient merging of user counts across time windows without storing all individual addresses.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Seven-day rolling window construction
- **Purpose**: Create overlapping 7-day windows for weekly active user calculation
- **Logic**: Generate a complete datespine covering all days from the minimum timestamp to yesterday. For each day in the datespine, create a 7-day window that includes the current day plus the 6 preceding days. This is accomplished by generating joindays for each window (current day minus 6 days through current day) and joining these with the daily HLL data to capture all users active within each 7-day period.
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within each window), joined with HLL sketches from matching days

### Component E: Weekly active user calculation by dimension
- **Purpose**: Calculate distinct weekly active users across different analytical dimensions
- **Logic**: For each 7-day window, merge all HLL sketches within the window and extract the distinct count to get weekly active users. This calculation is performed separately for four different dimensions: project level (project_dbt_tag), chain level, user type level, and product level. Each dimension aggregates the data differently - project level nullifies chain/product/user type fields, chain level keeps chain_id, user type level keeps user_type, and product level keeps product_id.
- **Key fields**: `user_wau` (weekly active users count), `dimensions` (breakdown type), dimension-specific identifier fields

### Final aggregation
- **Combining components**: The four dimensional breakdowns (project_dbt_tag, chain, user_type, product_id) are combined using UNION ALL to create a comprehensive dataset with weekly active users calculated across all relevant dimensions
- **Currency conversion**: No currency conversion is required as this metric counts addresses rather than monetary values
- **Time aggregation**: Weekly aggregation uses 7-day rolling windows where each day represents the count of unique addresses active in that day plus the 6 preceding days
- **Final calculation**: The weekly active user count (`user_wau`) is directly renamed to weekly active addresses (`active_addresses_weekly`) since for blockchain metrics, active users are equivalent to active addresses. The final output includes only chain-level and project-level breakdowns as filtered by the dimensions filter.

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

Unique active addresses over a rolling 7-day window.

AvalancheAVAX

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape