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

BENQI is a non-custodial lending protocol built on Avalanche. BENQI was founded by an international team of software developers and launched in 2021.

 QI tokenholders own and govern the protocol. They currently take a cut of the total interest paid by borrowers (revenue). BENQI’s investors include Dragonfly Capital, Mechanism Capital, Spartan, etc.

github

twitter

discord

etherscan

website

Lending

BENQI

# BENQI Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for BENQI measures the count of unique user addresses that interact with the BENQI lending protocol within any 7-day rolling window. This metric captures user engagement across lending activities including borrowing, depositing, withdrawing, and repaying on the Avalanche blockchain. The calculation uses HyperLogLog approximation for efficient distinct counting and provides dimensional breakdowns by project, chain, user type, and product.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **BENQI lending protocol events**: Parsed Avalanche blockchain event logs from BENQI v1 smart contracts, specifically `Market_Borrow_event`, `Market_Mint_event`, `Market_Redeem_event`, and `Market_RepayBorrow_event`
- **Blockchain transaction metadata**: Avalanche transaction timestamps, block information, and transaction hashes for contextual data
- **Protocol event parameters**: User addresses extracted from lending event parameters including borrower, minter, redeemer, and payer addresses

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Extract and classify user addresses from BENQI lending protocol interactions
- **Logic**: Parse four types of BENQI lending events on Avalanche blockchain. For `Market_Borrow_event`, extract the borrower address and classify as "Borrower". For `Market_Mint_event`, extract the minter address and classify as "Depositor". For `Market_Redeem_event`, extract the redeemer address and classify as "Withdrawer". For `Market_RepayBorrow_event`, extract the payer address and classify as "Repayer". Each record includes the block timestamp, transaction hash, chain identifier, and user classification
- **Key fields**: `block_timestamp`, `transaction_hash`, `chain`, `user_type`, `user_address` with specific user type mappings for different lending activities

### Component B: Daily active users aggregation  
- **Purpose**: Calculate daily distinct active users with HyperLogLog initialization
- **Logic**: Group user activity by daily timestamp boundaries using timestamp truncation to day level. Create distinct combinations of timestamp, chain, user type, and product identifiers. For each daily group, collect unique user addresses and initialize HyperLogLog sketches for approximate distinct counting with precision parameter 15
- **Key fields**: `timestamp` (daily grain), `timestamp_grain`, `chain`, `user_type`, `product_id`, `user_dau` (distinct user addresses), `hll` (HyperLogLog sketch)

### Component C: Rolling window construction
- **Purpose**: Create 7-day rolling windows for WAU calculation using datespine methodology
- **Logic**: Generate a complete datespine covering the full date range from minimum available data to current date minus one day. For each date in the spine, create join relationships with the previous 6 days (7 days total including current day) using timestamp array generation. This creates a comprehensive mapping where each target date is associated with all dates in its 7-day lookback window
- **Key fields**: `timestamp` (target date), `joinday` (dates within 7-day window for joining)

### Component D: Window aggregation with HyperLogLog merging
- **Purpose**: Aggregate daily HLL sketches across 7-day windows to calculate approximate WAU
- **Logic**: Join the rolling window structure with daily HLL data, matching each window date with corresponding daily HLL sketches. For each 7-day window, merge all available HLL sketches using HyperLogLog merge operations. This provides approximate distinct user counts across the rolling 7-day periods while handling missing days gracefully
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, merged `hll` sketches

### Component E: Dimensional breakdowns
- **Purpose**: Create separate WAU calculations for different analytical dimensions
- **Logic**: Generate four distinct dimensional views of the WAU data. For project-level breakdown, aggregate across all dimensions with nullified chain, product, and user type fields. For chain-level breakdown, group by chain while nullifying other dimensions. For user-type breakdown, group by user type classification. For product-level breakdown, group by product identifier. Each breakdown merges HLL sketches within its respective grouping and extracts final distinct counts
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_wau` (extracted HLL count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, maintaining dimension labels and appropriate null values for non-applicable dimension fields
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundaries with 7-day rolling windows, using complete datespine to ensure no gaps in time series
- **Final calculation**: Extract distinct user counts from merged HyperLogLog sketches using `hll_count.extract()` function, apply finalization macro for standardization and zero-filling of missing periods, resulting in daily WAU values representing unique users active within each 7-day rolling window

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

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

BENQIQI

Active users (weekly)

Active users (weekly)

Competitive landscape