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

Base is an Ethereum Layer 2 (L2) offering a secure, low-cost, builder-friendly way for anyone, anywhere, to build onchain.

Coinbase team owns and governs the protocol. Coinbase is a public company and its investors include Andreessen Horowitz, Vanguard Group, ARK Investment Management, etc.

github

twitter

discord

website

Blockchains (L2)

Base

# Base Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that sent at least one transaction on the Base blockchain within a 30-day rolling window. This metric treats each transaction sender (`from_address`) as an active address and uses HyperLogLog probabilistic counting to efficiently calculate distinct addresses across overlapping time periods. The metric answers the business question: "How many unique addresses are actively transacting on Base each month?"

## 2. Data sources

- **Base blockchain transaction records**: Complete transaction data from the Base blockchain including transaction hash, block timestamp, and sender address (`from_address`)
- **Chain availability filters**: Data quality filters that ensure consistent data availability across time periods

## 3. Step-by-step calculation

### Component A: Transaction sender extraction
- **Purpose**: Identify all unique transaction senders from Base blockchain transactions
- **Logic**: Extract the sender address (`from_address`) from each Base blockchain transaction along with the block timestamp and transaction hash. Each sender is classified as a 'Transaction sender' user type and associated with the Base blockchain ('base' chain) and Layer 2 blockchain market sector ('blockchains_l2'). The component includes metadata such as business segment ('blockchain') while leaving product-level identification as null since this is a chain-level metric.
- **Key fields**: `block_timestamp` (when the transaction occurred), `from_address` (the transaction sender address), `transaction_hash` (unique transaction identifier), `chain` (set to 'base'), `user_type` (set to 'Transaction sender')

### Component B: Daily active user calculation  
- **Purpose**: Calculate the number of distinct active addresses per day
- **Logic**: Group all transaction sender records by day using timestamp truncation to day granularity. For each day, count distinct sender addresses (`from_address`) to determine how many unique addresses sent transactions that day. This creates a daily active users (DAU) dataset where each record represents one unique address active on a specific day. The calculation includes chain and user type dimensions for later aggregation flexibility.
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain` (set to 'day'), `user_address` (the unique sender address), `chain`, `user_type`

### Component C: Monthly rolling window creation
- **Purpose**: Create 30-day rolling windows for monthly active address calculations
- **Logic**: Generate a complete datespine covering all dates from the first transaction to the current date. For each date in this datespine, create a 30-day window that includes that date plus the previous 29 days. Use HyperLogLog (HLL) data structures to aggregate daily active users within each rolling window. HLL enables efficient distinct counting across overlapping time periods without double-counting addresses that appear on multiple days within the same 30-day window. Apply HLL initialization on daily user data, then merge HLL sketches across the 30-day windows to get accurate distinct counts.
- **Key fields**: `timestamp` (the end date of each 30-day window), `hll` (HyperLogLog sketch containing distinct addresses), `chain_id`, `user_type`, `product_id`

### Component D: Dimensional breakdowns
- **Purpose**: Calculate monthly active addresses across different dimensional views
- **Logic**: Generate four different dimensional breakdowns of the monthly active address data: 1) Project-level aggregation ('project_dbt_tag') combining all Base data, 2) Chain-level aggregation ('chain') maintaining Base chain identity, 3) User type aggregation ('user_type') preserving the 'Transaction sender' classification, and 4) Product-level aggregation ('product_id') which remains null for blockchain-level metrics. For each breakdown, merge the HLL sketches and extract the final distinct count using HLL extraction functions. Union all dimensional breakdowns into a single result set.
- **Key fields**: `dimensions` (the aggregation level), `user_mau` (extracted distinct count from HLL), `chain_id`, `product_id`, `user_type`

### Final aggregation
- **Combining components**: Select monthly active user data specifically for 'chain' and 'project_dbt_tag' dimensions from the dimensional breakdowns. These represent the primary views needed for the active addresses metric.
- **Currency conversion**: No currency conversion is needed as this metric counts addresses rather than monetary values
- **Time aggregation**: Data is aggregated using 30-day rolling windows, with each date representing the distinct address count for that date and the previous 29 days. Monthly boundaries are handled through rolling windows rather than calendar months.
- **Final calculation**: Rename the `user_mau` field to `active_addresses_monthly` to reflect that this metric represents active addresses rather than users. Apply chain availability filters to ensure data quality and completeness. Fill missing periods with zeros using the finalize metric macro to maintain consistent time series reporting.

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

Unique addresses active over a rolling 30-day window.

Base

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown