# Flying Tulip Lend Revenue Methodology

## 1. Overview

Revenue measures the total protocol-owned income generated by Flying Tulip Lend, capturing fees that flow directly to the Flying Tulip treasury rather than to borrowers or external liquidity providers. Two distinct fee streams are included: leverage fees collected when leveraged positions are opened, closed, or rebalanced, and liquidation fees collected as positions are partially or gradually unwound. Borrower interest paid to lenders is explicitly excluded, as it is classified as supply-side and does not constitute protocol revenue. Revenue is denominated in the fee asset of each transaction and converted to USD using end-of-day price feeds.

## 2. Data sources

- **Blockchain events**: `OpenLeverageFlashFilled`, `CloseLeverageFlashFilled`, and `CollateralSwapFlashFilled` events from `LeverageRfqEngine` contracts, and `LiquidationFeeCollected` events from `RfqEngine` contracts, covering Sonic
- **External data**: End-of-day price feeds for fee assets

## 3. Step-by-step calculation

### Component A: Leverage fee collection

- **Purpose**: Capture protocol fees earned when leveraged positions are opened, closed, or collateral-swapped via flash fills
- **Logic**: `OpenLeverageFlashFilled`, `CloseLeverageFlashFilled`, and `CollateralSwapFlashFilled` events are parsed from `LeverageRfqEngine` contracts on Sonic. The `amount` field is extracted from each event, denominated in the asset identified by the `feeToken` field. Only events from on or after the Flying Tulip Lend Sonic launch date (2026-03-23) are included. All three event types are unioned into a single fee stream.
- **Key fields**: `feeAmount` (fee quantity), `feeToken` (fee asset address)

### Component B: Liquidation fee collection

- **Purpose**: Capture protocol fees earned when undercollateralized positions are liquidated
- **Logic**: `LiquidationFeeCollected` events are parsed from `RfqEngine` contracts on Sonic. Because liquidations are executed gradually across multiple partial fills, multiple events may be emitted per position; all events are summed to capture total liquidation fees. The `amount` field is denominated in the asset identified by the `asset` field. Only events from on or after the Flying Tulip Lend Sonic launch date (2026-03-23) are included.
- **Key fields**: `amount` (fee quantity), `asset` (fee asset address)

### Component C: USD conversion and aggregation

- **Purpose**: Normalize raw fee amounts to USD and aggregate to daily granularity
- **Logic**: Leverage and liquidation fee events are combined. Amounts are normalized by decimal precision using asset metadata and multiplied by end-of-day prices matched on asset address, chain, and UTC day. Results are aggregated by day, chain, and product, with zero-filling applied on days where no fee events are observed.

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

Revenue

Lending

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.

Flying Tulip Lend

Revenue

Revenue

Chain breakdown