Overcollateralized borrowers deposit funds into Lybra Finance and receive eUSD and peUSD stablecoins.

Lybra Finance is a non-custodial stablecoin protocol built on Ethereum. Lybra Finance was founded by a an anonymous team and launched in May 2023.

LBR tokenholders own & govern the protocol. They currently take all of the total fees paid by borrowers (revenue). Lybra Finance launched with a public presale.

governance

github

twitter

discord

etherscan

website

Stablecoin issuers

Lybra Finance

# Lybra Finance Active users (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of unique users who interacted with Lybra protocol within any 7-day rolling window. This metric answers how many distinct users are actively borrowing or repaying stablecoins using Lybra's collateralized debt position (CDP) vaults over a weekly timeframe. The calculation uses HyperLogLog probabilistic data structures to efficiently count unique users across rolling windows, with breakdowns by project level, blockchain, user activity type, and product.

## 2. Data sources

- **Blockchain events**: Parsed `Mint` and `Burn` events from Lybra V1 and V2 vault contracts on Ethereum, including eUSD vault events and various collateral-specific vault events (RETH, WBETH, StETH, WstETH)
- **Event parameters**: The `onBehalfOf` parameter from vault events which identifies the user address performing the borrowing or repayment action
- **Transaction metadata**: Block timestamps and transaction identifiers from Ethereum blockchain data

## 3. Step-by-step calculation

### Component A: User interaction extraction
- **Purpose**: Identify all user interactions with Lybra protocol vaults
- **Logic**: Extract events from Lybra V1 and V2 vault contracts on Ethereum. For each vault type (eUSD, RETH, WBETH, StETH, WstETH), capture both `Mint` events (representing borrowing activity) and `Burn` events (representing repayment activity). The `onBehalfOf` parameter identifies the actual user performing the action. Users are classified as "Borrower" for mint events and "Repayer" for burn events. All interactions are tagged with chain identifier, market sector as "stablecoin_issuers", and business segment as "stablecoin_issuer"
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `onBehalfOf` (renamed to `user_address`), `user_type`

### Component B: Daily active user aggregation  
- **Purpose**: Convert raw events into daily unique user counts
- **Logic**: Group user interactions by day using timestamp truncation to daily granularity. For each day, count distinct user addresses to get true daily active users, avoiding double-counting users who performed multiple actions on the same day. Preserve user type classification, chain information, and other dimensional attributes. This creates the foundational daily user data needed for rolling window calculations
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain` (set to "day"), `chain`, `user_type`, `product_id`, `user_dau` (distinct user address)

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user counts to memory-efficient probabilistic data structures
- **Logic**: Transform daily active user data into HyperLogLog structures with 15-bit precision using `hll_count.init()`. This probabilistic approach enables efficient unique user counting across large datasets and time windows. Group by timestamp, chain, user type, and product dimensions to maintain proper granularity for downstream calculations
- **Key fields**: `hll` (HyperLogLog structure), dimensional grouping fields

### Component D: Rolling window creation
- **Purpose**: Generate 7-day rolling windows for weekly calculations
- **Logic**: Create a complete datespine covering all days from the earliest user activity to the current date to ensure no gaps in the time series. For each day in the datespine, generate a 7-day window by joining with the current day and the preceding 6 days using `generate_timestamp_array()`. This creates a comprehensive set of 7-day windows where each day appears in multiple overlapping windows
- **Key fields**: `timestamp` (end date of window), `joinday` (individual days within each window)

### Component E: Window-based user aggregation
- **Purpose**: Merge HyperLogLog structures across 7-day windows
- **Logic**: Join the rolling window structure with the daily HLL data to collect all user activity within each 7-day period. For each window, merge the HyperLogLog structures from all 7 days using `hll_count.merge_partial()` to accurately count unique users across the entire window period. This handles users who were active on multiple days within the same week by counting them only once
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, merged `hll` structures

### Component F: Dimensional breakdowns
- **Purpose**: Calculate WAU across different analytical dimensions
- **Logic**: Create four separate views of the weekly active user data. Project-level breakdown aggregates all activity without dimensional filters. Chain-level breakdown groups by blockchain. User-type breakdown separates borrowers from repayers. Product-level breakdown groups by specific product identifiers. Each breakdown uses `hll_count.extract()` to convert merged HyperLogLog structures into final user counts, then combines all breakdowns using union operations
- **Key fields**: `dimensions` (breakdown type), `user_wau` (extracted unique user count), dimensional identifiers

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, with null values for non-applicable dimension columns in each breakdown
- **Time aggregation**: Weekly boundaries are calculated as 7-day rolling windows ending on each calendar day, not fixed weekly periods
- **Final calculation**: Extract unique user counts from merged HyperLogLog structures using `hll_count.extract()`, providing probabilistic estimates of unique users with high accuracy
- **Schema finalization**: Apply the `finalize_metric_user_wau` macro to standardize the output schema, add project metadata, and fill missing days with zero values to ensure complete time series coverage

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

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

Lybra FinanceLBR

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown