Users deposit yield-bearing tokens into Pendle Markets. The yield-bearing token is wrapped and split up into its principal and yield-bearing components, which allows users to execute yield-trading strategies (i.e. earn fixed yield, long yield). Traders pay a swap fee whenever yield-bearing tokens are swapped with its wrapped, principal, or yield-bearing component tokens.

Pendle is a permissionless yield-trading protocol built on Ethereum, HyperEVM, Arbitrum, BNB Chain, Optimism, Base, Berachain, Sonic, Plasma, Monad, X Layer, and Robinhood Chain. Pendle was founded by TN Lee and was launched in 2021.

PENDLE tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

github

twitter

discord

etherscan

website

Asset management

Pendle

# Pendle Average revenue per user (ARPU) Methodology

## 1. Overview

Average revenue per user (ARPU) measures the revenue generated per active user over a fixed 24-hour window. It is calculated as total daily revenue divided by active users (daily), and reflects how much the project is able to monetize an individual user on a daily basis. The average value extracted from each user engaging with Pendle AMM, Pendle Limit Order, Pendle Yield Tokenization, vePendle, and Boros is reflected by this metric.

## 2. Data sources

- **Revenue**: Derived from the Revenue metric
- **Active users (daily)**: Derived from the Active users (daily) metric

## 3. Step-by-step calculation

### Component A: active users (daily) calculation

- **Purpose**: Unique users interacting with Pendle trading products are counted each day.
- **Logic**: The `from_address` field is extracted from blockchain transactions containing `Swap` events from `Market` contracts across all supported chains. Transactions are filtered to include only trading transactions, excluding non-user activity. User addresses are grouped by day, and the count of unique active users is aggregated daily.
- **Key fields**: `user_address` (derived from transaction `from_address`), `block_timestamp` for daily grouping, `chain` for cross-chain aggregation

### Component B: Pendle AMM trading revenue calculation

- **Purpose**: Revenue from automated market maker trading fees is calculated.
- **Logic**: `Swap` events from `Market` contracts are processed, and `netSyFee` amounts are extracted. These amounts are joined with SY asset price conversion rates. An 80% fee retention rate is applied, as 20% is allocated to liquidity providers. Special decimal scaling is handled for BTC assets on specific chains. Fee amounts are multiplied by SY conversion rates and normalized to underlying asset decimals.
- **Key fields**: `netSyFee` for fee amounts, `netSyOut` for volume tracking, `market_address` for price ratio matching

### Component C: Pendle Limit Order revenue calculation
- **Purpose**: Revenue from limit order trading fees is calculated.
- **Logic**: `OrderFilledV2` events from `LimitRouter` contracts are processed, and `feeAmount` values are extracted. A 100% fee retention rate is applied. These values are joined with YT-to-PT asset mappings and SY conversion rates. Special decimal adjustments are handled for BTC assets, and SY exchange rates are applied for accurate USD conversion.
- **Key fields**: `feeAmount` for revenue amounts, `notionalVolume` for volume tracking, `YT` asset addresses for mapping

### Component D: Pendle Yield Tokenization revenue calculation

- **Purpose**: Revenue from YT asset interest and reward fees is calculated.
- **Logic**: `CollectInterestFee` and `CollectRewardFee` events from `YT` contracts (including versions V5, V6, and V7) are processed. SY conversion rates are applied to normalize interest fees to underlying asset values. Reward asset fees are extracted directly without conversion. Appropriate decimal corrections are applied based on underlying asset precision.
- **Key fields**: `amountInterestFee` and `amountRewardFee` for revenue amounts, `rewardToken` addresses for reward fees

### Component E: Treasury and vePendle revenue calculation

- **Purpose**: Revenue distributed to vePendle holders and the protocol treasury is calculated.
- **Logic**: Asset transfers to designated treasury and distributor contract addresses are tracked across all supported chains. USDT transfers are filtered out to prevent double-counting of primary fees. SY conversion rates are applied where applicable, and amounts are normalized to underlying asset values.
- **Key fields**: `value` amounts from asset transfers, `to_address` and `from_address` for filtering

### Component F: Boros trading revenue calculation

- **Purpose**: Revenue from Boros perpetual trading products is calculated.
- **Logic**: Fees are aggregated from multiple Boros event types, including `MarketOrdersFilled`, `SwapWithAmm`, `SingleOrderExecuted`, `PaymentFromSettlement`, `Liquidate`, and `OtcSwap` events from `BorosMarket` and `BorosRouter` contracts. Fee amounts are extracted from each event type and normalized by decimal precision. Conversion to USD is performed using end-of-day price feeds.
- **Key fields**: Various fee fields (`totalFees`, `otcFee`, `liqFee`, `takerOtcFee`, etc.) depending on event type

### Component G: SY exchange rate normalization

- **Purpose**: Accurate pricing ratios for SY (standardized yield) assets are calculated.
- **Logic**: SY `Deposit` events from `SY` contracts (including versions V2 to V7) are processed to calculate base asset to SY asset ratios. Daily deposits are aggregated, and `base_amount / sy_amount` ratios are calculated. Missing days are carried forward from the previous day's ratio. Denylisted assets that represent 1:1 base asset deposits are handled. These ratios are used to convert SY-denominated fees to underlying asset values.
- **Key fields**: `amountDeposited` and `amountSyOut` for ratio calculation, `tokenIn` for asset identification

### Component H: Final aggregation

- **Purpose**: All revenue components are combined, and the final ARPU metric is calculated.
- **Logic**: All revenue components (AMM fees, limit order fees, YT fees, treasury transfers, and Boros fees) are summed by day, chain, and product. USD conversion is applied using end-of-day price feeds, and proper decimal corrections are made for each asset type. Timestamps are truncated to daily boundaries and aggregated by day to ensure consistent time alignment between revenue and user metrics. Finally, total daily revenue (in USD) is divided by total active users (daily), and a zero-fill strategy is applied for days with no activity to maintain complete time series data.

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

PendlePENDLE

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape