Lenders deposit funds into Moonwell and receive interest payments from borrowers (supply-side fees).

Moonwell is a non-custodial lending protocol built on multiple blockchains.

WELL tokenholders own and govern the protocol. They currently take a cut of the total interest + liquidation fees paid by borrowers (revenue).

github

twitter

discord

website

Lending

Moonwell

# Moonwell Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Moonwell measures the number of unique users who interacted with the Moonwell lending protocol over a rolling 30-day period. This metric answers how many distinct users engaged with Moonwell's lending services (borrowing, depositing, withdrawing, or repaying) within any given 30-day window. The calculation uses HyperLogLog probabilistic counting to efficiently aggregate unique users across multiple dimensions while maintaining accuracy for large user sets.

## 2. Data sources

The calculation relies on these underlying data sources:
- **Blockchain events**: Parsed smart contract events from Moonwell's CToken contracts on Base and Optimism networks, specifically `Borrow`, `Mint`, `Redeem`, and `RepayBorrow` events
- **Market contract data**: Moonwell lending market contract addresses and their associated underlying token information
- **Token metadata**: Token symbols, decimals, and identifiers used to enrich market data
- **Transaction data**: Blockchain transaction timestamps and hashes for temporal aggregation
- **Chain availability data**: Network availability filters to ensure data quality across supported chains

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identify all user interactions with Moonwell lending protocols
- **Logic**: Parse specific Compound fork smart contract events from Base and Optimism blockchains. Extract `Borrow` events to identify borrowers, `Mint` events for depositors, `Redeem` events for withdrawers, and `RepayBorrow` events for loan repayers. Filter events to only include those originating from verified Moonwell market contracts. Extract user addresses from event parameters (`borrower`, `minter`, `redeemer`, `payer`) and associate each with the appropriate user type classification.
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` for unique user identification, `user_type` for interaction classification, `chain` for network identification

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily unique active users across all interaction types
- **Logic**: Truncate blockchain event timestamps to daily boundaries to group interactions by calendar day. Deduplicate user addresses within each day to count unique daily active users. Maintain dimensional breakdowns by chain, user type, and product categories. Apply chain availability filtering to exclude periods with incomplete data coverage.
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing unique user addresses, dimensional attributes for segmentation

### Component C: HyperLogLog initialization
- **Purpose**: Prepare efficient unique user counting for rolling window calculations
- **Logic**: Apply HyperLogLog initialization to daily user sets to enable memory-efficient probabilistic counting. HyperLogLog allows accurate estimation of unique users across large datasets while using minimal memory. Initialize HLL structures for each day's user set with precision parameter of 15 bits.
- **Key fields**: `hll` containing HyperLogLog sketches of daily user sets

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for MAU calculation
- **Logic**: Generate a complete datespine covering all days from the earliest available data to the present. For each calendar day, create associations with the previous 29 days to form 30-day windows. Join the datespine with daily HyperLogLog data to ensure complete time coverage without gaps. Apply incremental processing filters to limit historical recalculation scope.
- **Key fields**: `timestamp` for target dates, `joinday` for historical days within each window

### Final aggregation
- **Combining components**: Merge HyperLogLog sketches across each 30-day window using `hll_count.merge_partial()` to combine probabilistic counts while maintaining uniqueness. Extract final unique user counts using `hll_count.extract()` to convert HLL sketches to integer MAU values.
- **Time aggregation**: Calculate MAU for each calendar day based on the preceding 30-day period (including the target day). Handle incremental updates by recalculating recent periods with appropriate safety margins.
- **Dimensional breakdowns**: Generate separate MAU calculations across four dimensions: project-level (overall protocol MAU), chain-level (Base vs Optimism), user type-level (Borrower, Depositor, Withdrawer, Repayer), and product-level segmentation. Combine all dimensional breakdowns using union operations.
- **Final calculation**: Apply standardization macro to ensure consistent schema formatting, fill missing time periods with zero values, and format output according to Token Terminal's metric standards. The final MAU value represents the estimated number of unique users who performed any lending action within the rolling 30-day window ending on each date.

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

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

MoonwellWELL

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown