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 (monthly) Methodology

## 1. Overview

The Lybra monthly active users (MAU) metric measures the approximate number of distinct users who interact with the Lybra protocol within a 30-day rolling window. This metric captures both borrowers (who mint stablecoins) and repayers (who burn stablecoins) across various Lybra vault contracts on Ethereum. The calculation uses HyperLogLog algorithms for efficient approximate counting of distinct users across multiple dimensions including project-level, chain-level, user type, and product breakdowns.

## 2. Data sources

- **Lybra protocol events**: Parsed Ethereum smart contract events from Lybra V1 and V2 vault contracts including `Mint` and `Burn` events
- **Vault contracts**: Events from multiple vault types including eUSD V1, RETH, WBETH, StETH, and WstETH vaults
- **Blockchain data**: Ethereum transaction timestamps and block information for temporal aggregation
- **Chain availability data**: Configuration data determining which chains and time periods have valid data coverage

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Extract and classify user addresses from Lybra protocol interactions
- **Logic**: Parse `Mint` and `Burn` events from all Lybra vault contracts on Ethereum. Extract the `onBehalfOf` parameter from each event as the user address. Classify users based on event type: `Mint` events identify users as 'Borrower' (users who mint stablecoins by depositing collateral), while `Burn` events identify users as 'Repayer' (users who burn stablecoins to repay debt or withdraw collateral). Each interaction includes the block timestamp, transaction hash, log index, and vault-specific product information.
- **Key fields**: `onBehalfOf` (user address), `block_timestamp` (interaction time), event type determines `user_type` classification, chain identifier, market sector as 'stablecoin_issuers', business segment as 'stablecoin_issuer'

### Component B: Daily active user aggregation  
- **Purpose**: Aggregate user interactions into daily active user counts by various dimensions
- **Logic**: Group the classified user interactions by day (truncating block timestamps to daily granularity), chain, user type, market sector, business segment, and product. Extract distinct user addresses for each day and dimension combination. Apply chain availability filtering to ensure only valid time periods for each chain are included. This creates a foundation of daily active users that will be rolled up into monthly windows.
- **Key fields**: `timestamp` (daily), `timestamp_grain` ('day'), `chain`, `user_type`, `product_id`, `user_dau` (distinct user addresses)

### Component C: HyperLogLog sketch initialization
- **Purpose**: Convert daily user lists into efficient data structures for approximate distinct counting
- **Logic**: Transform the daily active user data into HyperLogLog sketches using precision 15. Group by timestamp, chain, user type, and product, then initialize HLL sketches for each group's user addresses. This enables efficient approximate counting when combining multiple days of data while maintaining reasonable accuracy for distinct user counts.
- **Key fields**: `hll` (HyperLogLog sketch of user addresses), maintaining all dimensional breakdowns from daily data

### Component D: Rolling window creation
- **Purpose**: Generate 30-day sliding windows for monthly active user calculation
- **Logic**: Create a datespine covering all relevant dates from the earliest available data to yesterday. For each date in the datespine, generate a 30-day lookback period (the current day plus the previous 29 days). This creates a cross-join structure where each final date is associated with all dates in its 30-day window. Apply incremental processing logic to limit the date range when running incremental updates, using table modification timestamps plus safety margins.
- **Key fields**: `timestamp` (final date), `joinday` (each day within the 30-day window)

### Component E: Window data aggregation
- **Purpose**: Combine daily HLL sketches within each 30-day window
- **Logic**: Join the rolling window structure with the daily HLL data, matching each window day with its corresponding daily sketch. This creates a dataset where each final date has associated HLL sketches for all days in its 30-day window. Filter the data based on incremental processing requirements when running updates, ensuring sufficient lookback periods to handle late-arriving data.
- **Key fields**: `timestamp` (final date), `hll` (daily sketches), dimensional breakdowns (`chain_id`, `user_type`, `product_id`)

### Component F: Multi-dimensional MAU calculation
- **Purpose**: Calculate monthly active users across different analytical dimensions
- **Logic**: Create four separate dimensional breakdowns: project-level (aggregating all users regardless of other dimensions), chain-level (grouping by blockchain), user type-level (separating borrowers and repayers), and product-level (grouping by vault/product). For each breakdown, group the window data by the relevant dimensions and merge the HLL sketches using `hll_count.merge_partial`, then extract the approximate distinct count using `hll_count.extract`. Set irrelevant dimension fields to null for each breakdown type.
- **Key fields**: `dimensions` (breakdown type), `user_mau` (approximate distinct user count), dimensional identifiers based on breakdown type

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project, chain, user type, product) into a single result set with a common schema
- **Time aggregation**: Each record represents a single day with its corresponding 30-day rolling MAU count
- **Final calculation**: The `user_mau` field contains the approximate count of distinct users who interacted with Lybra protocol in the 30-day period ending on the given timestamp, broken down by the specified dimension

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

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

Lybra FinanceLBR

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown