website

twitter

discord

github

Asset management

Reserve

# Reserve Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Reserve Protocol measures the number of unique wallet addresses that interact with Reserve products within a 30-day rolling window. This metric captures user engagement across Reserve's yield markets (RTokens), stablecoin markets, index products (folios), and RSR staking activities. The calculation uses HyperLogLog sketches to efficiently count unique users across multiple dimensions including chain, product type, and user behavior classification.

## 2. Data sources

The MAU calculation relies on several types of blockchain data and protocol-specific events:

- **Token transfer events**: Parsed ERC-20 `Transfer` events from Ethereum, Base, and Arbitrum networks that capture user deposits and withdrawals
- **Reserve protocol deployment events**: `RTokenFactory_RTokenCreated_event` logs that identify when new RToken markets are created across multiple chains
- **Backing manager configuration events**: `RTokenMain_BackingManagerSet_event` logs that map backing manager contract addresses to their respective markets
- **Index product deployment events**: `FolioDeployer_GovernedFolioDeployed_event` logs from Ethereum and Base that identify Reserve index products (folios)
- **RSR token addresses**: Hardcoded Reserve Rights token contract addresses on Ethereum (`0x320623b8e4ff03373931769a31fc52a4e78b5d70`) and Base (`0xab36452dbac151be02b16ca17d8919826072f64a`)
- **Protocol classifications**: Hardcoded stablecoin address classifications that distinguish between yield-bearing and stable products

## 3. Step-by-step calculation

### Component A: Market and address identification
- **Purpose**: Establishes the mapping between Reserve Protocol contracts and their product classifications
- **Logic**: Extract deployment events to identify RToken markets, backing manager addresses, and index products. RTokens are classified as either 'Reserve Yield' or 'Reserve Rights' based on hardcoded stablecoin addresses (`0xa0d69e286b938e21cbf7e51d71f6a4c8918f482f` and `0x78da5799cf427fee11e9996982f4150ece7a99a7`). Index products are identified from folio deployment events and classified as 'Reserve Index'. Backing manager addresses are mapped to their respective RToken markets for proper attribution
- **Key fields**: `chain_id`, `product_id`, `config_address`, `backing_manager_address`, `rtoken_address`, `staked_token_address`, `index_token_address`

### Component B: User interaction capture
- **Purpose**: Identifies user deposit and withdrawal activities across all Reserve products
- **Logic**: Extract token transfer events where the recipient or sender matches Reserve Protocol contract addresses. For backing manager flows, capture transfers both to backing managers (deposits) and from backing managers (withdrawals). For index products, capture transfers to and from index token addresses. For RSR flows, capture RSR token transfers to and from staked RSR contract addresses. Users are classified as 'Depositor' when they send tokens to Reserve contracts or 'Withdrawer' when they receive tokens from Reserve contracts
- **Key fields**: `block_timestamp`, `transaction_hash`, `chain_id`, `user_type`, `token_address`, `user_address`, `product_id`, `amount`

### Component C: Daily user aggregation
- **Purpose**: Creates daily unique user counts while preserving detailed user activity data
- **Logic**: Aggregate all user interaction events to daily granularity, identifying unique wallet addresses for each combination of date, chain, user type, and product. Maintain the user address as the unique identifier for downstream HyperLogLog processing. Filter and deduplicate user events across the four fact tables (backing manager flows, index inflows, index outflows, RSR flows)
- **Key fields**: `timestamp`, `timestamp_grain`, `user_address`, `user_type`, `product_id`, `chain_id`

### Component D: HyperLogLog sketch creation
- **Purpose**: Converts daily user lists into efficient probabilistic data structures for unique counting
- **Logic**: Transform the daily user data into HyperLogLog sketches using `hll_count.init` with precision parameter 15. Group by timestamp, chain, user type, and product to create separate sketches for each dimension combination. This enables efficient merging and counting of unique users across time windows without storing individual user addresses
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component E: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for each date to enable MAU calculation
- **Logic**: Generate a datespine covering all dates from the earliest DAU data to the current date. For each date, create associations with the previous 29 days (plus the current day) to form 30-day windows. Join the datespine with daily HLL sketches to populate each window with the available user data. Handle missing days gracefully by only including days where user activity was recorded
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within the window), `hll` sketches from matching days

### Final aggregation
- **Combining components**: Merge HyperLogLog sketches within each 30-day window using `hll_count.merge_partial` to combine unique user counts across all days in the window. Extract the final unique user count using `hll_count.extract`
- **Dimensional breakdowns**: Create separate aggregations for project-level (all chains and products combined), chain-level, user type-level, and product-level MAU counts. Each breakdown uses the same HLL merging logic but groups by different dimension combinations
- **Time aggregation**: The rolling 30-day window moves daily, so each date represents the unique users active in the 30 days ending on that date. Monthly partitioning is used for efficient storage and querying
- **Final calculation**: The MAU value for any given date represents the count of unique wallet addresses that interacted with Reserve Protocol products in the 30-day period ending on that date, calculated using probabilistic HyperLogLog counting for accuracy and efficiency

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

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

ReserveRSR

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown