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

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one transaction on Arbitrum within a rolling 30-day period. This metric provides insight into user engagement and adoption by tracking how many distinct addresses are actively using the Arbitrum network each month. The calculation uses a rolling 30-day window approach, where each day's value represents the count of unique addresses that sent transactions during the current day and the previous 29 days.

## 2. Data sources

The calculation relies on these core data sources:
- **Arbitrum transaction records**: Complete transaction history from the Arbitrum blockchain containing transaction metadata, sender addresses, recipient addresses, gas usage, and timestamp information
- **Generated timestamp data**: Daily timestamps created through datespine generation to ensure complete temporal coverage for rolling window calculations

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize Arbitrum transaction data for analysis
- **Logic**: Retrieve all transactions from Arbitrum blockchain records, extracting key fields including block timestamp, transaction hash, sender address (`from_address`), recipient address (`to_address`), gas price, and gas usage. The system assigns standard categorization labels including market sector as `blockchains_l2`, business segment as `blockchain`, and hardcodes the Arbitrum WETH token address. Each transaction is classified with user type as `Transaction sender` to indicate the address initiated the transaction.
- **Key fields**: `block_timestamp` for timing, `from_address` as the unique identifier for active addresses, `transaction_hash` for deduplication, gas-related fields for fee calculations

### Component B: Daily active user identification  
- **Purpose**: Identify unique addresses that sent transactions each day
- **Logic**: Group transactions by day using timestamp truncation to daily boundaries, then extract distinct sender addresses (`from_address`) for each day. Each unique address that initiates at least one transaction on a given day qualifies as a daily active user. The system maintains dimensional attributes including chain identifier, user type classification, and product categorization for downstream analysis.
- **Key fields**: `timestamp` truncated to day grain, `from_address` as the unique user identifier, `user_type` set to `Transaction sender`, `chain` for network identification

### Component C: HyperLogLog sketch generation
- **Purpose**: Create probabilistic data structures for efficient unique address counting across time windows
- **Logic**: Convert daily active user lists into HyperLogLog (HLL) sketches using a precision parameter of 15 bits. HLL sketches enable memory-efficient approximate counting of unique elements when merging across multiple time periods. Each daily dataset generates one HLL sketch containing all unique addresses active that day, grouped by dimensional breakdowns including chain, user type, and product identifiers.
- **Key fields**: `hll` sketch containing unique address estimates, `timestamp` for temporal alignment, dimensional grouping fields for analysis breakdowns

### Component D: Rolling window datespine creation
- **Purpose**: Generate complete daily timestamp coverage for 30-day rolling window calculations
- **Logic**: Create a datespine spanning from the earliest available transaction date to one day before the current timestamp. For each day in this range, generate an array of 30 timestamps representing the current day and previous 29 days. This ensures every day has a complete 30-day lookback window even when some historical days have no transaction activity. The datespine prevents gaps in the rolling calculation that could occur from missing data.
- **Key fields**: `timestamp` for the calculation date, `joinday` representing each day within the 30-day lookback window

### Component E: Monthly active user calculation
- **Purpose**: Calculate unique address counts over rolling 30-day periods using HLL sketch merging
- **Logic**: Join the datespine with daily HLL sketches to create 30-day windows for each date. For each calculation date, retrieve HLL sketches from the current day and previous 29 days, then merge these sketches using HLL aggregation functions. Extract the final unique count estimate from the merged sketch, producing the number of distinct addresses active within each 30-day rolling period. This approach maintains accuracy while handling the computational complexity of counting unique elements across sliding time windows.
- **Key fields**: `user_mau` containing the unique address count, `timestamp` for the calculation date, dimensional breakdown fields

### Component F: Dimensional breakdowns
- **Purpose**: Generate monthly active user counts across different analytical dimensions
- **Logic**: Create separate aggregations for different analysis levels including project-level totals (`project_dbt_tag`), chain-level counts, user type categories, and product classifications. Each dimensional breakdown merges HLL sketches across the appropriate grouping fields while nullifying non-relevant dimensions. Project-level aggregation provides overall Arbitrum network activity, chain-level maintains network identification, user type preserves transaction sender classification, and product-level enables feature-specific analysis.
- **Key fields**: `dimensions` indicating the breakdown level, `user_mau` with unique counts, relevant dimension identifiers with non-applicable fields set to null

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single dataset containing monthly active user counts across project, chain, user type, and product dimensions. Apply the `finalize_metric_user_mau` macro to standardize schema, handle missing periods with zero-filling strategy, and ensure consistent formatting.
- **Currency conversion**: Not applicable for this metric as it counts addresses rather than monetary values
- **Time aggregation**: Uses rolling 30-day windows calculated daily, where each date represents unique addresses active during that day plus the previous 29 days
- **Final calculation**: Rename `user_mau` field to `active_addresses_monthly` and filter results to include only chain-level and project-level dimensional breakdowns. Apply chain availability filters to ensure data quality and completeness for the final metric output.

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

Unique addresses active over a rolling 30-day window.

Arbitrum OneARB

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown