# OToken Revenue Methodology

## 1. Overview

Revenue measures the portion of generated yield and fees that is retained by the protocol for OToken products. This metric includes protocol takes from staking rewards and yield-generating strategies across Origin Ether (OETH), superOETHb, and Origin Sonic (OS), as well as fees collected by the ARM (Automated Reward Manager). Revenue represents the project's earnings from its product offerings before the distribution of yield to supply-side participants.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: OToken Vault revenue collection

- **Purpose**: Captures the protocol's share of yield from Origin Ether (OETH), Origin Sonic (OS), and superOETHb vaults.
- **Logic**: `YieldDistribution` events are parsed from the respective vault contracts. The protocol revenue is extracted from the fee parameter within the event, which represents the portion of the distributed yield retained by the protocol. For superOETHb on Base, a fixed fee ratio of 25% is applied, while for other vaults, the ratio is determined by the relationship between the distributed yield and the collected fee.
- **Key fields**: `block_timestamp`, `token_address`, `in__fee` (representing protocol revenue)

### Component B: superOETHb rebase revenue calculation

- **Purpose**: Determines protocol revenue from rebasing events on the superOETHb product.
- **Logic**: For historical data on Base, rebase amounts are calculated by subtracting the net sum of mints and burns (sourced from `mint` and `burn` functions) from the total supply updates (sourced from `TotalSupplyUpdatedHighres` events). A 20% fee ratio is applied to the calculated rebase amount to determine protocol revenue. For more recent data, revenue is identified via ERC-20 `Transfer` events representing WETH sent from the dripper address to the superOETHb vault.
- **Key fields**: `block_timestamp`, `in_totalSupply`, `in__amount` (from functions), `value` (from transfers)

### Component C: ARM revenue and fee tracking

- **Purpose**: Captures revenue generated by the ARM product.
- **Logic**: Revenue is aggregated from two primary sources. Direct fee payments are parsed from `FeeCollected` events from `LidoARM` contracts. Additionally, daily yield is calculated by tracking the daily change in total assets (retrieved from contract state calls) and adjusting for the daily volume of `Deposit` and `RedeemRequested` events.
- **Key fields**: `block_timestamp`, `in_fee`, `in_assets`, `state_value`

### Component D: Normalization and USD conversion

- **Purpose**: Standardizes revenue values for cross-chain and cross-asset comparison.
- **Logic**: Revenue amounts are normalized by the decimal precision of the underlying assets. These normalized values are then multiplied by the respective end-of-day asset prices. All data is aggregated by day using UTC boundaries.
- **Key fields**: `revenue`, `token_address`, `price_usd`

*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.

OTokenOTOKEN

Revenue

Revenue

Chain breakdown