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 Fees Methodology

## 1. Overview

Fees measures the total value generated across all Flying Tulip products, combining protocol revenue retained by the treasury with supply-side interest distributed to lenders. The metric spans four products: Flying Tulip USD (mint and redeem fees), Flying Tulip Yield (backing-capital Flying Tulip Yield harvested to the treasury), Flying Tulip Options (marketplace trading fees), and Flying Tulip Lend (leverage fees, liquidation fees, and borrower interest paid to lenders). For Flying Tulip USD, Flying Tulip Yield, and Flying Tulip Options, fees equal protocol revenue in full, as no supply-side participants receive a share. For Flying Tulip Lend, fees are the sum of protocol-retained revenue and the borrower interest distributed to lenders, reflecting a reserve factor of zero confirmed on-chain.

## 2. Data sources

- **Blockchain events**: `Minted` and `Redeemed` events from `MintAndRedeem` contracts (Flying Tulip USD); `YieldClaimed` events from `YieldWrapper` and `InvestorAaveWrapper` contracts (Flying Tulip Yield); `TokenRebased` and `TransferShares` events from `stETH` contracts via Lido V2 (Flying Tulip Yield treasury stETH leg); `Sold`, `NewListing`, and `BuyOfferAccepted` events from `OptionsMarketplace` contracts (Flying Tulip Options); `OpenLeverageFlashFilled`, `CloseLeverageFlashFilled`, and `CollateralSwapFlashFilled` events from `LeverageRfqEngine` contracts, `LiquidationFeeCollected` events from `RfqEngine` contracts, and `EpochSettled` events from `PositionsManager` contracts (Flying Tulip Lend); covering Ethereum and Sonic
- **External data**: End-of-day price feeds for all fee-denominated assets

## 3. Step-by-step calculation

### Component A: Flying Tulip USD mint and redeem fees

- **Purpose**: Capture fees charged on Flying Tulip USD minting and redemption operations
- **Logic**: `Minted` and `Redeemed` events are parsed from `MintAndRedeem` contracts on Ethereum and Sonic. The `feeFtUSDAmount` field from each event is extracted as the fee amount, denominated in Flying Tulip USD (a dollar-pegged stablecoin). Amounts are normalized by decimal precision and converted to USD using end-of-day price feeds for the Flying Tulip USD asset.

### Component B: Flying Tulip Yield — wrapper Flying Tulip Yield claims

- **Purpose**: Capture Flying Tulip Yield harvested to the treasury from Aave/Spark-deployed backing capital
- **Logic**: `YieldClaimed` events are parsed from `YieldWrapper` contracts (six asset wrappers) and `InvestorAaveWrapper` contracts (nine investor wrappers) on Ethereum. For `YieldWrapper` events, the fee token and amount are sourced from the `token` and `amount` fields respectively. For `InvestorAaveWrapper` events, the underlying asset and amount fields are used. All amounts are normalized by decimal precision and converted to USD.

### Component C: Flying Tulip Yield — treasury stETH rebase Flying Tulip Yield

- **Purpose**: Measure the daily stETH Flying Tulip Yield accruing to the treasury from Lido rebases, for which no direct claim event exists
- **Logic**: `TokenRebased` events from the `stETH` contract are used to compute a daily rebase ratio as `post_total_ether / post_total_shares`, taking the last rebase event of each UTC day. The ratio change from the prior day (`ratio − prev_ratio`) represents the per-share Flying Tulip Yield. Net treasury share flows are derived from `TransferShares` events where the treasury address appears as sender or recipient, summing received shares minus sent shares per day. Cumulative treasury shares held are computed as a running sum over the daily rebase spine. Daily Flying Tulip Yield is then calculated as `shares_held × (ratio − prev_ratio)`. Only days with a valid prior ratio, positive shares held, and a positive ratio change are included.

### Component D: Flying Tulip Options marketplace fees

- **Purpose**: Capture maker and taker fees from options trades on the Flying Tulip Options marketplace
- **Logic**: Two event types are parsed from `OptionsMarketplace` contracts on Ethereum. For `Sold` events, fees are computed as `makerFee + takerFee` per trade. The fee token is resolved by joining to the most recent `NewListing` event for the same `tokenId` at or before the sale block, using the `token` field from that listing. For `BuyOfferAccepted` events, the fee token is carried directly in the event's `token` field, and fees are again computed as `makerFee + takerFee`. Both legs are unioned and amounts are normalized by decimal precision and converted to USD.

### Component E: Flying Tulip Lend leverage fees

- **Purpose**: Capture protocol revenue from leveraged position operations on Flying Tulip Lend
- **Logic**: `OpenLeverageFlashFilled`, `CloseLeverageFlashFilled`, and `CollateralSwapFlashFilled` events are parsed from `LeverageRfqEngine` contracts on Sonic. The `feeAmount` field denominates the fee, and the corresponding fee asset is identified via the `feeToken` field. Only events on or after the Flying Tulip Lend Sonic launch floor date are included. Amounts are normalized by decimal precision and converted to USD.

### Component F: Flying Tulip Lend liquidation fees

- **Purpose**: Capture protocol revenue from gradual liquidations of undercollateralized positions
- **Logic**: `LiquidationFeeCollected` events are parsed from `RfqEngine` contracts on Sonic. Because liquidations are partial and incremental, multiple events may fire per position; all events are summed. The fee asset is identified via the `asset` field and the fee quantity via the `amount` field. Only events on or after the Flying Tulip Lend Sonic launch floor date are included. Amounts are normalized by decimal precision and converted to USD.

### Component G: Flying Tulip Lend supply-side fees (borrower interest)

- **Purpose**: Capture borrower interest distributed in full to lenders, reflecting the zero reserve factor
- **Logic**: `EpochSettled` events are parsed from `PositionsManager` contracts on Ethereum and Sonic. The `rewardAmount` field represents the full epoch interest distribution, denominated in the FT asset. Events are aggregated to daily granularity, then amounts are normalized by decimal precision and converted to USD using end-of-day FT asset price feeds.

### Component H: Aggregation

- **Purpose**: Combine all protocol revenue and supply-side fee components into a single Fees metric
- **Logic**: Protocol revenue components from Components A through F are unioned and aggregated to daily USD totals by product and chain. Supply-side fees from Component G are then unioned with these revenue totals. The resulting combined dataset is summed per day, product, and chain to produce the final Fees metric.

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

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

Flying TulipFT

Fees

Fees

Competitive landscape

Chain breakdown