Name: Avalanche Active addresses (daily) Metrics
Creator: Token Terminal
License: https://tokenterminal.com/terms

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

## 1. Overview

The Avalanche active addresses daily metric measures the number of unique addresses that performed at least one transaction on the Avalanche blockchain within a calendar day. This metric serves as a key indicator of user activity and engagement on the Avalanche network. The calculation identifies transaction senders as active addresses and uses probabilistic counting techniques to accurately count distinct addresses across different dimensional breakdowns while maintaining computational efficiency.

## 2. Data sources

The metric relies on the following raw data sources:

- **Avalanche blockchain transaction records**: Raw transaction data from the Avalanche blockchain containing transaction metadata including block timestamps, transaction hashes, and sender addresses (`from_address`)
- **Chain availability configuration data**: Data quality controls that ensure metrics are only calculated for time periods where blockchain data is complete and reliable

## 3. Step-by-step calculation

### Component A: User identification from transactions
- **Purpose**: Extract unique user addresses from Avalanche blockchain transactions and classify them as transaction senders
- **Logic**: The system processes all Avalanche blockchain transactions and extracts the `from_address` field from each transaction as the user address. Each transaction sender is classified as a 'Transaction sender' user type and associated with metadata including the 'avalanche' chain identifier, 'blockchains_l1' market sector, and 'blockchain' business segment. The `block_timestamp` is preserved to enable daily aggregation
- **Key fields**: `block_timestamp` for temporal grouping, `from_address` as the user identifier, `transaction_hash` for transaction linking, and classification fields like `user_type` and `chain`

### Component B: Daily user aggregation with HyperLogLog
- **Purpose**: Group users by calendar day and prepare for distinct counting across multiple dimensions
- **Logic**: Transaction data is aggregated by truncating `block_timestamp` to day boundaries to create daily user activity records. Each unique combination of day, chain, user type, and product is processed to create a distinct user record. The system applies incremental processing logic to handle data updates efficiently, focusing on recent partitions when processing incremental updates
- **Key fields**: `timestamp` (day-truncated), `timestamp_grain` set to 'day', `user_address` as the distinct user identifier, and dimensional fields like `chain`, `user_type`, and `product_id`

### Component C: HyperLogLog-based distinct counting
- **Purpose**: Create probabilistic distinct user counts that can be efficiently combined across different dimensional breakdowns
- **Logic**: The system initializes HyperLogLog sketches for each day and dimensional combination using a precision parameter of 15 bits. This allows for approximate distinct counting with high accuracy (standard error of ~0.65%) while enabling efficient aggregation operations. HyperLogLog sketches are created for each unique combination of timestamp, chain, user type, and product
- **Key fields**: `hll` sketches containing encoded distinct user information, grouped by `timestamp`, `timestamp_grain`, `chain`, `user_type`, and `product_id`

### Component D: Dimensional breakdown aggregation
- **Purpose**: Create multiple dimensional views of user activity data to support different analytical perspectives
- **Logic**: The system creates four distinct dimensional breakdowns by merging HyperLogLog sketches and extracting final counts: 1) Project-level aggregation combining all users across the entire project, 2) Chain-level breakdown showing users per blockchain, 3) User type breakdown segmenting by transaction sender categories, 4) Product-level breakdown for different protocol features. Each breakdown uses HLL merge operations to combine sketches while maintaining distinct count accuracy. The results include a `dimensions` field indicating the aggregation level and appropriate grouping fields
- **Key fields**: `dimensions` indicating breakdown type ('project_dbt_tag', 'chain', 'user_type', 'product_id'), `chain_id` for chain-specific data, `user_type` and `product_id` for categorical breakdowns, and `user_dau` containing the distinct user count

### Final aggregation
- **Combining components**: The active addresses metric extracts data specifically from chain-level and project-level dimensional breakdowns, filtering for records where `dimensions` equals 'chain' or 'project_dbt_tag'. The `user_dau` field is renamed to `active_addresses_daily` to reflect the specific metric being calculated
- **Currency conversion**: Not applicable for this count-based metric
- **Time aggregation**: Data is aggregated at daily boundaries using calendar day logic, with timestamps truncated to day precision. The finalization macro applies zero-filling for missing dates to ensure continuous time series coverage
- **Final calculation**: The final active addresses count represents the distinct number of Avalanche addresses that sent at least one transaction on each calendar day. Chain availability filters are applied to exclude dates where blockchain data may be incomplete or unreliable, ensuring metric accuracy and consistency

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

AvalancheAVAX