Blockchains (L3)

Anime

# Anime Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have initiated at least one transaction on the Anime blockchain within a rolling 30-day window. This metric serves as a proxy for user activity and engagement on the blockchain, providing insights into the growth and adoption of the Anime network. The calculation uses a rolling window approach where each day represents the count of distinct addresses active over the previous 30 days, employing HyperLogLog algorithms for efficient approximate distinct counting.

## 2. Data sources

The metric relies on the following raw data sources:

- **Anime blockchain transaction data**: Complete transaction records from the Anime blockchain containing sender addresses, timestamps, and transaction metadata
- **Transaction metadata**: Block timestamps and transaction hashes used for temporal analysis and deduplication
- **Calendar datespine**: Generated date sequences to ensure complete time series coverage without gaps

## 3. Step-by-step calculation

### Component A: User fact table construction
- **Purpose**: Extract and standardize user addresses from raw transaction data
- **Logic**: Raw Anime blockchain transactions are processed to extract sender addresses (`from_address`) and block timestamps. Each transaction sender is classified as a "Transaction sender" user type. The data is standardized with consistent field names and includes metadata such as chain identifier ("anime"), market sector ("blockchains_l2"), and business segment ("blockchain"). Product-level dimensions are set to null as this represents chain-level activity.
- **Key fields**: `block_timestamp`, `transaction_hash`, `from_address` (renamed to `user_address`), `user_type`, `chain`

### Component B: Daily active user calculation  
- **Purpose**: Calculate distinct daily active users with proper deduplication
- **Logic**: Transaction data is grouped by day using timestamp truncation to daily granularity. For each day, distinct sender addresses are identified to count unique users. The calculation includes temporal partitioning and incremental processing logic to handle new data efficiently. Each daily record includes dimensional attributes for later aggregation.
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain`, `user_address`, dimensional attributes

### Component C: HyperLogLog sketch creation
- **Purpose**: Create probabilistic data structures for efficient distinct counting across rolling windows  
- **Logic**: Daily active user data is converted into HyperLogLog sketches with precision 15, enabling approximate distinct counting with high accuracy. Each day's unique users are represented as an HLL sketch that can be efficiently merged with other time periods. This approach allows for accurate distinct counting across overlapping 30-day windows without storing individual address lists.
- **Key fields**: `timestamp`, `hll` (HyperLogLog sketch), dimensional groupings

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for monthly active user calculation
- **Logic**: A datespine is generated covering the entire analysis period, ensuring no gaps in the time series. For each calendar day, a 30-day window is constructed including the current day and the previous 29 days. This creates overlapping windows where each day represents a different 30-day period. The window construction uses timestamp arrays to generate the specific days included in each rolling period.
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within each window)

### Component E: Monthly active user aggregation
- **Purpose**: Calculate distinct users across 30-day rolling windows using HyperLogLog
- **Logic**: For each 30-day window, HyperLogLog sketches from constituent days are merged using the `hll_count.merge_partial` function. The merged sketch is then extracted to produce an approximate count of distinct users active during that 30-day period. This process is applied across multiple dimensional breakdowns including chain-level, project-level, user-type-level, and product-level aggregations.
- **Key fields**: `user_mau` (monthly active users), `dimensions` (breakdown type), dimensional attributes

### Component F: Dimensional breakdown aggregation  
- **Purpose**: Create multiple analytical perspectives of the monthly active user data
- **Logic**: Monthly active users are calculated separately for four dimensional breakdowns: by chain (Anime-specific), by project tag (protocol-wide), by user type (transaction senders), and by product (null for chain-level). Each breakdown aggregates HyperLogLog sketches at the appropriate level while nullifying irrelevant dimensional attributes. The results are combined using union operations to create a comprehensive dataset.
- **Key fields**: `dimensions`, `chain_id`, `product_id`, `user_type`, `user_mau`

### Final aggregation
- **Combining components**: Monthly active user data is filtered to include only chain-level and project-level dimensions, then renamed from `user_mau` to `active_addresses_monthly` to reflect the address-centric perspective
- **Time aggregation**: Each timestamp represents the end date of a 30-day rolling window, with monthly granularity for reporting
- **Final calculation**: The final metric directly uses the monthly active user count, treating each unique address as representing one active address for the period
- **Data quality**: Missing periods are filled with zero values, and chain availability filters ensure data is only reported for periods when the Anime blockchain was operational

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

Unique addresses active over a rolling 30-day window.

AnimeANIME

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown