website

twitter

discord

github

Blockchains (L1)

Berachain

# Berachain Active addresses (daily) Methodology

## 1. Overview

Active addresses daily measures the number of unique addresses that initiated at least one transaction on the Berachain blockchain within a given day. This metric provides insight into daily user activity and engagement on the Berachain network by tracking distinct wallet addresses that actively participate in on-chain transactions.

The calculation identifies transaction senders (from addresses) from all Berachain transactions, groups them by day, and counts the distinct addresses using efficient HyperLogLog aggregation to handle large datasets while maintaining accuracy.

## 2. Data sources

The metric relies on the following data sources:

- **Berachain transaction records**: Complete transaction history from the Berachain blockchain, including transaction hashes, block timestamps, sender addresses (`from_address`), and other transaction metadata
- **Token Terminal project metadata**: Classification data that identifies Berachain as a blockchain in the blockchains_l1 market sector with blockchain business segment

## 3. Step-by-step calculation

### Component A: User identification from transactions
- **Purpose**: Extract unique addresses that initiated transactions on Berachain
- **Logic**: Process all Berachain transaction records and extract the `from_address` field as the user identifier. Each transaction sender represents a user address. Apply data type casting and add metadata classification including chain identifier ('berachain'), market sector ('blockchains_l1'), business segment ('blockchain'), and user type ('Transaction sender'). The `product_id` is set to null since this is chain-level analysis rather than product-specific
- **Key fields**: `block_timestamp` (transaction timing), `transaction_hash` (unique transaction identifier), `from_address` (sender address used as user identifier), `chain`, `market_sector_id`, `business_segment_id`, `user_type`

### Component B: Daily user activity aggregation
- **Purpose**: Group user activity by day and prepare for distinct counting
- **Logic**: Truncate `block_timestamp` to day level using timestamp truncation to create daily time boundaries. Select distinct combinations of truncated timestamp, user address, and metadata fields to eliminate duplicate entries for the same user on the same day. Apply incremental processing logic that includes a lookback period to reprocess recent data and ensure data completeness. Filter data based on chain availability requirements
- **Key fields**: `timestamp` (daily truncated timestamp), `timestamp_grain` ('day'), `user_address` (distinct user identifier), `chain`, `user_type`, `product_id`

### Component C: HyperLogLog aggregation across dimensions
- **Purpose**: Efficiently count distinct user addresses across multiple analytical dimensions
- **Logic**: Create HyperLogLog sketches using `hll_count.init()` with precision parameter 15 for each unique user address, grouped by timestamp and metadata fields. Generate separate dimensional breakdowns including project-level aggregation (project_dbt_tag dimension), chain-level aggregation (chain dimension with chain identifier), user-type-level aggregation (user_type dimension), and product-level aggregation (product_id dimension). Merge HLL sketches using `hll_count.merge_partial()` and extract final distinct counts using `hll_count.extract()` for each dimensional breakdown
- **Key fields**: `timestamp`, `timestamp_grain`, `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_dau` (distinct user count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project_dbt_tag, chain, user_type, product_id) into a single result set with standardized schema
- **Filtering and standardization**: Filter results to include only chain-level and project-level dimensions ('chain', 'project_dbt_tag') for the active addresses metric. Apply the finalize_metric macro to standardize schema, ensure consistent data types, and fill missing days with zero values to maintain continuous time series
- **Renaming for context**: Transform the `user_dau` field to `active_addresses_daily` to reflect the blockchain-specific interpretation where daily active users represent active addresses on the network
- **Final calculation**: The final metric represents the count of distinct addresses that initiated at least one transaction on Berachain for each day, with missing days filled with zeros to ensure complete time series continuity

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

Unique active addresses over a fixed 24-hour window.

BerachainBERA

Active addresses (daily)

Active addresses (daily)

Competitive landscape