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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the average daily revenue generated per active user on the ZeroLend lending protocol. This metric answers the question "How much revenue does each user generate for the protocol on average?" and is calculated by dividing daily protocol revenue by the number of daily active users. ARPU provides insight into user monetization efficiency and protocol revenue density across ZeroLend's multi-chain lending markets.

## 2. Data sources

The calculation relies on several key data sources:

- **Blockchain events**: Parsed lending pool event logs from Ethereum, Blast, Manta, zkSync Era, Base, and Linea blockchains, including `Borrow`, `Supply`, `Withdraw`, `Repay`, and `FlashLoan` events
- **Protocol state data**: ZeroLend lending pool state snapshots containing treasury accrual information and cumulative interest calculations
- **Configuration events**: Reserve factor change events that determine fee distribution between protocol and supply-side participants  
- **Treasury operations**: Treasury mint events that track protocol fee collection from lending pools
- **External data**: End-of-day token price feeds for USD conversion and token metadata for decimal standardization

## 3. Step-by-step calculation

### Component A: Daily active user calculation
- **Purpose**: Count distinct users who performed any lending activity each day
- **Logic**: Extract user addresses from all lending-related events across supported chains. Events include borrowing, supplying, withdrawing, repaying, and flash loan initiation. Users are categorized by activity type (Borrower, Depositor, Withdrawer, Repayer) but counted as a single active user regardless of how many different activities they perform. The system uses HyperLogLog aggregation for efficient distinct counting across multiple dimensions including chain, user type, and product.
- **Key fields**: `user_address` from event logs, `block_timestamp` for daily grouping, `chain` for multi-chain aggregation

### Component B: Interest revenue calculation  
- **Purpose**: Calculate daily protocol revenue from lending interest
- **Logic**: Track cumulative treasury accruals from lending pool state data and combine with treasury mint events to determine total interest earned. Calculate daily interest revenue by taking the difference between consecutive days' cumulative values. Apply reserve factors to determine the protocol's share versus supply-side participants' share. Treasury accruals represent interest accumulated in the protocol's treasury, while treasury mints represent actual fee collection events.
- **Key fields**: `treasury_accruals` from state data, `amount` from mint events, `reserve_factor` from configuration, `token_address` for asset identification

### Component C: Flash loan revenue calculation
- **Purpose**: Calculate protocol revenue from flash loan fees
- **Logic**: Extract flash loan events across all chains and lending pools. Calculate fees by multiplying the flash loan amount by a fixed fee rate of 0.0004 (0.04%). Flash loans are instant borrowing transactions that must be repaid within the same transaction block, generating fees for the protocol.
- **Key fields**: `amount` from flash loan events, fixed fee rate of 0.0004, `token_address` for asset identification

### Final aggregation
- **Combining components**: Sum interest revenue and flash loan revenue for each day and token, then aggregate across all tokens to get total daily protocol revenue in USD
- **Currency conversion**: Convert all revenue amounts to USD using end-of-day price feeds, applying appropriate decimal corrections based on token specifications
- **Time aggregation**: Group all data by day using timestamp truncation, ensuring consistent daily boundaries across all calculations  
- **Final calculation**: Divide total daily revenue (in USD) by the count of daily active users to produce daily ARPU values. Days with zero users result in null ARPU values, while days with zero revenue result in zero ARPU values

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

ZeroLendZERO

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape