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

OP Mainnet is an L2 smart contract platform for decentralized applications on Ethereum. OP Mainnet was founded by Jinglan Wang, Karl Floersch & Kevin Ho and launched in 2021.

Optimism team & investors own and govern the protocol. Optimism’s investors include Paradigm, a16z, IDEO CoLab Ventures, etc.

governance

github

twitter

discord

etherscan

website

Blockchains (L2)

OP Mainnet

# OP Mainnet Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one transaction on the Optimism network within a 30-day rolling window, calculated on a monthly basis. This metric serves as a key indicator of network adoption and user engagement, providing insights into the active user base of the Optimism Layer 2 blockchain. The calculation uses probabilistic counting techniques to efficiently track unique addresses across overlapping monthly periods.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Optimism transaction records**: Complete transaction history from the Optimism blockchain including sender addresses, timestamps, gas usage, and L1/L2 fee information
- **End-of-day token price feeds**: USD conversion rates for reporting currency standardization (applied through schema normalization)
- **Token metadata**: WETH contract address and symbol information for gas fee calculations

## 3. Step-by-step calculation

### Component A: Transaction extraction
- **Purpose**: Extract all Optimism blockchain transactions with sender address information
- **Logic**: Retrieves all transaction records from Optimism blockchain data, capturing the `from_address` as the transaction sender, `block_timestamp` for timing, transaction hashes for uniqueness, and gas-related fields. Each transaction is labeled with the hardcoded WETH token address `0x4200000000000000000000000000000000000006` and assigned to the 'optimism' chain identifier. Gas fees are calculated for both L2 execution costs and L1 data availability costs using the formula: L2 gas fee = (gas_used_amount × gas_price) ÷ 1e18, and L1 gas fee = l1_fee_amount ÷ 1e18
- **Key fields**: `from_address` (transaction sender), `block_timestamp` (transaction time), `transaction_hash` (unique identifier), `gas_used_amount`, `l1_fee_amount`, `gas_price`

### Component B: Daily active user identification  
- **Purpose**: Identify unique transaction senders on a daily basis to create daily active user counts
- **Logic**: Groups transactions by day using timestamp truncation to daily granularity, then identifies distinct sender addresses (`from_address`) for each day. Each unique sender is classified as a 'Transaction sender' user type and associated with blockchain market sector and business segment identifiers. The result is a daily list of unique addresses that initiated transactions, forming the foundation for monthly aggregations
- **Key fields**: `timestamp` (daily granularity), `user_dau` (unique sender address), `user_type` ('Transaction sender'), `chain` ('optimism')

### Component C: Monthly active user aggregation
- **Purpose**: Calculate monthly active users using a 30-day rolling window with efficient deduplication
- **Logic**: Implements HyperLogLog probabilistic counting to track unique users across a rolling 30-day window. First, daily unique users are converted to HyperLogLog sketches using `hll_count.init` with precision 15. A datespine generates all dates from the minimum historical date to yesterday, then creates joinday arrays spanning 30-day periods (current day minus 29 days to current day). For each date, the system joins with all daily HLL sketches in its 30-day window and merges them using `hll_count.merge_partial` to get deduplicated monthly counts. Results are broken down by multiple dimensions: 'chain' level (preserving chain identifier), 'project_dbt_tag' level (aggregating across all chains), 'user_type' level (grouping by user classification), and 'product_id' level (grouping by product classification)
- **Key fields**: `user_mau` (monthly unique user count), `dimensions` (breakdown level), `chain_id`, `user_type`, `product_id`

### Final aggregation
- **Combining components**: The monthly active user counts are directly mapped to active addresses by selecting records where dimensions equal 'chain' or 'project_dbt_tag', and renaming the `user_mau` field to `active_addresses_monthly`. This creates the final metric values at both chain-specific and project-wide levels
- **Currency conversion**: USD conversion and decimal correction are applied through the `finalize_metric_active_addresses_monthly` macro, which standardizes the output schema and applies any necessary currency transformations using end-of-day price feeds
- **Time aggregation**: Monthly boundaries are maintained through the rolling 30-day window approach, where each day represents a distinct monthly active address count based on the trailing 30-day period. Time partitioning is set to monthly granularity for efficient storage and querying
- **Final calculation**: The final monthly active addresses value represents the count of unique addresses that sent at least one transaction within the 30-day period ending on each calculation date, with missing periods filled with zeros and chain availability filters applied to ensure data completeness and accuracy

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

Unique addresses active over a rolling 30-day window.

OP MainnetOP

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown