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 Transaction count Methodology

## 1. Overview

The opBNB transaction count metric measures the daily number of unique transactions on the opBNB blockchain, broken down by destination contract. This metric provides insights into network activity and usage patterns, with transactions categorized by the type of contract they interact with (labeled vs unlabeled addresses). The calculation aggregates all transactions by day and enriches them with contract metadata to provide context about where transaction activity is occurring.

## 2. Data sources

- **opBNB blockchain transaction records**: Complete transaction data from the opBNB layer-2 blockchain including transaction hashes, sender/receiver addresses, timestamps, and gas usage metrics
- **Account and contract label database**: Token Terminal's curated database of opBNB account labels that provides human-readable names and categorizations for known contracts and accounts
- **Token metadata**: Native BNB token information including the standard contract address (`0x4200000000000000000000000000000000000006`) and symbol for the opBNB network's gas token

## 3. Step-by-step calculation

### Component A: Raw transaction processing
- **Purpose**: Extract and standardize all opBNB transaction records for analysis
- **Logic**: All transactions from the opBNB blockchain are retrieved with their essential fields including block timestamps, transaction hashes, sender addresses (`from_address`), and destination addresses (`to_address`). Gas-related fields such as `gas_used`, `l1_gas_used`, `l1_gas_price`, `l1_fee_scalar`, and `gas_price` are also captured. The native BNB token information is standardized with the contract address `0x4200000000000000000000000000000000000006` and symbol `BNB`. All transactions are associated with the `opbnb` chain identifier.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` as unique identifier, `from_address` and `to_address` for transaction flow, gas metrics for network usage analysis

### Component B: Daily transaction aggregation
- **Purpose**: Count unique daily transactions grouped by destination address
- **Logic**: Transactions are aggregated to daily granularity using timestamp truncation to the day level. For each day and destination address (`to_address`), the count of distinct transaction hashes is calculated to ensure no double-counting of transactions. Each record is tagged with standardized metadata including chain identifier as `opbnb`, market sector as `blockchains_l2`, and business segment as `blockchain`. The `product_id` field is set to null as this metric tracks overall chain activity rather than specific product usage.
- **Key fields**: `timestamp` truncated to daily boundary, `transaction_count` as distinct hash count, `to_address` for destination grouping

### Component C: Contract label enrichment  
- **Purpose**: Enhance transaction counts with human-readable contract names and categories
- **Logic**: The daily transaction counts are left-joined with the account labels dimension using the destination address (`to_address`) as the join key. When a destination address has a corresponding label in the accounts dimension, the `title` field provides the contract name. For addresses without labels in the database, the contract name defaults to `Unlabeled`. This enrichment helps categorize transactions by the type of contract being interacted with.
- **Key fields**: `contract_name` derived from account labels or defaulting to `Unlabeled`, maintaining all transaction count and metadata fields from the aggregation step

### Final aggregation
- **Combining components**: The enriched transaction data flows through the `finalize_metric_transaction_count` macro which standardizes the output schema and validates that all required fields are present
- **Data validation**: The finalization process ensures no gaps in the time series by applying a `fill_zeros` strategy, meaning days with no transactions will still appear in the output with zero counts
- **Quality filtering**: Chain availability filtering is applied to ensure data completeness and quality standards are met before final output
- **Final calculation**: The metric represents the count of distinct transactions per day per destination contract on the opBNB network, with each transaction counted exactly once regardless of its value or gas usage

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

Confirmed transactions added to the blockchain.

opBNB

Transaction count

Transaction count

Competitive landscape

Chain breakdown