opBNB is built on the OP Stack, the same underlying framework as Optimism. It extends the Ethereum Virtual Machine (EVM) to provide faster and cheaper transactions, while leveraging BNB Smart Chain (BSC) for ecosystem integration.

opBNB is an Ethereum-compatible Layer 2 scaling solution designed to improve the performance and affordability of decentralized applications on BNB Chain. It provides high throughput and low fees, making it suitable for gaming, social, and DeFi applications.

opBNB is developed by BNB Chain, which is supported by contributors from the broader Binance ecosystem.

twitter

etherscan

website

Blockchains (L2)

opBNB

# opBNB Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who performed at least one transaction on the opBNB blockchain within any 7-day rolling window. This metric provides insight into user engagement and adoption patterns on the opBNB Layer 2 network. The calculation uses HyperLogLog (HLL) approximation techniques to efficiently handle large-scale distinct user counting across rolling time windows.

## 2. Data sources

- **opBNB blockchain transactions**: Raw transaction records from the opBNB Layer 2 blockchain containing sender addresses, timestamps, and transaction metadata
- **Transaction sender addresses**: Unique wallet addresses that initiated transactions on the opBNB network
- **Block timestamps**: Precise timing information for when transactions were included in opBNB blocks
- **Transaction metadata**: Additional context including transaction hashes for traceability

## 3. Step-by-step calculation

### Component A: Daily user extraction
- **Purpose**: Identify unique users who transacted each day on opBNB
- **Logic**: Extract all transaction records from opBNB blockchain data and identify unique sender addresses (`from_address`) for each day. Transactions are grouped by truncating `block_timestamp` to daily granularity. Each unique sender address represents a distinct active user for that day. All users are classified as 'Transaction sender' user type since the metric focuses on transaction activity.
- **Key fields**: `block_timestamp` truncated to day, `from_address` as user identifier, `chain` set to 'opbnb'

### Component B: HyperLogLog sketch creation  
- **Purpose**: Convert daily user sets into efficient data structures for rolling window calculations
- **Logic**: Transform the daily unique user sets into HyperLogLog sketches using BigQuery's `hll_count.init()` function with precision parameter 15. HLL sketches allow approximate distinct counting with high accuracy while using minimal storage space, essential for efficiently merging user sets across multiple days in rolling windows.
- **Key fields**: `hll` sketches containing compressed user address sets, grouped by `timestamp`, `chain_id`, `user_type`, and `product_id`

### Component C: Date spine and rolling window construction
- **Purpose**: Create complete time series and define 7-day rolling windows
- **Logic**: Generate a continuous date spine from the earliest available data through the current date to ensure no missing time periods. For each date in the spine, create a 7-day rolling window by joining with the 6 preceding days plus the current day. This creates a `jointables` structure that maps each target date to its constituent 7-day period, enabling proper window-based aggregation.
- **Key fields**: `timestamp` for target date, `joinday` for each day within the 7-day window

### Component D: HLL sketch merging across windows
- **Purpose**: Combine daily user sketches within each 7-day window
- **Logic**: Join the rolling window structure with daily HLL sketches, then merge sketches across each 7-day period using `hll_count.merge_partial()`. This combines the approximate user sets from all 7 days while maintaining the distinct user property. Extract the final distinct count using `hll_count.extract()` to get the approximate number of unique users active within each 7-day window.
- **Key fields**: Merged `hll` sketches, `user_wau` containing the final distinct user count

### Component E: Multi-dimensional breakdowns
- **Purpose**: Calculate WAU across different analytical dimensions
- **Logic**: Create separate aggregations for different business dimensions: project-level (all opBNB activity), chain-level (opBNB chain specifically), user-type level (transaction senders), and product-level (currently null for opBNB). Each breakdown groups the windowed data by its respective dimensions while setting non-relevant dimension fields to null. All breakdowns are combined using union operations to create a unified result set.
- **Key fields**: `dimensions` indicating breakdown type, dimension-specific fields (`chain_id`, `product_id`, `user_type`), `user_wau` metric values

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set with standardized schema structure
- **Schema standardization**: Apply the `finalize_metric_user_wau` macro to ensure consistent field names, data types, and metadata across all breakdown dimensions
- **Missing period handling**: Fill any gaps in the time series with zero values to maintain complete historical continuity
- **Final calculation**: Each row contains a `user_wau` value representing the approximate count of unique users who were active within the 7-day rolling window ending on that date, broken down by the specified dimension

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

Unique revenue-generating users over a rolling 7-day window.

opBNB

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown