# Flying Tulip Lend Fees Methodology

## 1. Overview

Fees measures the total value generated by Flying Tulip Lend, combining protocol revenue from leverage and liquidation activity with supply-side interest distributed to lenders. The metric captures two economically distinct flows: fees retained by the protocol treasury (leverage fills and liquidation charges) and borrower interest paid out entirely to lenders (supply-side fees). Because the reserve factor is confirmed at zero on-chain, no portion of borrower interest is retained by the protocol — lenders receive 100% of interest distributions, denominated in FT. All fee components are converted to USD using end-of-day asset prices.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: Leverage fee collection

- **Purpose**: Capture protocol revenue from leveraged position opens, closes, and collateral swaps
- **Logic**: `OpenLeverageFlashFilled`, `CloseLeverageFlashFilled`, and `CollateralSwapFlashFilled` events are parsed from `LeverageRfqEngine` contracts on Sonic. The `amount` field is extracted from each event, denominated in the `feeToken` specified per event. Events from Ethereum-deployed contracts are excluded as those engines carry zero fills. Only events at or after the Flying Tulip Lend Sonic launch date (2026-03-23) are included.
- **Key fields**: `feeAmount` (fee quantity), `feeToken` (asset denomination)

### Component B: Liquidation fee collection

- **Purpose**: Capture protocol revenue from gradual liquidation of undercollateralized positions
- **Logic**: `LiquidationFeeCollected` events are parsed from `RfqEngine` contracts on Sonic. Because liquidations are partial and incremental, multiple events fire per position; all events are summed to arrive at total liquidation fees. The `amount` field is extracted, denominated in the `asset` field of each event. The same Sonic-only and date floor constraints apply as in Component A.
- **Key fields**: `amount` (fee quantity), `asset` (asset denomination)

### Component C: Flying Tulip Lend supply-side interest distribution

- **Purpose**: Capture borrower interest distributed to lenders as supply-side fees
- **Logic**: `EpochSettled` events are parsed from `PositionsManager` contracts on both Sonic and Ethereum. The `rewardAmount` field represents the full interest distribution for each settled epoch, denominated in FT (18 decimals). All `EpochSettled` events within a day are summed to produce a daily supply-side fee total per chain. The reserve factor is zero on-chain, so no portion is withheld by the protocol — the entire `rewardAmount` is classified as supply-side fees.
- **Key fields**: `rewardAmount` (interest distribution quantity)

### Component D: USD conversion and aggregation

- **Purpose**: Normalize all fee components to USD for cross-asset comparability
- **Logic**: Raw token amounts from Components A, B, and C are normalized by decimal precision using asset metadata and multiplied by end-of-day asset prices. Protocol revenue (Components A and B) and supply-side fees (Component C) are aggregated separately by day and chain, then unioned to produce total fees. The final metric represents the sum of protocol-retained fees and lender interest distributions at daily UTC granularity.

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

Total value users pay to use a protocol (gross fees, user-paid fees).

Fees

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

Fees

Fees

Chain breakdown