Risk accessors providers deposit funds into Nexus Mutual and receive insurance premiums from policyholders (currently as token incentives).

Nexus Mutual is a non-custodial insurance protocol built on Ethereum. Nexus Mutual was founded by Hugh Karp and launched in 2017.

NXM tokenholders own and govern the protocol. They currently take all of the total insurance premiums paid by policyholders (revenue). Nexus Mutual's investors include KR1, Kenetic, Version One Ventures, etc.

governance

github

twitter

discord

etherscan

website

Insurance

Nexus Mutual

# Nexus Mutual Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Nexus Mutual measures the number of unique users who interacted with the Nexus Mutual insurance protocol within a trailing 30-day period. This metric answers the business question "How many distinct users were active in the past month?" and is calculated using a rolling 30-day window approach with HyperLogLog sketches for efficient approximate distinct counting. The calculation starts from individual blockchain events, aggregates to daily active users, then uses rolling windows to compute monthly active users across multiple dimensional breakdowns.

## 2. Data sources

- **Ethereum blockchain event logs**: Raw event logs from Ethereum blockchain containing smart contract interactions
- **Nexus Mutual Cover contract events**: Specifically the `Cover_CoverEdited` events from Nexus Mutual's v1 Cover smart contract on Ethereum
- **Transaction records**: Ethereum transaction hashes and log indexes for unique event identification  
- **Block timestamp data**: Ethereum block timestamps for temporal aggregation and time-based filtering
- **Smart contract parameters**: Event parameters including `buyer` addresses that identify insurance cover purchasers

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identifies and extracts user addresses from Nexus Mutual protocol interactions
- **Logic**: Parses Ethereum `Cover_CoverEdited` events from the Nexus Mutual v1 Cover smart contract. Extracts the `buyer` parameter which contains the address of users who edited their insurance covers. Each interaction is classified with user_type as 'Cover buyer', market_sector_id as 'insurances', and business_segment_id as 'insurance'. Events are tagged with chain identifier 'ethereum' and include transaction metadata like `transaction_hash`, `log_index`, and `block_timestamp`
- **Key fields**: `buyer` (user address), `block_timestamp` (event timing), `transaction_hash` (transaction identifier), `log_index` (event position), `user_type` (always 'Cover buyer')

### Component B: Daily active user calculation  
- **Purpose**: Aggregates user interactions into daily distinct active user counts
- **Logic**: Takes the user interactions and truncates `block_timestamp` to day granularity. Groups data by timestamp, chain, `user_type`, and `product_id`, then counts distinct `user_address` values for each day. This creates a time series of daily active users with dimensional breakdowns. Applies chain availability filtering to ensure data quality
- **Key fields**: `timestamp` (day-truncated), `timestamp_grain` ('day'), `chain`, `user_type`, `product_id`, `user_dau` (distinct user address)

### Component C: HyperLogLog sketch preparation
- **Purpose**: Converts daily active user data into HyperLogLog sketches for efficient distinct counting
- **Logic**: Transforms the daily active user data by initializing HyperLogLog sketches with precision 15 for each day's user set. Groups by timestamp, `timestamp_grain`, `chain_id`, `user_type`, and `product_id`. The HLL sketches enable approximate distinct counting that can be efficiently merged across time windows
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component D: Time window construction
- **Purpose**: Creates 30-day rolling windows for MAU calculation
- **Logic**: Generates a complete datespine covering all days from the minimum timestamp in the DAU data to yesterday. For each day in the datespine, creates a 30-day window by joining with the previous 29 days plus the current day using `joinday` logic. This ensures consistent 30-day trailing windows even for days with no activity
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 30-day window)

### Component E: MAU window aggregation
- **Purpose**: Merges HLL sketches within each 30-day window to calculate monthly active users
- **Logic**: Joins the time windows with the HLL sketch data, matching each `joinday` with its corresponding daily HLL sketch. For each target timestamp, collects all HLL sketches from its 30-day window. Groups by timestamp, `timestamp_grain`, `chain_id`, `user_type`, and `product_id`
- **Key fields**: `timestamp` (target date), dimensional fields, `hll` (daily sketches within window)

### Component F: Dimensional breakdowns
- **Purpose**: Creates MAU calculations across different analytical dimensions
- **Logic**: Generates four separate dimensional views. Project-level aggregation merges all HLL sketches regardless of chain, user type, or product. Chain-level aggregation groups by chain while nullifying other dimensions. User-type-level aggregation groups by `user_type` while nullifying chain and product dimensions. Product-level aggregation groups by `product_id` while nullifying other dimensions. Each breakdown uses `hll_count.merge_partial()` to combine sketches and `hll_count.extract()` to get final distinct counts
- **Key fields**: `timestamp`, `dimensions` (breakdown type), dimension-specific fields, `user_mau` (extracted distinct count)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a unified result set with different analytical views
- **Currency conversion**: No currency conversion required as this is a count-based metric
- **Time aggregation**: Uses daily boundaries with 30-day trailing windows. Each day's MAU represents unique users active in the 30-day period ending on that day
- **Final calculation**: The metric value is the HyperLogLog-approximated count of distinct user addresses that appeared in any daily active user calculation within the trailing 30-day period, segmented by various dimensional breakdowns (project-level, chain-level, user-type-level, product-level)

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

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

Nexus MutualNXM

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape