Arbitrum One batches users' transactions and submits them to Ethereum, paying a share of the transaction fees to Ethereum validators (expense).

Arbitrum One is an L2 smart contract platform for decentralized applications on Ethereum. Arbitrum was founded by Offchain Labs and launched in 2021.

ARB tokenholders own and govern the protocol. They currently run the only sequencer and take a cut of the total transaction fees paid by users (revenue). Arbitrum’s investors include Polychain, Alameda Research, Coinbase Ventures, etc.

github

twitter

discord

etherscan

website

Blockchains (L2)

Arbitrum One

# Arbitrum One Block time Methodology

## 1. Overview

Block time measures the average time interval between consecutive blocks on the Arbitrum blockchain, expressed in milliseconds. This metric indicates the network's block production rate and helps assess blockchain performance and throughput. The calculation determines the time difference between each pair of consecutive blocks, then averages these intervals daily to provide a smoothed measure of network timing consistency.

## 2. Data sources

- **Arbitrum blockchain data**: Raw block header information from the Arbitrum network, containing block timestamps and sequential block numbers
- **Block metadata**: Timestamp data indicating when each block was mined on the Arbitrum blockchain
- **Chain availability data**: Information about Arbitrum network operational status for filtering

## 3. Step-by-step calculation

### Component A: Block data extraction
- **Purpose**: Retrieves basic block information needed for time interval calculations
- **Logic**: Extracts `timestamp` and `number` fields from raw Arbitrum blockchain block data. Block numbers are cast to integers to ensure proper sequential ordering. Only includes blocks with valid timestamps and block numbers.
- **Key fields**: `block_timestamp` (when block was mined), `block_number` (sequential identifier)

### Component B: Consecutive block pairing
- **Purpose**: Creates pairs of consecutive blocks to enable time difference calculations
- **Logic**: Uses a LAG window function ordered by `block_number` to associate each block with the timestamp of the previous block. This creates the necessary pairs for measuring intervals between sequential blocks. Excludes the first block since it has no predecessor.
- **Key fields**: `block_timestamp` (current block time), `previous_timestamp` (previous block time), `block_number` (ordering reference)

### Component C: Block time interval calculation
- **Purpose**: Computes the actual time intervals between consecutive blocks
- **Logic**: Calculates the difference in milliseconds between each block's timestamp and its predecessor's timestamp using timestamp difference functions. Results represent the exact time elapsed between consecutive block productions. Truncates block timestamps to daily boundaries for subsequent aggregation.
- **Key fields**: `block_time` (milliseconds between blocks), `timestamp` (daily boundary)

### Component D: Daily aggregation
- **Purpose**: Aggregates individual block intervals into daily average block times
- **Logic**: Groups all block time intervals by daily timestamp boundaries and calculates the arithmetic mean of block times for each day. Adds standard metadata fields including `chain_id` as 'arbitrum', `market_sector_id` as 'blockchains_l2', and `business_segment_id` as 'blockchain'. Sets `product_id` to null since this is a chain-level metric.
- **Key fields**: `block_time` (average daily milliseconds), `timestamp` (daily boundary), metadata fields for classification

### Final aggregation
- **Combining components**: Daily aggregated block times are processed through a finalization macro that applies standard formatting and validation
- **Currency conversion**: Not applicable for this time-based metric
- **Time aggregation**: Block times are aggregated at daily boundaries, with each day containing the average of all block intervals produced during that 24-hour period
- **Final calculation**: The final metric value represents the mean time in milliseconds between consecutive blocks for each day, providing a daily average block time for the Arbitrum network

The methodology includes incremental loading logic that processes recent data with a configurable lookback period to ensure data freshness while maintaining computational efficiency. Chain availability filters are applied to exclude periods when the network may not have been fully operational.

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

avg(block_timestamp - previous_block_timestamp)

Arbitrum OneARB

Block time

Block time

Competitive landscape

Chain breakdown