# OToken Supply-side fees Methodology

## 1. Overview

Supply-side fees measures the portion of yield and transaction fees generated by OToken that is distributed to asset holders and liquidity providers. This metric represents the gross earnings of supply-side participants including holders of Origin Ether (OETH), Super OETH (superOETHb), and Origin Sonic (OS). These fees are primarily derived from rebasing yield produced by underlying collateral assets and a portion of fees collected from redemptions and Automated Range Management (ARM) operations, after accounting for the protocol's fee share.

## 2. Data sources

- **Blockchain events**: `YieldDistribution` and `Redeem` events from `OETHVault`, `OSVault`, and `superOETHbVault` contracts; `TotalSupplyUpdatedHighres` events, `mint` function calls, and `burn` function calls from `superOETHb` contracts; `FeeCollected`, `Deposit`, and `RedeemRequested` events from `LidoARM` contracts; and ERC-20 token transfers, covering Ethereum, Base, and Sonic
- **External data**: End-of-day price feeds

## 3. Step-by-step calculation

### Component A: OToken yield and rebase tracking

- **Purpose**: Captures yield generated by the underlying collateral of rebasing assets.
- **Logic**: Yield distribution events are parsed from `OETHVault`, `OSVault`, and `superOETHbVault` contracts. For `superOETHb` on Base, rebase yield is calculated by determining the difference between the total supply and the net flow of mints and burns (derived from `mint` and `burn` function calls). For later periods on Base, yield is tracked via WETH transfers from the dripper address to the vault. The supply-side portion is isolated by deducting the protocol fee ratio (e.g., 20% or 25%) from the total yield captured.
- **Key fields**: `in__yield`, `in__fee`, `in_totalSupply`, `in__amount`

### Component B: Redemption fee collection

- **Purpose**: Measures the fees paid by users when redeeming OToken assets for underlying collateral.
- **Logic**: `Redeem` events are captured from `OETHVault`, `OSVault`, and `superOETHbVault` contracts across all supported chains. Fee rates are identified from `RedeemFeeUpdated` events and applied to the redemption value based on a tier-based lookup. These fees are aggregated and classified as supply-side fees.
- **Key fields**: `in__value`, `in__redeemFeeBps`

### Component C: Automated Range Management (ARM) fees

- **Purpose**: Captures fees and yield generated through the Automated Range Management product.
- **Logic**: `FeeCollected` events and yield changes are tracked from `LidoARM` contracts on Ethereum. Yield is calculated by comparing total assets against cumulative deposits and withdrawals. The supply-side share is determined by subtracting the protocol fee rate (identified from `FeeUpdated` events) from the total fees and yield collected.
- **Key fields**: `in_fee`, `in_assets`, `in_fee` (protocol fee rate)

### Component D: USD conversion and aggregation

- **Purpose**: Normalizes all captured fee components into a single USD-denominated metric.
- **Logic**: All fee amounts are normalized by their respective asset decimal precision. Daily totals are multiplied by end-of-day price feeds for the relevant assets. Data is aggregated at a daily granularity using UTC day boundaries.
- **Key fields**: `block_timestamp`, `token_address`, `price_usd`

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

Portion of fees distributed to service providers or supply-side participants.

Supply-side fees

Liquid staking

github

OTokenOTOKEN

Supply-side fees

Supply-side fees

Chain breakdown