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 addresses (weekly) Methodology

## 1. Overview

The opBNB weekly active addresses metric measures the number of unique addresses that sent at least one transaction on the opBNB blockchain within a 7-day rolling window. This metric provides insight into user engagement and network activity by tracking distinct wallet addresses that actively participate in network transactions each week. The calculation uses HyperLogLog (HLL) data structures for efficient unique address counting across rolling time windows.

## 2. Data sources

The calculation relies on the following data sources:

- **opBNB transaction records**: Complete transaction history from the opBNB blockchain including transaction hashes, timestamps, and sender addresses
- **Transaction metadata**: Block timestamps for temporal aggregation and sender addresses (`from_address` field) for identifying active users
- **Chain availability data**: Filters and metadata used to determine data availability periods for the opBNB chain
- **Internal data structures**: HyperLogLog data structures for efficient unique address counting across time windows

## 3. Step-by-step calculation

### Component A: User identification and daily aggregation

- **Purpose**: Identify unique transaction senders and aggregate them by day
- **Logic**: Extract all transactions from opBNB blockchain data, focusing on sender addresses (`from_address` field). Each transaction sender is classified as a 'Transaction sender' user type and associated with the 'blockchains_l2' market sector and 'blockchain' business segment. Aggregate unique sender addresses by day using timestamp truncation to day-level granularity, creating daily active user (DAU) records.
- **Key fields**: `block_timestamp` (transaction timing), `from_address` (sender address), `transaction_hash` (transaction identifier), `user_dau` (daily unique addresses)

### Component B: Weekly window creation with datespine

- **Purpose**: Create 7-day rolling windows for weekly active address calculation
- **Logic**: Generate a complete datespine covering all days in the analysis period to ensure no gaps in the time series. For each day, create associations with the previous 6 days to form 7-day rolling windows. Initialize HyperLogLog (HLL) data structures for each day's unique addresses to enable efficient merging across the weekly windows. This approach handles missing days and ensures consistent weekly calculations.
- **Key fields**: `timestamp` (analysis date), `joinday` (days within the 7-day window), `hll` (HyperLogLog structure for unique addresses)

### Component C: Multi-dimensional weekly aggregation

- **Purpose**: Calculate weekly active addresses across different analytical dimensions
- **Logic**: Process the 7-day windows using HyperLogLog merge operations to count unique addresses across each weekly period. Create separate calculations for multiple dimensions: project-level aggregation ('project_dbt_tag'), chain-level aggregation ('chain'), user-type-level aggregation ('user_type'), and product-level aggregation ('product_id'). For each dimension, merge HLL structures across the 7-day windows and extract the final unique address count.
- **Key fields**: `dimensions` (aggregation level), `user_wau` (weekly active addresses), `chain_id` (chain identifier), `user_type` (user classification)

### Final aggregation

- **Combining components**: Select the chain-level and project-level dimensional breakdowns from the weekly active user calculations, renaming `user_wau` to `active_addresses_weekly` to align with the target metric schema
- **Time aggregation**: Use 7-day rolling windows where each day represents the count of unique addresses active in that day plus the previous 6 days, providing a smoothed view of weekly engagement
- **Data quality**: Apply chain availability filters to ensure only data from periods when the opBNB chain was properly operational is included in the final metric
- **Final calculation**: The final weekly active addresses value represents the count of unique sender addresses that executed at least one transaction within each 7-day rolling window, calculated using HyperLogLog for computational efficiency and accuracy

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

Unique active addresses over a rolling 7-day window.

opBNB

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown