website

twitter

discord

Liquid staking

Trevee

# Trevee Average revenue per user (ARPU) Methodology

## 1. Overview

Average revenue per user (ARPU) measures the revenue generated per active user over a fixed 24-hour window. It is calculated as total daily revenue divided by active users (daily) and reflects how much Trevee is able to monetize an individual user on a daily basis. This metric provides insight into the monetization efficiency of products such as Trevee scETH, Rings scUSD, and Rings scBTC across different user activities including yield generation and quest participation.

## 2. Data sources

- **Blockchain events**: `Enter`, `Exit`, `Deposit`, `Withdraw`, `YieldClaimed`, and `PerformanceFeeUpdated` events, plus `createRangedQuest` and `createFixedQuest` function calls from various protocol contracts, covering Ethereum and Sonic
- **Revenue**: Derived from the Revenue metric
- **Active users (daily)**: Derived from the Active users (daily) metric
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Active user identification

- **Purpose**: Identify unique daily participants across all Trevee products
- **Logic**: Unique user addresses are identified from interaction events. On Ethereum and Sonic, `Enter` and `Exit` events are parsed from Rings scBTC, Trevee scETH, and Rings scUSD contracts. On Sonic, additional activity is captured from `Enter` and `Exit` events from `stkscBTC`, `stkscETH`, and `stkscUSD` contracts, as well as `Deposit` and `Withdraw` events from `wstkscBTC`, `wstkscETH`, `wstkscUSD`, `veBTC`, `veETH`, and `veUSD` contracts. These addresses are aggregated to determine the active users (daily).

### Component B: Revenue calculation

- **Purpose**: Aggregate all protocol-retained fees and income
- **Logic**: Revenue is calculated from three primary sources. First, quest fees are captured from `createRangedQuest` and `createFixedQuest` function calls from `QuestRingsveBTC`, `QuestRingsveETH`, `QuestRingsveUSD`, `QuestRingsveBAL`, `QuestRingsveCRV`, and `QuestRingsveFXN` contracts. Second, yield-based revenue is determined by parsing `YieldClaimed` events from `scETHAccountant` and `scUSDAccountant` contracts and applying the performance fee rates identified in `PerformanceFeeUpdated` events from `wstkscBTC`, `wstkscETH`, and `wstkscUSD` contracts. Third, gauge-related revenue is tracked via token transfers to the designated gauge fee recipient address. All amounts are normalized by decimal precision and converted to USD using end-of-day price feeds.

### Component C: Average revenue per user calculation

- **Purpose**: Determine the daily monetization rate per active user
- **Logic**: The total daily revenue is divided by the count of unique active users (daily). The calculation is performed at a daily granularity using UTC day boundaries. If no revenue or users are recorded for a specific day, the value is set to zero.

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

TreveeTREVEE

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape