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 Transactions per second Methodology

## 1. Overview

Transactions per second (TPS) measures the average number of transactions processed per second on the opBNB blockchain over a given day. This metric provides insight into the network's throughput and activity level. The calculation takes the total daily transaction count and divides it by the number of seconds in a day (86,400) to produce an average TPS value.

## 2. Data sources

The calculation relies on two primary data sources:

- **opBNB blockchain transaction records**: Raw transaction data from the opBNB network containing transaction hashes, timestamps, sender and receiver addresses, gas usage information, and other transaction metadata
- **Account labels database**: A curated database of opBNB account addresses with corresponding human-readable labels and titles for contracts and other notable addresses

## 3. Step-by-step calculation

### Component A: Transaction data preparation
- **Purpose**: Clean and standardize raw opBNB transaction data for analysis
- **Logic**: Raw transaction records from the opBNB blockchain are processed to extract and cast relevant fields to appropriate data types. The `block_timestamp` field is converted to a timestamp format, transaction hashes and addresses are cast as strings, and gas-related fields are cast as big numeric values. A hardcoded token address for BNB (`0x4200000000000000000000000000000000000006`) and symbol are added to maintain consistency with the data model.
- **Key fields**: `block_timestamp`, `transaction_hash`, `from_address`, `to_address`, gas usage fields (`gas_used`, `l1_gas_used`, `l1_gas_price`, `l1_fee_scalar`, `gas_price`)

### Component B: Daily transaction counting
- **Purpose**: Aggregate transaction data on a daily basis and count unique transactions
- **Logic**: Transaction timestamps are truncated to day boundaries using timestamp truncation. Transactions are grouped by day, destination address (`to_address`), and various classification fields. For each group, distinct transaction hashes are counted to determine the number of unique transactions. The aggregation includes metadata fields like chain ID (opbnb), market sector (blockchains_l2), and business segment (blockchain) for categorization purposes.
- **Key fields**: Daily aggregated `transaction_count` grouped by `timestamp`, `to_address`, and classification dimensions

### Component C: Account label enrichment
- **Purpose**: Add human-readable labels to identify transaction destinations
- **Logic**: The daily transaction counts are joined with the account labels dimension table using the destination address (`to_address`) as the join key. This enrichment adds contract names and titles where available. Addresses without labels are marked as "Unlabeled" to ensure complete data coverage.
- **Key fields**: `contract_name` (derived from account labels), maintaining all existing transaction count and metadata fields

### Component D: Data finalization and quality assurance
- **Purpose**: Apply data quality checks, schema validation, and gap filling
- **Logic**: The enriched transaction data is processed through a finalization macro that ensures data completeness, validates identifier fields, and fills any gaps in the time series. The fill strategy uses zeros for missing periods, ensuring continuous daily coverage. Chain availability filters are also applied to ensure data consistency.
- **Key fields**: All fields from previous steps, with quality assurance and gap filling applied

### Final aggregation
- **Combining components**: The daily transaction counts from the finalized transaction count model are grouped by timestamp, timestamp grain, product ID, and chain ID, with transaction counts summed across all destination addresses for each day
- **Currency conversion**: No currency conversion is required as this metric measures transaction volume rather than monetary value
- **Time aggregation**: Data is aggregated at daily boundaries, with each day representing a complete 24-hour period
- **Final calculation**: Transactions per second is calculated by dividing the sum of daily transaction counts by the number of seconds in a day (86,400). Safe division is used to handle potential division by zero scenarios gracefully, ensuring robust calculation even with edge cases

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

Average confirmed user transactions added per second.

opBNB

Transactions per second

Transactions per second

Competitive landscape

Chain breakdown