# OToken Fees Methodology

## 1. Overview

Fees measures the total economic value generated by OToken products, including Origin Ether (OETH), Origin Sonic (OS), and superOETHb. The metric captures yield-based performance fees, redemption fees paid by users exiting positions, and fees generated by the Automated Reward Manager (ARM). These fees represent the total value paid by users or captured by the protocol from yield-bearing activities and vault interactions.

## 2. Data sources

- **Blockchain events**: `Redeem`, `YieldDistribution`, `RedeemFeeUpdated`, `Vault_RedeemFeeUpdated`, `OETHVault_RedeemFeeUpdated`, `OSVault_RedeemFeeUpdated`, and `superOETHbVault_RedeemFeeUpdated` events from vault contracts; `Deposit`, `RedeemRequested`, `FeeCollected`, and `FeeUpdated` events from `LidoARM` contracts; `TotalSupplyUpdatedHighres` events and `mint` and `burn` function calls on Base; and ERC-20 token transfers from dripper contracts, covering Ethereum, Base, and Sonic
- **External data**: End-of-day price feeds for the underlying assets

## 3. Step-by-step calculation

### Component A: Yield performance fees

- **Purpose**: Captures the protocol's share of yield generated from liquid staking and DeFi strategies for OToken products.
- **Logic**: Fees are extracted from `YieldDistribution` events emitted by OToken vault contracts. For the superOETHb product on Base, yield is calculated prior to a specific block height by determining the difference between the total asset supply and the net cumulative flows (mints minus burns); after this block, fees are identified as specific ERC-20 transfers from the reward dripper contract to the vault. All calculated rebase amounts are adjusted to represent gross yield values.
- **Key fields**: `in__yield`, `in_totalSupply`, `in__amount`

### Component B: Redemption fees

- **Purpose**: Measures the fees paid by users when redeeming OToken assets for underlying collateral.
- **Logic**: Transaction data is parsed from `Redeem` events across the various OToken vault contracts. A redemption fee rate is determined by tracking the most recent `RedeemFeeUpdated` events for each specific vault. The total fee for each redemption is calculated by multiplying the redemption value by the applicable fee rate at the time of the transaction.
- **Key fields**: `in__value` (redeem amount), `in__redeemFeeBps` (fee rate)

### Component C: Automated Reward Manager (ARM) fees

- **Purpose**: Captures fees generated specifically through the ARM product.
- **Logic**: Fees are identified through two primary methods. First, direct fee payments are parsed from `FeeCollected` events emitted by `LidoARM` contracts. Second, total yield is calculated by tracking daily changes in total assets (retrieved via contract state calls) and adjusting for the net change in cumulative deposits and withdrawals parsed from `Deposit` and `RedeemRequested` events.
- **Key fields**: `in_fee`, `in_assets`, `state_value` (total assets)

### Component D: Normalization and USD conversion

- **Purpose**: Standardizes all collected fee components into a single USD-denominated metric.
- **Logic**: All identified fee amounts are normalized by decimal precision based on the specific asset. Daily totals are aggregated by product and chain using UTC day boundaries. The resulting values are multiplied by end-of-day price feeds to determine the final USD value.
- **Key fields**: `block_timestamp`, `token_address`, `price_usd`

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

Total value users pay to use a protocol (gross fees, user-paid fees).

Fees

Liquid staking

github

OTokenOTOKEN

Fees

Fees

Chain breakdown