Liquidity providers deposit funds into Ribbon Protocol and receive option premiums from traders & withdrawal fees from other liquidity providers (supply-side fees).

Ribbon Finance is a non-custodial asset management protocol built on Ethereum. Ribbon Finance was founded by Julian Koh & Ken Chan and launched in 2021.

RBN tokenholders own and govern the protocol. They currently take a cut of the total premiums and management fees paid by liquidity providers (revenue).

governance

github

twitter

discord

etherscan

website

Asset management

Ribbon Finance

# Ribbon Finance Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Ribbon protocol measures the number of unique user addresses that interact with Ribbon's yield generation vaults within any 30-day period. This metric uses a rolling window approach where each day's MAU represents the count of unique users who were active on that day or any of the previous 29 days. The calculation employs HyperLogLog algorithms for efficient cardinality estimation and provides breakdowns across chains, user types, and products.

## 2. Data sources

The metric relies on the following blockchain data sources:
- **Ribbon protocol events**: Parsed smart contract events from Ethereum and Avalanche blockchains, specifically `Deposit`, `Withdraw`, and `InstantWithdraw` events
- **Vault interaction data**: Events from multiple Ribbon vault types including ThetaVault, EarnVault, and TreasuryVault across protocol versions v1 and v2
- **Blockchain transaction data**: Ethereum and Avalanche transaction timestamps and user addresses from vault interaction events
- **Chain availability data**: Filters to ensure data quality and completeness across supported blockchain networks

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Identify all user interactions with Ribbon protocol vaults across supported chains
- **Logic**: Extract user addresses and timestamps from vault deposit and withdrawal events across Ethereum and Avalanche. Events are sourced from multiple vault types including ThetaVault (v1 and v2), EarnVault (v2), and TreasuryVault (v2). Each event contains an `account` field representing the user address and is classified based on event type - deposit events classify users as 'Depositor' while withdraw and instant withdraw events classify users as 'Withdrawer'. All interactions are tagged with chain information ('ethereum' or 'avalanche'), market sector ('asset_management'), and business segment ('yield_aggregator')
- **Key fields**: `block_timestamp` for timing, `account` for user address, event type for user classification, `transaction_hash` for deduplication

### Component B: Daily active user aggregation  
- **Purpose**: Calculate unique daily active users with proper deduplication and dimensional grouping
- **Logic**: Transform the user event data by truncating `block_timestamp` to daily granularity using day-level timestamp truncation. Deduplicate user addresses within each day to count unique active users. Group results by day, chain, user type, and product dimensions. Apply chain availability filtering to ensure data completeness across supported networks. This creates the foundation dataset of daily unique users that will be aggregated into monthly metrics
- **Key fields**: `timestamp` (day-truncated), `chain`, `user_type`, `product_id`, `user_address` (deduplicated daily)

### Component C: HyperLogLog sketch creation
- **Purpose**: Create efficient cardinality estimation structures for scalable unique user counting
- **Logic**: Initialize HyperLogLog sketches for each day's user data using 15-bit precision for accurate cardinality estimation. Group daily user data by timestamp, chain, user type, and product dimensions. Each HLL sketch represents the unique users for a specific day and dimensional combination, enabling efficient merging operations for window calculations
- **Key fields**: `hll` sketch containing daily user cardinality data, dimensional grouping fields

### Component D: Complete datespine generation
- **Purpose**: Ensure continuous time series coverage without gaps in MAU calculations
- **Logic**: Generate a complete sequence of daily timestamps from the earliest available data date through yesterday using timestamp array generation. This datespine ensures that MAU calculations don't skip days with no activity and maintains consistent time series data. For incremental processing, the datespine starts from 29 days plus lookback period before the last modification time
- **Key fields**: `timestamp` representing each day in the analysis period

### Component E: 30-day rolling window creation
- **Purpose**: Create sliding windows to capture all users active within each 30-day period
- **Logic**: For each day in the datespine, generate an array of the current day plus the previous 29 days to create a 30-day window. Join this window data with the daily HLL sketches to identify all user activity within each rolling period. This approach ensures that a user active on any day within the 30-day window contributes to that period's MAU calculation. Filter data appropriately for incremental processing to maintain efficiency
- **Key fields**: `timestamp` (current day), `joinday` (days within the 30-day window), dimensional grouping fields, `hll` sketches

### Component F: Monthly user aggregation with dimensional breakdowns
- **Purpose**: Calculate unique monthly active users across multiple dimensional cuts
- **Logic**: Merge HyperLogLog sketches within each 30-day window to calculate unique user counts across the time period. Create four distinct dimensional breakdowns: overall project level (all dimensions aggregated), by chain (maintaining chain splits), by user type (maintaining user type splits), and by product (maintaining product splits). For each breakdown, merge the appropriate HLL sketches and extract the final cardinality estimate. Use safe casting to null for unused dimensional fields in each breakdown
- **Key fields**: `user_mau` (extracted unique count), `dimensions` (breakdown type), chain/user type/product fields as applicable

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project-level, chain-level, user type-level, and product-level) into a single result set with consistent schema
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily MAU values represent rolling 30-day unique user counts, with each day showing users active in that day plus the previous 29 days
- **Final calculation**: Extract unique user count from merged HyperLogLog sketches, providing accurate cardinality estimation for monthly active users across all specified dimensional cuts, with appropriate null handling and schema standardization through the finalize metric macro

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

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

Ribbon FinanceRBN

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown