# Flying Tulip Options Revenue Methodology

## 1. Overview

Revenue measures the total protocol fees collected by Flying Tulip Options from options marketplace trades on Ethereum. All fees collected are attributed entirely to protocol revenue, with no supply-side allocation. Revenue is denominated in the trade asset of each transaction and converted to USD. Because the marketplace captures both maker and taker fees per trade, revenue reflects the full bilateral fee take on every settled options transaction.

## 2. Data sources

- **Blockchain events**: `Sold`, `NewListing`, and `BuyOfferAccepted` events from `OptionsMarketplace` contracts, covering Ethereum
- **External data**: End-of-day price feeds for trade assets

## 3. Step-by-step calculation

### Component A: Secondary sale fee extraction

- **Purpose**: Capture maker and taker fees from options sales settled via the secondary marketplace
- **Logic**: `Sold` events are parsed from `OptionsMarketplace` contracts. For each sale, the maker fee and taker fee fields are summed to produce a total fee amount per transaction. Because `Sold` events do not carry the fee asset directly, the fee token is resolved by joining to the most recent `NewListing` event for the same token ID at or before the sale's block number and log index. This ensures the correct asset denomination is applied even when an option has been relisted.
- **Key fields**: `makerFee` and `takerFee` (summed fee components), `tokenId` (used to resolve the fee asset via the listing join), `token` from the matched listing (fee asset address)

### Component B: Buy-offer settlement fee extraction

- **Purpose**: Capture maker and taker fees from options trades settled via accepted buy offers
- **Logic**: `BuyOfferAccepted` events are parsed from `OptionsMarketplace` contracts. The fee asset is carried directly within the event, so no listing join is required. The maker fee and taker fee fields are summed to produce a total fee amount per transaction.
- **Key fields**: `makerFee` and `takerFee` (summed fee components), `token` (fee asset address carried in-event)

### Component C: USD conversion and aggregation

- **Purpose**: Normalize raw fee amounts to USD for reporting
- **Logic**: Fee amounts from Components A and B are combined. Amounts are normalized by decimal precision using asset metadata and multiplied by end-of-day asset prices. Aggregation is performed at daily granularity using UTC day boundaries, grouped by chain and product.

*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

Derivative exchanges

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.

Perpetual PUT Marketplace

Revenue

Revenue

Chain breakdown