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

ZeroLend is a non-custodial lending protocol built on Ethereum and other adjacent blockchains.

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

github

twitter

discord

website

Lending

ZeroLend

# ZeroLend Active users (weekly) Methodology

## 1. Overview

The ZeroLend Weekly Active Users (WAU) metric measures the number of unique users who interacted with ZeroLend's lending protocol within any 7-day rolling window. This metric captures user engagement across all core lending activities including borrowing, lending, repaying, and flash loans across multiple blockchain networks. The calculation uses HyperLogLog probabilistic counting for efficient computation of unique users across different dimensional breakdowns including project-level, chain-level, user activity type, and product-level views.

## 2. Data sources

The metric relies on the following raw blockchain data sources:
- **ZeroLend smart contract events**: Parsed lending pool contract events from six blockchain networks (Manta, Base, zkSync Era, Blast, Ethereum mainnet, and Linea)
- **Core lending events**: Five primary event types capturing all user lending activities - `Borrow`, `FlashLoan`, `Repay`, `Supply` (deposits), and `Withdraw` events
- **Specialized lending pools**: Ethereum mainnet includes specialized pools for different asset categories (BTC LRT, ETH LRT, RWA Stablecoin pools) and Linea includes multiple named pools (Main, Foxy, Croak pools)
- **Transaction metadata**: Blockchain transaction timestamps, transaction hashes, and block information for temporal attribution

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify and categorize all unique users interacting with ZeroLend lending pools across supported chains
- **Logic**: Parse blockchain events from ZeroLend lending pool smart contracts across six chains. Extract user addresses from five core event types where users are identified through different fields depending on the event - `user` field for most events and `initiator` field for `FlashLoan` events. Categorize users by their activity type: Borrower (for `Borrow` and `FlashLoan` events), Repayer (for `Repay` events), Depositor (for `Supply` events), and Withdrawer (for `Withdraw` events). Each user interaction includes chain identification, market sector classification as lending, and transaction metadata
- **Key fields**: `user_address` (the unique user identifier), `user_type` (activity category), `chain` (blockchain network), `block_timestamp` (transaction timing), `transaction_hash` (transaction identifier)

### Component B: Daily user aggregation
- **Purpose**: Calculate daily unique active users with dimensional grouping for downstream weekly calculations
- **Logic**: Aggregate user interactions by truncating timestamps to daily boundaries. Group users by day, chain, user activity type, market sector, business segment, and product to eliminate duplicate user interactions within the same day. This creates a base dataset of daily unique active users across all relevant dimensions for the weekly rolling window calculation
- **Key fields**: `timestamp` (daily boundary), `timestamp_grain` (set to day), `chain` (blockchain identifier), `user_type` (activity classification), `product_id` (product classification), `user_dau` (unique daily user identifier)

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user counts into efficient probabilistic data structures for approximate unique counting
- **Logic**: Initialize HyperLogLog sketches from the daily unique users grouped by timestamp, chain, user type, and product. Use HLL precision of 15 bits for balance between accuracy and memory efficiency. These sketches enable efficient merging and counting of unique users across multiple days without storing individual user identifiers
- **Key fields**: `hll` (HyperLogLog sketch containing user count estimates), grouped by temporal and dimensional attributes

### Component D: Rolling window construction
- **Purpose**: Create 7-day rolling windows for each date to calculate weekly active user metrics
- **Logic**: Generate a complete datespine covering the full date range from the earliest user activity to the previous day. For each date in the datespine, create an array of seven joindays spanning from six days prior to the current day (inclusive). This creates overlapping 7-day windows that will be used to aggregate weekly users. Join the datespine joindays with the daily HLL sketches to prepare for weekly aggregation
- **Key fields**: `timestamp` (target date for WAU calculation), `joinday` (individual dates within the 7-day window), `hll` (daily user sketches for merging)

### Component E: Weekly user calculation
- **Purpose**: Aggregate unique users across 7-day windows using HyperLogLog merging
- **Logic**: For each target date and dimensional combination, merge HyperLogLog sketches from all seven days in the rolling window. The HLL merge operation efficiently combines daily user sketches to estimate unique users across the entire week, accounting for users who may have been active on multiple days within the window. Extract the final count from the merged HLL sketch to get the weekly active user estimate
- **Key fields**: `user_wau` (estimated weekly active users), `timestamp` (week ending date), dimensional grouping fields

### Component F: Dimensional breakdowns
- **Purpose**: Create multiple dimensional views of weekly active users for different analytical perspectives
- **Logic**: Generate four distinct aggregation levels by grouping the weekly user data differently. Project-level aggregation combines all dimensions for overall protocol WAU. Chain-level aggregation groups by blockchain network. User-type-level aggregation groups by activity classification (Borrower, Repayer, Depositor, Withdrawer). Product-level aggregation groups by product classification. For each breakdown, null out non-relevant dimensional fields and merge HLL sketches accordingly
- **Key fields**: `dimensions` (breakdown type identifier), dimension-specific fields (`chain_id`, `user_type`, `product_id`), `user_wau` (weekly unique user count for each dimensional slice)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set containing project-level, chain-level, user-type-level, and product-level WAU metrics
- **Time aggregation**: Apply daily boundaries with 7-day rolling windows, where each date represents the end of a weekly period
- **Final calculation**: The `finalize_metric_user_wau` macro applies standardized schema formatting, implements zero-filling strategy for missing dates, and adds protocol metadata to create the final weekly active users metric across all specified dimensions

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

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

ZeroLendZERO

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown