Users deposit single assets into wrapper contracts. Flying Tulip deploys these deposits into automated yield strategies (e.g., Aave V3) across Ethereum, Sonic, BNB Chain, Avalanche, and Base, maximizing capital efficiency.

Flying Tulip is a multi-chain yield aggregation protocol that pools user deposits into wrapper contracts and deploys them into automated yield strategies. The protocol supports assets including USDC, wETH, USDT, USDS, USDTb, and USDe, and uses an omnichain FT token to align incentives across its five supported networks.

FT tokenholders own and govern the Flying Tulip protocol. Flying Tulip is a yield aggregation protocol backed by partnerships with major DeFi protocols.

website

twitter

Asset management

Flying Tulip

# Flying Tulip Arpu Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily protocol revenue generated per active user across Flying Tulip's product suite, including Flying Tulip USD, Flying Tulip Lend, Flying Tulip Options, and Flying Tulip Yield. This metric is used to assess the monetization efficiency of the protocol and how revenue scales relative to its active user base. ARPU is expressed in USD and is computed at the project level, aggregating across all products and chains rather than being broken down per product or chain.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: Daily revenue aggregation

- **Purpose**: Establish total protocol revenue per day as the numerator for ARPU
- **Logic**: Daily revenue figures are sourced from the Revenue metric, which captures all fees routed to the Flying Tulip treasury across Flying Tulip USD, Flying Tulip Lend, Flying Tulip Options, and Flying Tulip Yield. Revenue values denominated in each respective asset are normalized by decimal precision and converted to USD using end-of-day price feeds. These per-product, per-chain revenue amounts are then summed across all products and chains to produce a single project-level daily revenue total.

### Component B: Daily active user aggregation

- **Purpose**: Establish the total count of distinct active users per day as the denominator for ARPU
- **Logic**: Distinct active user counts are sourced from the User Dau metric at the project level, collapsing across all chains, products, and user types (Minters, Redeemers, Depositors, Borrowers, and Traders) into a single deduplicated project-wide count per day. The Flying Tulip Yield product is intentionally excluded from the active user count, as it holds the protocol's own backing capital rather than retail deposits.

### Component C: ARPU computation

- **Purpose**: Divide daily revenue by active users (daily) to produce ARPU
- **Logic**: ARPU is calculated as `revenue / active users (daily)` for each day where both a revenue value and a non-zero active user count are present. The join is performed on the daily timestamp at the project level. Days for which no active users are recorded result in a zero fill rather than a division, avoiding undefined values.

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

Flying TulipFT

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape