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

## 1. Overview

Active addresses daily for BSC measures the number of unique addresses that initiated at least one transaction on the BSC ecosystem during a given day. This metric combines activity from both BSC mainnet (Layer 1) and OpBNB (Layer 2) to provide a comprehensive view of daily user engagement across the BSC ecosystem. The calculation uses HyperLogLog algorithms for efficient distinct counting across large datasets and supports multiple dimensional breakdowns including chain-level, user-type, and product-level aggregations.

## 2. Data sources

The calculation draws from two primary blockchain transaction data sources:

- **BSC mainnet transaction records**: Raw transaction data from the Binance Smart Chain Layer 1 blockchain, including transaction metadata such as sender addresses, recipient addresses, block timestamps, gas usage, and transaction hashes
- **OpBNB L2 transaction records**: Raw transaction data from the OpBNB Layer 2 scaling solution, containing similar transaction metadata including sender addresses, block timestamps, and transaction identifiers

Both data sources provide comprehensive transaction logs that capture all network activity, with sender addresses (`from_address`) serving as the primary identifier for active users.

## 3. Step-by-step calculation

### Component A: BSC mainnet transaction processing
- **Purpose**: Extract and standardize user activity data from BSC mainnet transactions
- **Logic**: Raw BSC transaction records are processed to extract key fields including `block_timestamp`, `transaction_hash`, `from_address`, and `to_address`. The system applies safe type casting to ensure data quality and adds standardized metadata including 'bsc' as the chain identifier, 'blockchains_l1' as the market sector, and 'blockchain' as the business segment. Transaction senders (`from_address`) are classified as 'Transaction sender' user types and represent the active addresses for this data source.
- **Key fields**: `block_timestamp` for timing, `from_address` as the user identifier, and standardized metadata fields for dimensional breakdowns

### Component B: OpBNB L2 transaction processing  
- **Purpose**: Extract and standardize user activity data from OpBNB Layer 2 transactions
- **Logic**: OpBNB transaction records undergo similar processing to extract `block_timestamp`, `transaction_hash`, and `from_address` fields. The system applies consistent type casting and adds metadata with 'opbnb' as the chain identifier and 'blockchains_l2' as the market sector, while maintaining 'bsc' as the product identifier to associate it with the broader BSC ecosystem. Transaction senders are similarly classified as 'Transaction sender' user types.
- **Key fields**: `block_timestamp` for daily aggregation boundaries, `user_address` (mapped from `from_address`) as the unique identifier, and chain-specific metadata

### Component C: Daily user aggregation
- **Purpose**: Combine both data sources and aggregate unique addresses by day
- **Logic**: The system unions BSC mainnet and OpBNB transaction data with a standardized schema, then truncates `block_timestamp` to daily boundaries using day-level granularity. For each day, it identifies all unique `from_address` values across both chains, treating each sender address as an active user. The aggregation maintains dimensional metadata including chain identifiers, user types, and product classifications to enable multi-dimensional analysis.
- **Key fields**: `timestamp` (truncated to day), `user_dau` (unique address identifier), `chain` for source identification, and categorical dimensions

### Component D: HyperLogLog distinct counting
- **Purpose**: Efficiently calculate distinct user counts across multiple dimensional breakdowns
- **Logic**: The system creates HyperLogLog sketches for each day using `hll_count.init()` with 15-bit precision, allowing for approximate distinct counting that scales efficiently with large datasets. Daily HLL sketches are created for each combination of timestamp, chain, user type, and product. These sketches are then aggregated across different dimensional cuts: overall project level (project_dbt_tag), chain-level breakdowns, user-type segmentation, and product-level analysis. For each dimension, the system merges partial HLL sketches using `hll_count.merge_partial()` and extracts final distinct counts using `hll_count.extract()`.
- **Key fields**: HLL sketches for scalable distinct counting, dimensional grouping fields, and extracted `user_dau` counts for each breakdown

### Final aggregation
- **Combining components**: The various dimensional breakdowns (project, chain, user-type, product) are combined using union operations to create a comprehensive dataset with multiple analytical perspectives. Each breakdown maintains consistent schema with `timestamp`, `dimensions` identifier, and relevant categorical fields.
- **Field transformation**: The final step renames the `user_dau` field to `active_addresses_daily` to reflect the blockchain context where daily active users are equivalent to active addresses that initiated transactions.
- **Time aggregation**: Daily boundaries are maintained throughout the calculation, with timestamp truncation ensuring consistent 24-hour periods. The finalization process includes zero-filling for missing days to maintain complete time series data.
- **Final calculation**: The metric represents the distinct count of unique addresses that sent at least one transaction on either BSC mainnet or OpBNB on a given day, aggregated using HyperLogLog for efficiency and accuracy across multiple dimensional perspectives.

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

Unique active addresses over a fixed 24-hour window.

BNB ChainBNB

Active addresses (daily)

Active addresses (daily)

Competitive landscape

Chain breakdown