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

Venus is a non-custodial lending protocol built on BNB chain. Venus was founded by Joselito Lizarondo and launched in 2020.

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

governance

github

twitter

discord

etherscan

website

Lending

Venus

Venus | Data breakdown

# Venus Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) for Venus protocol measures the number of unique addresses that performed lending operations across all supported chains within a 7-day rolling window. This metric answers the business question: "How many distinct users are actively engaging with Venus lending markets on a weekly basis?" The calculation uses HyperLogLog algorithms to efficiently count distinct users across multiple dimensions while handling the scale of multi-chain DeFi activity.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Venus protocol smart contract events**: Parsed lending events from Venus smart contracts across 8 blockchain networks including BSC, Ethereum, Arbitrum, Base, opBNB, Optimism, Unichain, and zkSync Era
- **Core lending events**: Four primary event types capturing all user interactions - `Borrow`, `Mint` (deposits), `Redeem` (withdrawals), and `RepayBorrow` events
- **Event metadata**: Block timestamps, transaction hashes, contract addresses, and user addresses from blockchain event logs
- **Chain-specific contract data**: Different contract implementations across chains (VBep20Delegate and vBNB on BSC, VToken contracts on other chains)

## 3. Step-by-step calculation

### Component A: User event collection
- **Purpose**: Collects and normalizes all Venus lending activity across supported chains
- **Logic**: Extracts user addresses from four core Venus lending events across 8 blockchain networks. On BSC, events are sourced from VBep20Delegate and vBNB contracts. On other chains (Ethereum, Arbitrum, Base, opBNB, Optimism, Unichain, zkSync Era), events come from VToken contracts. Each event captures the user address, event timestamp, transaction hash, and chain identifier. Users are classified into four types based on their activity: Borrower (from `Borrow` events), Depositor (from `Mint` events), Withdrawer (from `Redeem` events), and Repayer (from `RepayBorrow` events)
- **Key fields**: `user_address` (the wallet performing the action), `block_timestamp` (when the transaction occurred), `chain` (blockchain network), `user_type` (classification based on action), `transaction_hash` (unique transaction identifier)

### Component B: Daily active user aggregation  
- **Purpose**: Aggregates user activity to daily level and prepares data for weekly rolling calculations
- **Logic**: Groups all user events by day using timestamp truncation to daily granularity. Creates distinct user counts per day, chain, user type, and product combination. Transforms daily user sets into HyperLogLog sketches using 15-bit precision to enable efficient distinct counting across large datasets. This intermediate step ensures that each user is counted only once per day regardless of how many transactions they performed
- **Key fields**: `timestamp` (daily truncated date), `user_dau` (distinct user address), `chain` (blockchain identifier), `user_type` (activity classification), `hll` (HyperLogLog sketch of daily users)

### Component C: Rolling window construction
- **Purpose**: Creates 7-day rolling windows to capture weekly active user periods
- **Logic**: Generates a complete date spine covering all days from the earliest data through yesterday. For each day, creates a 7-day lookback window by generating timestamps from 6 days prior through the current day. Cross-joins the date spine with daily HLL data to ensure complete coverage of all time periods. This approach handles missing days and ensures consistent 7-day windows even when some days have no activity
- **Key fields**: `timestamp` (the end date of the 7-day window), `joinday` (each day within the rolling window), `hll` (daily HLL sketches to be merged)

### Component D: Weekly active user calculation
- **Purpose**: Merges daily HLL sketches across 7-day windows to calculate weekly distinct users
- **Logic**: Groups data by the 7-day window end date and dimensional attributes (chain, user type, product). Merges HLL sketches across all days within each window using HLL merge operations. Extracts the final distinct count from the merged HLL sketch to get the weekly active user count. This approach ensures users are counted only once within each 7-day period, regardless of how many days they were active
- **Key fields**: `user_wau` (weekly active user count), `timestamp` (window end date), dimensional breakdowns for analysis

### Component E: Dimensional breakdown
- **Purpose**: Creates multiple analytical views of WAU data across different business dimensions
- **Logic**: Generates four separate breakdowns of the same weekly active user data: project-level aggregation (total across all chains and user types), chain-level breakdown (WAU per blockchain), user-type breakdown (WAU per activity type like Borrower/Depositor), and product-level breakdown (currently null as Venus operates as single product). Each breakdown maintains the same underlying WAU calculation but provides different analytical perspectives by setting some dimensional fields to null
- **Key fields**: `dimensions` (breakdown type identifier), dimension-specific fields (`chain_id`, `user_type`, `product_id`), `user_wau` (weekly active users for each dimension)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive dataset with multiple analytical views in a single table
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily timestamps mark the end of each 7-day rolling window, with monthly partitioning for query performance
- **Final calculation**: The final weekly active user count represents the number of distinct addresses that performed at least one Venus lending operation (borrow, deposit, withdraw, or repay) within any 7-day rolling period, calculated using HyperLogLog algorithms for precise distinct counting across large multi-chain datasets

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

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

VenusXVS

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown