website

twitter

discord

github

Asset management

Reserve

# Reserve Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique wallet addresses that interact with Reserve protocol products within any 7-day rolling window. This metric captures user engagement across Reserve's yield-bearing RTokens, stablecoins, index products (folios), and RSR staking activities. The calculation uses HyperLogLog probabilistic data structures to efficiently handle large-scale unique user counting across multiple blockchains and product types.

## 2. Data sources

The metric relies on the following blockchain data sources:

- **Token transfer events**: Parsed `Transfer` events from Ethereum, Base, and Arbitrum networks, filtered by sender and recipient addresses to identify flows to/from Reserve protocol contracts
- **Reserve protocol deployment events**: `RTokenFactory_RTokenCreated_event` events that identify RToken contract addresses and their associated backing managers and staked token addresses across all supported chains
- **Folio deployment events**: `FolioDeployer_GovernedFolioDeployed_event` events that identify Reserve index product contract addresses on Ethereum and Base
- **Backing manager configuration events**: `RTokenMain_BackingManagerSet_event` events that map RToken configurations to their backing manager contract addresses
- **RSR token transfers**: Specific `Transfer` events for RSR token contracts on Ethereum and Base networks, filtered for flows to/from staked RSR (stRSR) contract addresses

## 3. Step-by-step calculation

### Component A: User interaction identification
- **Purpose**: Identify all user wallet addresses that interact with Reserve protocol products on any given day
- **Logic**: Extract user addresses from token transfer events across four interaction types: backing manager flows (RToken deposits/withdrawals), index token flows (folio interactions), and RSR staking flows. For deposits and staking, the user address comes from the `from_address` field. For withdrawals and unstaking, the user address comes from the `to_address` field. Each interaction is classified with a `user_type` of either 'Depositor' or 'Withdrawer' based on the flow direction.
- **Key fields**: `user_address` (wallet performing the interaction), `user_type` (Depositor or Withdrawer), `product_id` (Reserve Yield, Reserve Rights, or Reserve Index), `chain_id` (ethereum, base, or arbitrum), `timestamp` (truncated to daily boundaries)

### Component B: Daily active user aggregation
- **Purpose**: Create daily unique user counts and convert them to HyperLogLog sketches for efficient storage and merging
- **Logic**: Group all user interactions by day, chain, user type, and product, then create a distinct list of user addresses for each combination. Convert these user sets into HyperLogLog sketches using 15-bit precision to enable efficient merging operations while maintaining accuracy for unique counting.
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch of daily unique users)

### Component C: Rolling window construction
- **Purpose**: Create 7-day rolling windows for WAU calculation by generating date ranges and joining with daily data
- **Logic**: Generate a complete date spine covering all days from the earliest data to yesterday. For each date, create join keys for the current day plus the 6 preceding days (7 days total). Join this expanded date range with the daily HyperLogLog data to collect all relevant daily sketches for each 7-day window.
- **Key fields**: `timestamp` (the end date of each 7-day window), `joinday` (each day within the 7-day window), `hll` (daily HyperLogLog sketches to be merged)

### Component D: Weekly active user calculation by dimension
- **Purpose**: Calculate unique weekly active users across different dimensional breakdowns
- **Logic**: For each 7-day window, merge all HyperLogLog sketches within that window and extract the final unique user count. Create separate calculations for four dimensional breakdowns: overall project level (all dimensions null), by chain, by user type, and by product. Each breakdown groups the data differently but uses the same HLL merging approach to count unique users across the 7-day period.
- **Key fields**: `user_wau` (unique user count from merged HLL sketches), `dimensions` (breakdown type: project_dbt_tag, chain, user_type, or product_id), dimension-specific fields set to non-null only for their respective breakdowns

### Final aggregation
- **Combining components**: Union all four dimensional breakdowns into a single result set, maintaining the same schema structure with dimension-specific fields populated only for their relevant breakdown type
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Each record represents a 7-day rolling window ending on the specified date, calculated daily to provide continuous WAU tracking
- **Final calculation**: The `user_wau` field contains the exact count of unique wallet addresses that interacted with Reserve protocol products within each 7-day rolling window, derived from merging HyperLogLog sketches and extracting the final cardinality estimate

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

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

ReserveRSR

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown