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 Fees Methodology

## 1. Overview

This metric measures the total fees collected by Nexus Mutual from insurance premium payments, representing revenue generated from users purchasing coverage. The calculation aggregates premium payments from both Nexus Mutual v1 and v2 protocols, converts all amounts to USD using appropriate price feeds, and presents daily fee totals. This metric answers the business question: "How much revenue does Nexus Mutual generate from insurance premiums over time?"

## 2. Data sources

The calculation relies on the following data sources:
- **Blockchain events**: Parsed Ethereum `QuotationData_CoverDetailsEvent` events from the Nexus Mutual v1 contract containing premium payment details
- **Transaction data**: Ethereum `Cover_buyCover` function call traces from the Nexus Mutual v2 contract with payment parameters
- **External data**: CoinGecko daily market data API specifically for NXM token price feeds, and Token Terminal's end-of-day price feeds for ETH and DAI tokens
- **Token metadata**: Hardcoded mapping of token IDs to contract addresses for ETH (WETH), DAI, and NXM tokens

## 3. Step-by-step calculation

### Component A: Premium payment extraction
- **Purpose**: Extract all insurance premium payments from both Nexus Mutual protocol versions
- **Logic**: The system processes two distinct data sources. For v1 protocols, it extracts `QuotationData_CoverDetailsEvent` events from Ethereum, filtering for non-removed events and capturing the `curr` field (token ID) and `premium` field (payment amount). For v2 protocols, it processes `Cover_buyCover` function calls, filtering for successful transactions (status = true) and extracting `paymentAsset` (token ID) and `maxPremiumInAsset` (payment amount) from the parameters. All records include transaction hash, block timestamp, and are labeled with business classification as 'Insurance', market sector as 'insurances', and business segment as 'insurance'
- **Key fields**: `curr`/`paymentAsset` for token identification, `premium`/`maxPremiumInAsset` for payment amounts, `block_timestamp` for timing, `transaction_hash` for deduplication

### Component B: Token address resolution
- **Purpose**: Convert numeric token IDs to actual contract addresses for price lookup
- **Logic**: A hardcoded mapping table translates token IDs to Ethereum contract addresses. Token ID '0' and '0x45544800' map to WETH address `0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`, token ID '1' and '0x44414900' map to DAI address `0x6b175474e89094c44da98b954eedeac495271d0f`, and token ID '255' maps to NXM address `0x0d438f3b5175bebc262bf23753c1e53d03432bde`. The premium payment data is joined with this mapping to replace token IDs with contract addresses
- **Key fields**: `token_id` from premiums joined with `token_address` from mapping table

### Component C: Decimal correction and daily aggregation
- **Purpose**: Normalize token amounts and aggregate by day
- **Logic**: Token amounts are adjusted for their respective decimal places using a decimal correction process that accounts for each token's specific decimal configuration. The corrected amounts are then aggregated by day using timestamp truncation, with grouping by all dimensional attributes including chain, business line, market sector, business segment, product ID, version, account name, and token address
- **Key fields**: `amount` values corrected for decimals, `timestamp` truncated to day boundaries

### Component D: USD conversion with dual pathways
- **Purpose**: Convert all fee amounts to USD using appropriate price sources
- **Logic**: The system employs two different USD conversion approaches based on token type. For ETH and DAI denominated fees, it uses Token Terminal's standard end-of-day price feeds through a standard conversion process. For NXM denominated fees, it uses CoinGecko daily market data because internal price feeds are insufficient for this token. The CoinGecko conversion joins daily aggregated NXM fees with CoinGecko's daily timestamp and NXM token ID ('nxm'), multiplying the fee amount by the USD price from CoinGecko
- **Key fields**: `fees` amounts converted to USD, `price_usd` from respective price sources

### Final aggregation
- **Combining components**: The USD-converted fees from both pathways (standard Token Terminal conversion for ETH/DAI and CoinGecko conversion for NXM) are combined using a union operation, maintaining all dimensional attributes
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds, with NXM specifically using CoinGecko prices while other tokens use Token Terminal's internal price feeds
- **Time aggregation**: Daily boundaries are established through timestamp truncation to day level, with all fees aggregated within each day
- **Final calculation**: The metric applies final schema validation, ensures dimensional ID consistency, and fills any missing days with zero values to maintain complete time series continuity. Chain availability filters are applied to ensure data quality across supported networks

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

Total value users pay to use a protocol (gross fees, user-paid fees).

Nexus MutualNXM

Archived

Fees

Fees

Competitive landscape