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 User Wau Methodology

## 1. Overview

Active users (weekly) measures the number of distinct wallet addresses that interact with Flying Tulip products within any given 7-day rolling window. Each address is counted once per 7-day window per product, providing a deduplicated view of weekly engagement across Flying Tulip USD, Flying Tulip Lend, and Flying Tulip Options. The Flying Tulip Yield product is intentionally excluded, as it holds the protocol's own backing capital rather than retail deposits, and therefore produces no meaningful active-user signal.

## 2. Data sources

- **Blockchain events**: `Minted` and `Redeemed` events from `MintAndRedeem` contracts; `Deposit`, `Withdraw`, `Borrow`, `Repay`, and `RepayFor` events from `PositionsManager` contracts; `Sold` and `BuyOfferAccepted` events from `OptionsMarketplace` contracts — covering Ethereum and Sonic

## 3. Step-by-step calculation

### Component A: Flying Tulip USD participant extraction

- **Purpose**: Identify wallet addresses that minted or redeemed Flying Tulip USD within a given 7-day window
- **Logic**: The recipient address field is extracted from `Minted` events to capture minters. The sender address field is extracted from `Redeemed` events to capture redeemers. Both address fields are unified under a single user address column, tagged with the Flying Tulip USD product identifier, on Ethereum and Sonic.

### Component B: Flying Tulip Lend participant extraction

- **Purpose**: Identify wallet addresses that deposited, withdrew, borrowed, or repaid through Flying Tulip Lend
- **Logic**: The user address field is extracted from `Deposit`, `Withdraw`, `Borrow`, and `Repay` events. For `RepayFor` events, the borrower address field is used rather than the caller, ensuring the beneficiary of the repayment is attributed as the active user. All addresses are tagged with the Flying Tulip Lend product identifier, on Ethereum and Sonic.

### Component C: Flying Tulip Options participant extraction

- **Purpose**: Identify wallet addresses that traded options through Flying Tulip Options
- **Logic**: Both the buyer address and the seller address fields are extracted from `Sold` and `BuyOfferAccepted` events from `OptionsMarketplace` contracts. Each side of a trade is recorded independently, so both counterparties are counted as active users. This component is limited to Ethereum only.

### Component D: Deduplication and weekly aggregation

- **Purpose**: Produce a distinct weekly count of active addresses per product and chain
- **Logic**: All extracted addresses from Components A through C are unioned together. Reverted transactions are excluded by filtering to events where the `removed` flag is false. Timestamps are truncated to UTC 7-day window boundaries, and distinct user addresses are selected per 7-day window, chain, and product. Chain availability filters are then applied to ensure data is clipped appropriately for archived or partially archived chains.

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

Unique revenue-generating users over a rolling 7-day window.

Flying TulipFT

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown