website

twitter

discord

github

Asset management

Reserve

# Reserve Active users (daily) Methodology

## 1. Overview

Reserve user daily active users (DAU) measures the count of distinct wallet addresses that interact with Reserve Protocol products on any given day. This metric captures user engagement across Reserve's ecosystem including yield-bearing RTokens, stablecoins, and index products (folios), as well as RSR token staking activities. The calculation aggregates all user interactions from token transfer events across Ethereum, Base, and Arbitrum networks, counting each unique address only once per day regardless of interaction frequency or type.

## 2. Data sources

The calculation relies on the following blockchain data sources:

- **Token transfer events**: Parsed `Transfer` events from Ethereum, Base, and Arbitrum networks, indexed by both recipient (`by_to`) and sender (`by_from`) addresses to efficiently identify protocol interactions
- **Reserve factory events**: `RTokenFactory_RTokenCreated` events across Reserve protocol versions (v1, v2, v3) on Ethereum, Base, and Arbitrum that establish RToken markets and their associated contract addresses
- **Index deployment events**: `FolioDeployer_GovernedFolioDeployed` events from Reserve v1 on Ethereum and Base that create index product markets (folios)
- **Backing manager events**: `RTokenMain_BackingManagerSet` events across all Reserve versions and chains that map RTokens to their backing manager contracts
- **RSR token contracts**: Hardcoded RSR token addresses on Ethereum (`0x320623b8e4ff03373931769a31fc52a4e78b5d70`) and Base (`0xab36452dbac151be02b16ca17d8919826072f64a`)
- **Protocol metadata**: Static configuration data distinguishing stablecoin addresses from general yield tokens

## 3. Step-by-step calculation

### Component A: Market identification and categorization

- **Purpose**: Establishes the universe of Reserve protocol contracts and categorizes them by product type
- **Logic**: Extract contract addresses from factory deployment events across multiple protocol versions. For yield markets, parse `RTokenFactory_RTokenCreated` events to identify RToken addresses, backing manager addresses, and staked token addresses. Apply hardcoded logic to categorize specific RToken addresses as stablecoins (`Reserve Rights`) versus general yield tokens (`Reserve Yield`). For index markets, parse `FolioDeployer_GovernedFolioDeployed` events to identify index token and staked token addresses, categorizing all as `Reserve Index` products. Link backing manager addresses to their corresponding RTokens through `RTokenMain_BackingManagerSet` events.
- **Key fields**: `rtoken_address`, `backing_manager_address`, `staked_token_address`, `index_token_address`, `product_id`, `chain_id`

### Component B: Backing manager user flows

- **Purpose**: Captures users depositing collateral to and withdrawing collateral from RToken backing managers
- **Logic**: Identify token transfers where backing manager addresses are either recipients (deposits) or senders (withdrawals). For deposits, classify the `from_address` as a 'Depositor' user. For withdrawals, classify the `to_address` as a 'Withdrawer' user. Join token transfer events with the backing manager dimension table to associate flows with specific RToken products. Apply positive amounts for deposits and negative amounts for withdrawals.
- **Key fields**: `user_address` (derived from `from_address` or `to_address`), `user_type`, `amount`, `token_address`, `product_id`

### Component C: Index token user flows  

- **Purpose**: Captures users interacting with Reserve index products (folios)
- **Logic**: For index inflows, identify token transfers TO index token addresses, classifying `from_address` as 'Depositor' users. For index outflows, identify token transfers FROM index token addresses, classifying `to_address` as 'Withdrawer' users. Join with index market dimensions to associate flows with `Reserve Index` products. Apply positive amounts for inflows and negative amounts for outflows.
- **Key fields**: `user_address`, `user_type`, `index_token_address`, `amount`, `product_id`

### Component D: RSR staking flows

- **Purpose**: Captures users staking and unstaking RSR tokens with Reserve protocol staking contracts
- **Logic**: Filter token transfers to RSR token addresses only. For RSR deposits, identify transfers TO staked token addresses (stRSR contracts), classifying `from_address` as 'Depositor' users. For RSR withdrawals, identify transfers FROM staked token addresses, classifying `to_address` as 'Withdrawer' users. Join with yield market dimensions to associate RSR flows with appropriate product categories. Apply positive amounts for staking and negative amounts for unstaking.
- **Key fields**: `user_address`, `user_type`, `token_address` (RSR address), `amount`, `product_id`

### Component E: User activity aggregation

- **Purpose**: Combines all user interaction types into a unified activity dataset
- **Logic**: Union all user flows (backing manager, index, RSR staking) into a single dataset. Standardize user address extraction based on flow direction - for 'Depositor' flows use `from_address`, for 'Withdrawer' flows use `to_address`. Truncate all timestamps to daily boundaries and preserve user type, product categorization, chain, and token information for downstream analysis.
- **Key fields**: `timestamp` (daily), `user_address`, `user_type`, `product_id`, `chain_id`, `token_address`

### Final aggregation

- **Combining components**: All user activity records are unioned together and grouped by daily timestamp boundaries
- **Distinctness logic**: Count distinct `user_address` values per day, regardless of how many transactions or interaction types each user performed
- **Time aggregation**: All activity timestamps are truncated to day-level granularity using `timestamp_trunc(block_timestamp, day)`
- **Final calculation**: Select distinct combinations of daily timestamp, user address, user type, product ID, and chain ID. Apply chain availability filtering to ensure data completeness. The final metric represents unique wallet addresses that performed any Reserve protocol interaction on each day, segmented by user type and product category.

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

Unique revenue-generating users over a fixed 24-hour window.

ReserveRSR

Active users (daily)

Active users (daily)

Competitive landscape

Chain breakdown