website

twitter

discord

github

Asset management

Reserve

# Reserve Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) for Reserve Protocol measures the average daily revenue generated per active user across all Reserve products. This metric is calculated by dividing total daily protocol revenue by the number of daily active users. Reserve operates two main product categories: yield-bearing RTokens that generate revenue through RSR buybacks, and index tokens (folios) that generate revenue through management fees. ARPU provides insight into the protocol's revenue efficiency and user value generation.

## 2. Data sources

The calculation uses the following raw data sources:

- **Token transfer events**: Parsed `Transfer` events from Ethereum, Base, and Arbitrum blockchains tracking token movements to and from Reserve protocol contracts
- **Protocol deployment events**: `RTokenFactory_RTokenCreated_event` logs for yield products and `FolioDeployer_GovernedFolioDeployed_event` logs for index products across supported chains
- **Configuration events**: `RTokenMain_BackingManagerSet_event` and `RTokenMain_RSRTraderSet_event` logs establishing contract relationships for yield products
- **Fee configuration events**: `DTF_FeeRecipientsSet_event`, `DTF_TVLFeeSet_event`, and `DTF_MintFeeSet_event` logs setting fee parameters for index products
- **Trading events**: `RSR_TradeSettled_event` logs from RSR trader contracts recording buyback transactions
- **Price feeds**: End-of-day token price data for USD conversion
- **Token metadata**: Token decimal information for amount normalization

## 3. Step-by-step calculation

### Component A: Product identification
- **Purpose**: Identify and categorize Reserve protocol products across supported chains
- **Logic**: Extract product creation events to build a registry of Reserve products. Yield products (RTokens) are identified from `RTokenFactory_RTokenCreated_event` logs which contain the main config address, RToken address, and staked token address. Index products (folios) are identified from `FolioDeployer_GovernedFolioDeployed_event` logs containing the index token address and staked token address. Products are categorized as either `Reserve Yield`, `Reserve Rights`, or `Reserve Index` based on contract addresses and deployment patterns.
- **Key fields**: `config_address`, `rtoken_address`, `staked_token_address`, `index_token_address`, `product_id`

### Component B: Contract relationship mapping  
- **Purpose**: Map protocol contracts to their associated products for revenue and user tracking
- **Logic**: Use configuration events to establish relationships between different contract types. Backing manager addresses are linked to yield products via `RTokenMain_BackingManagerSet_event` logs. RSR trader addresses are connected to products through `RTokenMain_RSRTraderSet_event` logs. Fee recipient configurations for index products are established through `DTF_FeeRecipientsSet_event` logs. These mappings enable proper attribution of user activity and revenue to specific products.
- **Key fields**: `backing_manager_address`, `rsr_trader_address`, `recipient_address`, `recipient_portion`

### Component C: User activity tracking
- **Purpose**: Identify and count daily active users across all Reserve products
- **Logic**: Monitor token transfer events to identify user interactions with Reserve protocol contracts. For yield products, track transfers to backing manager addresses (deposits) and from backing manager addresses (withdrawals), plus RSR transfers to staked token addresses. For index products, track transfers to index token addresses (deposits) and from index token addresses (withdrawals). Extract user addresses from transfer `from_address` and `to_address` fields, categorizing users as `Depositor` or `Withdrawer` based on transfer direction. Aggregate unique user addresses per day using HyperLogLog for efficient distinct counting across multiple dimensions including chain, product, and user type.
- **Key fields**: `user_address`, `user_type`, `block_timestamp`, `chain_id`, `product_id`

### Component D: Index product revenue calculation
- **Purpose**: Calculate fee-based revenue from Reserve index token products
- **Logic**: Compute revenue from two fee components applied to index products. TVL fees are calculated by multiplying token balances held by index contracts by the TVL fee per second rate, then by seconds per day (86400). Mint fees are calculated by multiplying deposit amounts by the configured mint fee rate. Fee rates are extracted from configuration events and normalized from 18-decimal blockchain values to decimal percentages. Total fees are split between supply-side participants and protocol revenue using the platform fee rate from recipient configurations. Protocol revenue equals total fees multiplied by the platform fee rate.
- **Key fields**: `amount`, `tvl_fee_per_second`, `mint_fee`, `platform_fee_rate`, `revenue`

### Component E: Yield product revenue calculation  
- **Purpose**: Calculate buyback-based revenue from Reserve RToken yield products
- **Logic**: Capture RSR buyback transactions from `RSR_TradeSettled_event` logs emitted by RSR trader contracts. Extract the `buyAmount` field representing the quantity of tokens purchased with RSR. These amounts represent protocol revenue generated from yield product operations. Convert buyback amounts from native token units to decimal-corrected values, then to USD using end-of-day price feeds.
- **Key fields**: `buyAmount`, `token_address`, `amount`, `revenue`

### Component F: Balance tracking for TVL fees
- **Purpose**: Maintain cumulative token balances for TVL fee calculations
- **Logic**: Track token flows into and out of index contracts by combining inflow and outflow transfer events. Calculate running cumulative balances for each token held by each index contract using window functions ordered by timestamp and log index. Extract end-of-day balance snapshots by taking the latest balance each day. Fill forward balances for days without transactions to ensure continuous TVL fee calculations across all calendar days.
- **Key fields**: `amount`, `cumulative_balance`, `end_of_day_balance`

### Final aggregation
- **Combining components**: Sum index product revenue and yield product revenue by day to get total protocol revenue. Count distinct users across all products using HyperLogLog merge operations to get total daily active users. Both revenue and user counts are aggregated at the protocol level, combining data across all chains and product types.
- **Currency conversion**: All revenue amounts are converted to USD using end-of-day price feeds via the `convert_to_usd_and_correct_decimals` macro, which handles both decimal normalization and USD conversion in a single operation.
- **Time aggregation**: All data is aggregated to daily boundaries using `timestamp_trunc(block_timestamp, day)` with end-of-day snapshots for balance-based calculations and daily sums for flow-based calculations.
- **Final calculation**: ARPU is calculated by dividing total daily protocol revenue by total daily active users using the `calculate_arpu` macro, with missing days filled using a zero-fill strategy to maintain continuous time series data.

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

ReserveRSR

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape