Buyers register new domains and renew existing ones for which they pay a fee (revenue).

Ethereum Name Service (ENS) is an extensible naming system built on Ethereum with similar goals to the Domain Name System (DNS). ENS was founded by Nick Johnson and launched in 2017.

ENS token holders own and govern the protocol. They currently take the full share of all registration and renewal fees.

governance

github

twitter

discord

etherscan

website

Infrastructure

Ethereum Name Service

# Ethereum Name Service Active users (monthly) Methodology

## 1. Overview

ENS Monthly Active Users (MAU) measures the number of distinct users who interacted with Ethereum Name Service (ENS) contracts within a rolling 30-day window. This metric tracks user engagement with ENS domain registration and renewal activities, providing insights into the active user base of the ENS protocol. The calculation uses a rolling 30-day window approach with HyperLogLog (HLL) data structures for efficient approximate distinct user counting across multiple dimensional breakdowns.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Ethereum smart contract interactions**: Parsed function calls and events from multiple ENS contract versions including ETHRegistrarControllerV2, ETHRegistrarController, and BaseRegistrarImplementation contracts
- **Function call data**: Successful transaction calls to ENS renewal functions (`renew`) that capture domain renewal activities
- **Event logs**: ENS `NameRegistered` events emitted during new domain registrations
- **Transaction metadata**: Block timestamps and transaction hashes from Ethereum blockchain data to establish timing and transaction context
- **Contract execution status**: Transaction success/failure status to filter only successful interactions

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify and classify ENS user activities from blockchain interactions
- **Logic**: The system extracts user addresses from successful ENS contract interactions on Ethereum. For renewal activities, it captures the `from_address` from successful function calls to `renew` methods across different ENS controller contract versions. For registration activities, it extracts the `owner` parameter from `NameRegistered` events. Each user activity is classified into two types: "Registerer" for users who register new domains and "Renewer" for users who extend existing domain registrations. Only successful transactions are included (where `status` equals true for function calls and `removed` equals false for events)
- **Key fields**: `block_timestamp` for timing, `user_address` for user identification, `user_type` for activity classification, `chain` for blockchain identification, and `transaction_hash` for deduplication

### Component B: Daily active user aggregation
- **Purpose**: Calculate daily distinct active users from the extracted activities
- **Logic**: User activities are aggregated by truncating `block_timestamp` to daily boundaries and counting distinct `user_address` values per day. This creates daily snapshots of unique users who performed ENS activities. The aggregation maintains dimensional attributes including `chain`, `user_type`, and `product_id` for later breakdown analysis. Each day represents a complete set of unique users who interacted with ENS contracts during that 24-hour period
- **Key fields**: `timestamp` (daily boundary), `user_dau` (distinct user address), dimensional grouping fields for breakdowns

### Component C: Rolling window construction
- **Purpose**: Create 30-day rolling windows for MAU calculation
- **Logic**: A datespine is generated covering the full time range from the earliest user activity to the current date minus one day. For each date in the datespine, a 30-day lookback window is created spanning from 29 days prior to the current date. This creates overlapping windows where each day's MAU calculation includes that day plus the previous 29 days. The system uses `generate_timestamp_array` to create consistent daily intervals and joins these with the daily active user data to populate each window with the relevant user activities
- **Key fields**: `timestamp` for window end date, `joinday` for dates within the 30-day window, HLL sketches for efficient distinct counting

### Component D: HyperLogLog aggregation
- **Purpose**: Efficiently count distinct users across 30-day windows without double-counting
- **Logic**: Daily active user data is converted into HyperLogLog (HLL) data structures using `hll_count.init` with 15-bit precision. For each 30-day window, the daily HLL sketches are merged using `hll_count.merge_partial` to combine user counts while avoiding double-counting users who were active on multiple days within the window. The final distinct user count is extracted using `hll_count.extract`. This approach enables memory-efficient approximate counting of distinct users across large time windows and multiple dimensional breakdowns
- **Key fields**: `hll` sketches for approximate distinct counting, merged HLL structures for window-level aggregation

### Component E: Dimensional breakdowns
- **Purpose**: Calculate MAU across different analytical dimensions
- **Logic**: The system generates MAU calculations for four different dimensional breakdowns: project-level (overall ENS MAU), chain-level (by blockchain), user-type-level (Registerer vs Renewer), and product-level (by product classification). Each breakdown groups the 30-day window data by the relevant dimensions and merges the appropriate HLL sketches. Unused dimension fields are set to null using `safe_cast(null as string)` to maintain consistent schema structure. All dimensional breakdowns are combined using `union all` operations to create a unified output table
- **Key fields**: `dimensions` field to identify breakdown type, dimension-specific fields (`chain_id`, `user_type`, `product_id`), `user_mau` for final counts

### Final aggregation
- **Combining components**: The dimensional breakdown results are combined using union operations and processed through the `finalize_metric_user_mau` macro which standardizes the output schema and applies consistent formatting
- **Time aggregation**: Daily boundaries are maintained throughout the calculation with 30-day rolling windows providing the monthly aggregation logic
- **Final calculation**: The final MAU value for each day represents the count of distinct users who were active in ENS within the 30-day period ending on that day, calculated using merged HyperLogLog sketches for approximate but efficient distinct counting across the rolling window

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

Unique revenue-generating users over a rolling 30-day window.

Ethereum Name ServiceENS

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown