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 (weekly) Methodology

## 1. Overview

ENS Weekly Active Users (WAU) measures the number of distinct users who interact with Ethereum Name Service (ENS) contracts within any 7-day rolling window. This metric captures users performing domain registration and renewal activities on the ENS protocol. The calculation uses HyperLogLog data structures to efficiently count distinct users across rolling time windows, providing accurate estimates of weekly user engagement while minimizing computational overhead.

## 2. Data sources

The ENS WAU calculation uses the following blockchain data sources:

- **ENS smart contract function calls**: Ethereum transaction records containing calls to ENS controller contract functions, specifically domain renewal operations across multiple contract versions
- **ENS smart contract events**: Parsed Ethereum event logs from ENS controller contracts, particularly `NameRegistered` events that capture new domain registrations  
- **Transaction metadata**: Ethereum transaction details including `block_timestamp` for temporal aggregation, `transaction_hash` for deduplication, and `status`/`removed` flags for filtering valid operations
- **Contract-specific data**: Function call parameters and event parameters that identify user addresses (`from_address`, `owner` fields) and transaction outcomes

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Extract and classify all ENS user interactions from blockchain transactions
- **Logic**: The system processes Ethereum transactions involving ENS smart contracts, extracting user addresses from both function calls and events. For renewal activities, it captures the `from_address` from function calls to `ETHRegistrarControllerV2_renew_function`, `ETHRegistrarController_renew_function`, and `BaseRegistrarImplementation_renew_function` contracts. For registration activities, it extracts the `owner` parameter from `NameRegistered` events emitted by `ETHRegistrarControllerV2` and `ETHRegistrarController` contracts. The system filters for successful transactions where `status` equals true for function calls and `removed` equals false for events.
- **Key fields**: `block_timestamp` for temporal grouping, `user_address` for distinct counting, `user_type` classification as either "Renewer" or "Registerer", `chain` identifier (Ethereum), and transaction validation flags

### Component B: Daily active user aggregation  
- **Purpose**: Aggregate user interactions to daily distinct active user counts
- **Logic**: User interactions are grouped by day using `timestamp_trunc` on `block_timestamp` to create daily boundaries. The system counts distinct `user_address` values for each day, preserving dimensional breakdowns by `chain`, `user_type`, and `product_id`. Each day's result includes the timestamp truncated to day granularity, dimension values, and the set of unique user addresses that were active on that day.
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing the distinct user address, dimension fields for later aggregation

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user sets into memory-efficient HyperLogLog data structures for subsequent set operations
- **Logic**: For each day's user set, the system creates a HyperLogLog sketch using `hll_count.init` with precision parameter 15. This transforms the exact set of user addresses into a probabilistic data structure that enables efficient union operations across multiple days while maintaining accurate distinct count estimates. The sketches are grouped by timestamp, chain, user type, and product dimensions.
- **Key fields**: `hll` sketch containing the compressed user set representation, dimensional grouping fields maintained from the daily aggregation

### Component D: Rolling window generation
- **Purpose**: Create 7-day rolling windows for each day to capture weekly active user periods
- **Logic**: The system generates a complete datespine covering all days from the earliest ENS data through yesterday to ensure no gaps in the time series. For each day in the datespine, it creates a 7-day window by generating timestamps for the target day and the previous 6 days using `generate_timestamp_array` with 1-day intervals. This creates joinday records that map each target day to all days in its 7-day window, enabling the rolling window calculation.
- **Key fields**: `timestamp` for the target day, `joinday` for each day within the 7-day window leading up to the target day

### Component E: Weekly active user calculation
- **Purpose**: Merge daily HyperLogLog sketches across 7-day windows to calculate distinct weekly active users
- **Logic**: The rolling window timestamps are joined with the daily HLL sketches, matching each `joinday` to its corresponding daily user sketch. For each target day, this creates up to 7 HLL sketches representing the users active on each day of the 7-day window. The system then uses `hll_count.merge_partial` to union all sketches within each window, combining the user sets while maintaining distinctness. Finally, `hll_count.extract` converts the merged sketch back to a distinct count, producing the weekly active user total for each window.
- **Key fields**: `user_wau` containing the final distinct user count for the 7-day window, dimensional fields preserved from daily aggregation

### Component F: Dimensional aggregation
- **Purpose**: Generate WAU breakdowns across multiple analytical dimensions
- **Logic**: The weekly user data is aggregated across four dimensional views. The project-level aggregation sums users across all chains and user types. The chain-level aggregation preserves `chain_id` while summing across user types. The user-type aggregation preserves `user_type` classification while summing across chains. The product-level aggregation preserves `product_id` while summing across other dimensions. Each aggregation maintains the HyperLogLog merging approach to preserve distinct counting accuracy across dimensional boundaries.
- **Key fields**: `dimensions` field indicating the aggregation level, dimension-specific fields (`chain_id`, `user_type`, `product_id`), aggregated `user_wau` counts

### Final aggregation
- **Combining components**: The four dimensional aggregations are combined using union operations, creating a unified dataset with multiple analytical perspectives of the same underlying weekly active user data
- **Currency conversion**: Not applicable - this is a user count metric without monetary values
- **Time aggregation**: Data is aggregated to daily grain with each record representing a 7-day rolling window ending on that day. The rolling window approach means each day's WAU includes users active on that day or any of the previous 6 days
- **Final calculation**: The final WAU value represents the distinct count of user addresses that performed ENS registration or renewal activities within the 7-day rolling window, calculated using HyperLogLog sketch merging to maintain accuracy while enabling efficient computation across large user sets

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

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

Ethereum Name ServiceENS

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown