github

twitter

discord

etherscan

website

Liquid staking

Origin Protocol

# Origin Protocol Average revenue per user (ARPU) Methodology

## 1. Overview

ARPU measures the average daily revenue generated per active user of the Origin protocol. This metric is calculated by dividing total daily revenue by the number of daily active users across all Origin products and supported blockchain networks. ARPU helps assess the protocol's ability to monetize its user base and track revenue efficiency over time. The calculation combines revenue from yield distributions, rebase mechanisms, and fee collections, then divides by the count of unique users performing any protocol interaction each day.

## 2. Data sources

The ARPU calculation relies on several categories of blockchain data:

**Blockchain events**: Parsed contract events from multiple chains including:
- Ethereum `Mint`, `Redeem`, and `YieldDistribution` events from Origin vault contracts (Origin Dollar and OETH vaults)
- Base `Mint`, `Redeem`, `YieldDistribution`, and `TotalSupplyUpdatedHighres` events from superOETHb vault contracts
- Sonic `Mint`, `Redeem`, and `YieldDistribution` events from OS vault contracts
- Ethereum ARM-related events including `FeeCollected`, `Zap`, and `RedeemClaimed` events
- Ethereum `FeeUpdated` events for ARM protocol fee rate tracking

**Transaction data**: 
- Ethereum parsed function calls from Flipper contracts for Origin Dollar trading activities
- Arbitrum parsed function calls from woETH contracts for minting and burning
- Base token transfer events for WETH transfers from dripper to vault contracts

**Token transfer events**:
- Ethereum token transfers for ARM ERC4626 minting detection (from null address to zapper)
- Base WETH transfers from specific dripper contracts to vault addresses

**External data**: 
- End-of-day token price feeds for USD conversion of revenue amounts
- Token metadata for proper decimal handling and price matching

## 3. Step-by-step calculation

### Component A: Daily active user calculation
- **Purpose**: Count unique addresses interacting with Origin protocol each day
- **Logic**: Collect all user addresses from various Origin protocol interactions across Ethereum, Base, Sonic, and Arbitrum. This includes users minting or redeeming Origin Dollar, OETH, superOETHb, and OS tokens through vault contracts, users interacting with zapper contracts for streamlined deposits, users trading Origin Dollar through Flipper contracts, users depositing or withdrawing from ARM contracts, and users minting or burning woETH on Arbitrum. Events are filtered to only include successful transactions, and addresses are deduplicated using HyperLogLog aggregation to handle users active across multiple products or chains
- **Key fields**: Extract `user_address` from event parameters like `_addr`, `sender`, `minter`, `withdrawer`, and function call `from_address` fields, along with `block_timestamp` for daily bucketing and `chain` for cross-chain tracking

### Component B: Revenue from yield distributions
- **Purpose**: Capture protocol revenue from vault yield distribution events
- **Logic**: Extract yield distribution amounts from `YieldDistribution` events across all Origin vaults on Ethereum, Base, and Sonic. For each event, the `yield` field represents the protocol's revenue portion from yield generation. Fee ratios are applied differently per chain: Base uses a fixed 25% fee ratio while other chains extract the ratio from event data by dividing fee by yield amounts. Revenue amounts are converted from wei to standard token units by dividing by 10^18
- **Key fields**: Extract `yield` amounts, `fee` amounts for ratio calculation, `token_address` for price conversion, and `block_timestamp` for daily aggregation

### Component C: Revenue from Base rebase yields
- **Purpose**: Calculate implied yield revenue from Base superOETHb rebase mechanics
- **Logic**: For Base superOETHb before block 24827918, calculate rebase amounts using the formula: Total Supply - (Cumulative Mints - Cumulative Withdrawals). Track all mint and burn functions alongside `TotalSupplyUpdatedHighres` events to determine the rebase component of supply changes. Apply an 80/20 split where 80% goes to users and 20% represents protocol fee revenue. After certain blocks, use direct WETH transfers from dripper contracts to vault as the yield source. Remove specific outlier dates and apply the same fee ratio logic
- **Key fields**: Use `totalSupply` from supply update events, `amount` from mint and burn functions, `value` from token transfer events, with precise block number and log index tracking for chronological ordering

### Component D: Revenue from ARM fees
- **Purpose**: Capture ARM protocol fee revenue from multiple sources
- **Logic**: Combine ARM fees from two sources: direct fee collection events that emit `FeeCollected` events with fee amounts, and implied fees from ARM ERC4626 minting detected through token transfers from null address to zapper contracts. For fee collection events, extract the fee amount directly. For ERC4626 minting, the minted amount represents fee revenue. Apply protocol fee rates from `FeeUpdated` events by matching token addresses and using the most recent fee rate setting before each revenue event
- **Key fields**: Extract `fee` amounts from fee collection events, `value` amounts from token transfers, `protocol_fee_rate` from fee update events, with proper temporal matching using block numbers and log indices

### Final aggregation
- **Combining components**: Sum all revenue sources (yield distributions, Base rebase yields, ARM fees) by day, ensuring no double-counting across different revenue streams. Each revenue amount is converted to USD using end-of-day price feeds matched by token address and date
- **Currency conversion**: Apply end-of-day USD prices to each token amount after converting from wei decimals. Price conversion occurs after daily aggregation to use consistent daily exchange rates
- **Time aggregation**: Group all revenue and user data by day using timestamp truncation to daily boundaries. Handle timezone considerations by using UTC day boundaries consistently across all data sources
- **Final calculation**: Divide total daily revenue (in USD) by daily active user count to produce ARPU. Apply forward-filling with zeros for days with missing revenue or user data to maintain continuous time series. The result represents average USD revenue generated per active user per day across all Origin protocol products and chains

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

Origin ProtocolOGN

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape