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

## 1. Overview

Revenue measures the total protocol income accrued to the Flying Tulip treasury across all products: Flying Tulip USD, Flying Tulip Yield, Flying Tulip Options, and Flying Tulip Lend. Because no supply-side participants receive a share of fees in the Flying Tulip USD, Flying Tulip Yield, or Flying Tulip Options products, fees and revenue are equivalent for those products. For Flying Tulip Lend, only leverage and liquidation fees are classified as revenue; borrower interest payments flow entirely to supply-side lenders and are excluded. All fee amounts are denominated in their native assets, normalized by decimal precision, and converted to USD using end-of-day asset prices.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: Flying Tulip USD mint and redeem fee collection

- **Purpose**: Capture fees charged on Flying Tulip USD minting and redemption operations
- **Logic**: `Minted` and `Redeemed` events from `MintAndRedeem` contracts are parsed on both Ethereum and Sonic. The `feeFtUSDAmount` field from each event is extracted as the fee amount, denominated in Flying Tulip USD (a dollar-pegged stablecoin). Both mint and redeem events are unioned and treated as 100% protocol revenue with no supply-side allocation.
- **Key fields**: `feeFtUSDAmount` (fee quantity in Flying Tulip USD)

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

- **Purpose**: Capture Flying Tulip Yield harvested from Aave- and Spark-deployed backing capital held in Flying Tulip Yield wrapper contracts
- **Logic**: `YieldClaimed` events from `YieldWrapper` contracts are parsed, extracting the `amount` field denominated in the `token` field. Separately, `YieldClaimed` events from `InvestorAaveWrapper` contracts are parsed, extracting the `amount` field denominated in the `underlying` field. Both sets of events are unioned and treated as 100% protocol revenue, as the wrappers hold Flying Tulip's own and investor backing capital rather than retail deposits.
- **Key fields**: `amount` (Flying Tulip Yield quantity), `token` / `underlying` (fee-denominating asset)

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

- **Purpose**: Measure daily Flying Tulip Yield earned on stETH shares held in the treasury, derived from Lido rebase events rather than explicit claim events
- **Logic**: The latest `TokenRebased` event from `stETH` contracts per UTC day is selected, and a daily rebase ratio is computed as `postTotalEther / postTotalShares`. The prior day's ratio is lagged to produce a daily ratio increment. Concurrently, net treasury share flows are derived from `TransferShares` events on `stETH` contracts by summing inbound shares to the treasury address and subtracting outbound shares per day. A cumulative running sum of net share flows is maintained over the rebase day spine to produce daily shares held. Daily stETH Flying Tulip Yield is then calculated as `shares_held × (ratio − prev_ratio)` and included only on days where shares are positive and the ratio has increased. This Flying Tulip Yield is classified as 100% protocol revenue.
- **Key fields**: `postTotalEther`, `postTotalShares` (for ratio computation); `sharesValue`, `to`, `from` (for net share flow tracking)

### 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 processed on Ethereum. For `Sold` events from `OptionsMarketplace` contracts, the combined fee is computed as `makerFee + takerFee`. Because `Sold` events do not carry the fee-denominating asset directly, the fee token is resolved by joining to the most recent `NewListing` event from `OptionsMarketplace` contracts with a matching `tokenId` at or before the sale's block number; the `token` field from that listing record is used as the fee asset. For `BuyOfferAccepted` events from `OptionsMarketplace` contracts, the fee token is available directly in the event as the `token` field, and the combined fee is again computed as `makerFee + takerFee`. Both legs are unioned and treated as 100% protocol revenue.
- **Key fields**: `makerFee`, `takerFee` (fee components); `tokenId` (listing join key); `token` (fee asset)

### Component E: Flying Tulip Lend leverage fees

- **Purpose**: Capture protocol fees from leveraged position operations on Flying Tulip Lend
- **Logic**: `OpenLeverageFlashFilled`, `CloseLeverageFlashFilled`, and `CollateralSwapFlashFilled` events from `LeverageRfqEngine` contracts are parsed on Sonic. The `feeAmount` field is extracted as the protocol fee, denominated in the `feeToken` field. Events are filtered to those at or after the Flying Tulip Lend Sonic launch date. All three flash-filled variants are unioned and classified as protocol revenue.
- **Key fields**: `feeAmount` (fee quantity), `feeToken` (fee-denominating asset)

### Component F: Flying Tulip Lend liquidation fees

- **Purpose**: Capture protocol fees collected during position liquidations on Flying Tulip Lend
- **Logic**: `LiquidationFeeCollected` events from `RfqEngine` contracts are parsed on Sonic, filtered to events at or after the Flying Tulip Lend Sonic launch date. Because liquidations are partial and gradual, multiple events may fire per position; all events are summed to capture the full liquidation fee. The `amount` field denominated in the `asset` field is used as the fee quantity, classified as 100% protocol revenue.
- **Key fields**: `amount` (fee quantity), `asset` (fee-denominating asset)

### Component G: USD conversion and aggregation

- **Purpose**: Normalize all fee amounts to USD and aggregate to daily granularity
- **Logic**: Raw token amounts from all six components are unioned. Amounts are normalized by decimal precision using asset metadata and then multiplied by end-of-day asset prices. The resulting USD values are aggregated by UTC day, product, and chain. Daily granularity is maintained 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.

Flying TulipFT

Revenue

Revenue

Competitive landscape

Chain breakdown