Liquidity providers deposit funds into Notional and receive trading fees from borrowers & lenders (supply-side fees).

Notional is a non-custodial fixed-rate, fixed-term lending protocol built on Ethereum. Notional was founded by Jeff Wu & Teddy Woodward and launched in 2020.

NOTE holders own and govern the protocol. They currently take a cut of the total trading fees paid by borrowers & lenders and all of the COMP incentives from funds deposited to Compound (revenue). Notional’s investors include Coinbase Ventures, Nascent Ventures, 1Confirmation, etc.

github

twitter

discord

etherscan

website

Lending

Notional Finance

# Notional Finance Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with the Notional protocol within any 7-day period. This metric uses a rolling 7-day window approach with HyperLogLog probabilistic counting to efficiently handle large-scale user deduplication across multiple days. The calculation identifies users from lending, borrowing, trading, and liquidity provision activities on the Notional V2 protocol on Ethereum.

## 2. Data sources

- **Ethereum event logs**: Parsed `Router_LendBorrowTrade_event` logs from Notional V2 protocol contracts, capturing lending, borrowing, and trading activities
- **Ethereum event logs**: Parsed `Router_nTokenSupplyChange_event` logs from Notional V2 protocol contracts, capturing nToken liquidity provision activities  
- **Blockchain transaction data**: Ethereum transaction records providing block timestamps for activity timing
- **Protocol metadata**: Notional V2 contract addresses and event schemas for proper event identification

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identifies and classifies user activities from Notional protocol events on Ethereum
- **Logic**: Extracts user addresses from two primary event types. `Router_LendBorrowTrade_event` logs capture lending, borrowing, and trading activities, with the `account` field identifying users classified as 'Trader' type. `Router_nTokenSupplyChange_event` logs capture nToken supply changes for liquidity provision, with the `account` field identifying users classified as 'LP' type. Each activity record includes the user address, block timestamp, transaction hash, and user type classification
- **Key fields**: `account` (user address), `block_timestamp`, `transaction_hash`, user classification as either 'Trader' or 'LP'

### Component B: Daily active user aggregation  
- **Purpose**: Creates daily snapshots of unique active users with proper deduplication
- **Logic**: Groups user activities by truncating block timestamps to day-level granularity. Deduplicates user addresses within each day to ensure each user is counted only once per day, regardless of how many transactions they performed. Maintains dimensional attributes including chain identifier, user type classification, and other metadata for downstream analysis
- **Key fields**: `timestamp` (day-level), `user_address`, `user_type`, `chain`, `product_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Converts daily user lists into probabilistic data structures for efficient weekly aggregation
- **Logic**: Transforms daily active user lists into HyperLogLog sketches using 15-bit precision. This probabilistic counting approach enables efficient merging of user sets across multiple days while maintaining reasonable accuracy for unique count estimation. Each daily user set becomes an HLL sketch that can be mathematically combined with other sketches
- **Key fields**: HLL sketches with 15-bit precision containing compressed user set information

### Component D: Rolling window construction
- **Purpose**: Creates 7-day rolling windows to capture weekly activity periods
- **Logic**: Generates a complete datespine covering the entire analysis period to ensure no missing dates. For each day, creates a 7-day window including the current day plus the 6 preceding days. Uses a cross-join approach with the datespine to ensure every day has a complete 7-day lookback window, even when some days had no activity
- **Key fields**: `timestamp` (target date), `joinday` (each of the 7 days in the window)

### Component E: HLL sketch merging and WAU calculation
- **Purpose**: Combines daily user sketches across 7-day windows to calculate unique weekly active users
- **Logic**: For each 7-day window, merges the HLL sketches from all 7 days using `hll_count.merge_partial()` function. This mathematical operation combines the probabilistic user sets while maintaining uniqueness constraints. Extracts the final unique user count from the merged sketch using `hll_count.extract()`. The result represents the estimated number of unique users who were active at least once during the 7-day period
- **Key fields**: Merged HLL sketches, extracted `user_wau` counts

### Final aggregation
- **Combining components**: Creates multiple dimensional views of the WAU metric by grouping the merged HLL data across different dimensions including project-level totals, chain-level breakdowns, user type segmentation, and product-level analysis
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses daily granularity with 7-day rolling windows, where each day represents the WAU for that day's 7-day lookback period
- **Final calculation**: The final WAU value for any given day represents the unique count of users who had at least one transaction with the Notional protocol during that day and the 6 preceding days, calculated using probabilistic HyperLogLog sketch merging for scalable deduplication

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

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

Notional FinanceNOTE

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown