Validators process transactions and receive fees from users (supply-side fees).

BNB Chain is a smart contract platform for decentralized applications (a blockchain). BNB Chain was founded by Changpeng Zhao and launched in 2020.

BNB holders own and govern the protocol. They currently take a cut of the total transaction fees paid by users (revenue).

github

twitter

discord

etherscan

website

Blockchains (L1)

BNB Chain

# BNB Chain Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the distinct number of unique addresses that initiated at least one transaction on the BSC ecosystem during each 7-day rolling period. This metric tracks user engagement across both BSC mainnet (layer 1) and opBNB (layer 2) networks by counting transaction senders as active addresses. The calculation uses a 7-day rolling window approach, where each day's value represents the count of unique addresses that were active during that day plus the 6 preceding days.

## 2. Data sources

- **BSC mainnet transaction records**: Complete transaction data from BSC layer 1 blockchain including sender addresses (`from_address`), recipient addresses (`to_address`), block timestamps, and transaction metadata
- **opBNB layer 2 transaction records**: Complete transaction data from opBNB layer 2 network including sender addresses, block timestamps, and transaction identifiers
- **Chain availability filters**: Configuration data that determines active time periods for each blockchain network

## 3. Step-by-step calculation

### Component A: Daily active user extraction
- **Purpose**: Identify unique addresses that initiated transactions each day across both BSC mainnet and opBNB networks
- **Logic**: Extract transaction data from BSC mainnet and opBNB networks, truncate block timestamps to daily granularity, and identify transaction senders (`from_address` field) as active users. Classify transactions by market sector (layer 1 vs layer 2 blockchains), business segment (blockchain), and product identification. Union data from both networks to create a comprehensive daily active user dataset
- **Key fields**: `block_timestamp` (truncated to day), `from_address`/`user_address` as user identifiers, `chain` designation, `user_type` as "Transaction sender", and classification metadata

### Component B: HyperLogLog sketch creation
- **Purpose**: Create memory-efficient data structures for counting distinct addresses across time periods
- **Logic**: Group daily transaction data by timestamp, chain, user type, and product identification, then generate HyperLogLog sketches for each group using the `hll_count.init` function with precision parameter 15. These sketches enable efficient distinct counting when aggregating across multiple days
- **Key fields**: Daily `timestamp`, dimensional grouping fields (`chain_id`, `user_type`, `product_id`), and HLL sketches containing user address data

### Component C: Rolling window construction
- **Purpose**: Build 7-day rolling windows for each day to calculate weekly active addresses
- **Logic**: Create a complete datespine covering all days from the earliest available data to yesterday. For each day in the datespine, generate a 7-day window by creating join relationships with the current day plus the 6 preceding days. Join this window structure with the daily HLL sketches to associate user activity data with each 7-day period
- **Key fields**: Target `timestamp` for each window, `joinday` timestamps covering the 7-day range, and associated HLL sketches for each day in the window

### Component D: Weekly aggregation and dimensional breakdown
- **Purpose**: Calculate distinct active addresses for each 7-day window across multiple analytical dimensions
- **Logic**: For each 7-day window, merge the HLL sketches using `hll_count.merge_partial` function and extract the distinct count using `hll_count.extract`. Perform this calculation across four dimensional breakdowns: overall project level (`project_dbt_tag`), individual chain level (`chain`), user type level (`user_type`), and product level (`product_id`). Union all dimensional breakdowns together
- **Key fields**: `timestamp` for the window end date, `dimensions` indicating the breakdown level, dimension-specific identifiers (`chain_id`, `product_id`, `user_type`), and `user_wau` containing the distinct address count

### Final aggregation
- **Combining components**: Weekly active user data is directly mapped to active addresses since transaction senders represent active addresses in blockchain contexts. Filter the aggregated data to include only chain-level and project-level dimensional breakdowns
- **Currency conversion**: Not applicable for this count-based metric
- **Time aggregation**: Each daily timestamp represents a 7-day rolling window ending on that date. Windows overlap, with each day's value covering the current day plus 6 preceding days
- **Final calculation**: The final metric value equals the distinct count of addresses that initiated at least one transaction during the 7-day period ending on each date. Missing periods are filled with zero values to ensure complete time series continuity

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

Unique active addresses over a rolling 7-day window.

BNB ChainBNB

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown