website

twitter

discord

Liquid staking

Trevee

# Trevee Revenue Methodology

## 1. Overview

Revenue measures the portion of fees that Trevee retains, as determined by its take rate. Performance fees from Trevee scETH and Rings scUSD, protocol fees from quest creation, and gauge-related revenue are included in this metric. Revenue is calculated after the distribution of fees to supply-side participants and represents the protocol's earnings from its yield-bearing assets and questing infrastructure.

## 2. Data sources

- **Blockchain events**: `PerformanceFeeUpdated` events from `wstkscBTC`, `wstkscETH`, and `wstkscUSD` contracts; `YieldClaimed` events from `scETHAccountant` and `scUSDAccountant` contracts; `createRangedQuest` and `createFixedQuest` function calls from `QuestRingsveBTC`, `QuestRingsveETH`, `QuestRingsveUSD`, `QuestRingsveBAL`, `QuestRingsveCRV`, and `QuestRingsveFXN` contracts; and ERC-20 token transfers, covering Ethereum and Sonic
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Performance fee rate tracking

- **Purpose**: Tracks the protocol's take rate for yield-bearing assets
- **Logic**: `PerformanceFeeUpdated` events are parsed from `wstkscBTC`, `wstkscETH`, and `wstkscUSD` contracts to identify the active performance fee rate for each asset. Rates are normalized by decimal precision and tracked over time to ensure point-in-time accuracy for revenue calculations.
- **Key fields**: `newPerformanceFee` (fee rate), `token_address` (asset identification)

### Component B: Yield-based revenue calculation

- **Purpose**: Calculates revenue generated from performance fees on asset yields
- **Logic**: `YieldClaimed` events are parsed from `scETHAccountant` and `scUSDAccountant` contracts. Protocol revenue is calculated by applying the performance fee rate identified in Component A to the claimed yield amount.
- **Key fields**: `amount` (yield quantity), `yieldAsset` (token identification)

### Component C: Quest fee extraction

- **Purpose**: Captures protocol fees from the creation of fixed and ranged quests
- **Logic**: `createRangedQuest` and `createFixedQuest` function calls are parsed from `QuestRingsveBTC`, `QuestRingsveETH`, `QuestRingsveUSD`, `QuestRingsveBAL`, `QuestRingsveCRV`, and `QuestRingsveFXN` contracts. Protocol fees are extracted from the `feeAmount` field for each quest creation event.
- **Key fields**: `feeAmount` (protocol fee), `rewardToken` (asset identification)

### Component D: Gauge revenue tracking

- **Purpose**: Captures direct revenue transfers from gauge mechanisms
- **Logic**: Gauge revenue is identified by tracking ERC-20 token transfers to the designated protocol fee recipient address. These transfers represent direct revenue captured by the protocol from gauge activities.
- **Key fields**: `amount` (transfer value), `to_address` (fee recipient)

### Component E: USD conversion and aggregation

- **Purpose**: Normalizes all revenue components to USD for final reporting
- **Logic**: All revenue components are aggregated by day and asset. Amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. Daily granularity is maintained with UTC day boundaries.
- **Key fields**: `block_timestamp` (timing), `token_address` (asset identification), `price_usd` (valuation)

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

TreveeTREVEE

Revenue

Revenue

Competitive landscape

Chain breakdown