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

## 1. Overview

Monthly Active Users (MAU) for Notional protocol measures the number of unique users who interacted with the protocol within any rolling 30-day period. This metric captures both trading activity (lending, borrowing, trading) and liquidity provision activity on the Notional V2 protocol deployed on Ethereum. The calculation uses HyperLogLog data structures to efficiently count unique users across rolling windows while avoiding double-counting users who are active on multiple days within the same 30-day period.

## 2. Data sources

The metric is calculated from the following raw data sources:

- **Ethereum blockchain event logs**: Parsed smart contract events from Notional V2 protocol contracts on Ethereum
- **Trading and lending events**: `LendBorrowTrade_event` logs from Notional's Router contract, containing user addresses, transaction hashes, block timestamps, and trading activity details
- **Liquidity provision events**: `nTokenSupplyChange_event` logs from Notional's Router contract, capturing liquidity provider activities and user addresses
- **Blockchain metadata**: Block timestamps and transaction hashes for temporal ordering and deduplication

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify and classify unique user activities from Notional protocol smart contract events
- **Logic**: Extract user addresses from two specific Ethereum event types. From `LendBorrowTrade_event` logs, extract the `account` field to identify Trader users engaging in lending, borrowing, or trading activities. From `nTokenSupplyChange_event` logs, extract the `account` field to identify Liquidity Provider users who supply or withdraw liquidity. Each event record includes the block timestamp, transaction hash, user address, and activity classification.
- **Key fields**: `account` (user address), `block_timestamp`, `transaction_hash`, user type classification as either "Trader" or "LP"

### Component B: Daily active users calculation  
- **Purpose**: Aggregate user activities into daily unique user counts while preserving dimensional information
- **Logic**: Group all user activities by day using timestamp truncation to day granularity. Take distinct user addresses per day to count Daily Active Users, ensuring each user is counted only once per day regardless of how many transactions they performed. Preserve user type classification, chain information, and other dimensional attributes for downstream analysis.
- **Key fields**: `timestamp` (truncated to day), `user_address`, `user_type`, `chain`, dimensional grouping fields

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user data into efficient probabilistic data structures for unique counting across time windows
- **Logic**: Transform the daily active user data into HyperLogLog sketches using BigQuery's `hll_count.init()` function with 15-bit precision. This creates compact representations of user sets that can be efficiently merged across different time periods without losing accuracy in unique user counting.
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, dimensional grouping fields

### Component D: Rolling window generation
- **Purpose**: Create complete 30-day rolling windows for MAU calculation without gaps in the time series
- **Logic**: Generate a complete datespine covering the full date range from the earliest user activity to the current date. For each day in the datespine, create associations with the previous 29 days to form 30-day rolling windows. This ensures that MAU is calculated consistently even for days with no user activity, and provides complete temporal coverage without missing periods.
- **Key fields**: `timestamp` (current day), `joinday` (each day in the 30-day lookback window)

### Component E: Window-based user aggregation
- **Purpose**: Merge user activity data across rolling 30-day windows to count unique monthly active users
- **Logic**: Join the rolling window structure with the daily HyperLogLog sketches. For each day, collect all HLL sketches from that day and the previous 29 days. Merge these sketches using `hll_count.merge_partial()` to combine user sets while avoiding double-counting users who were active on multiple days within the window. Extract the final unique user count using `hll_count.extract()`.
- **Key fields**: Merged `hll` sketches, `user_mau` (final unique count)

### Component F: Dimensional breakdowns
- **Purpose**: Create multiple views of MAU data across different analytical dimensions
- **Logic**: Generate separate aggregations of the MAU data across four dimensional levels: project-level (overall protocol MAU), chain-level (MAU per blockchain), user_type-level (MAU for Traders vs Liquidity Providers), and product_id-level (MAU per product offering). Each breakdown nullifies non-relevant dimensional fields while preserving the specific dimension being analyzed. Union all dimensional views together to create a comprehensive dataset.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_mau`

### Final aggregation
- **Combining components**: The dimensional breakdowns are combined using UNION ALL operations to create a single comprehensive dataset containing MAU metrics across all analytical dimensions
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows with daily granularity, where each day represents the MAU for that day and the previous 29 days
- **Final calculation**: The final MAU value is the unique count of user addresses who had at least one interaction with Notional protocol within any rolling 30-day period, calculated using HyperLogLog probabilistic counting for efficiency and accuracy

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

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

Notional FinanceNOTE

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown