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 Active Loans Methodology

## 1. Overview

Active Loans measures the total value of outstanding borrows across all reserves in Flying Tulip Lend at daily granularity. Each reserve's outstanding borrow balance is captured as a point-in-time snapshot, providing a real-time view of credit utilization across the protocol. This metric is denominated in USD and serves as a key indicator of Flying Tulip Lend's capital deployment and demand for borrowing capacity.

## 2. Data sources

- **Blockchain state**: Daily reserve-level borrow balances sourced from `LendingLens` contract reads, capturing the `borrows` field per reserve address across all supported chains
- **External data**: End-of-day price feeds for borrowed assets, used to convert raw borrow balances to USD

## 3. Step-by-step calculation

### Component A: Outstanding borrow extraction

- **Purpose**: Identify the raw outstanding borrow balance for each reserve on each day
- **Logic**: Daily reserve state snapshots are read for each active reserve on Flying Tulip Lend. The `borrows` field from each snapshot represents the total outstanding principal owed by borrowers in that reserve. Records where `borrows` equals zero are excluded, retaining only reserves with active loan positions. The reserve address serves as the borrowed asset identifier.
- **Key fields**: `reserve_address` (identifies the borrowed asset), `borrows` (outstanding principal), `chain` (chain context)

### Component B: USD conversion

- **Purpose**: Normalize raw borrow balances to USD for cross-asset and cross-chain comparability
- **Logic**: Raw borrow amounts are normalized by the decimal precision of each asset, joined against asset metadata by chain and token address. Decimal-adjusted balances are then multiplied by end-of-day asset prices, matched on timestamp, chain, and token address.

### Component C: Forward-fill and aggregation

- **Purpose**: Ensure continuous daily time series without gaps
- **Logic**: Converted USD loan balances are aggregated by day, chain, and product (Flying Tulip Lend). Where a reserve has no new state snapshot for a given day, the most recent known balance is carried forward, reflecting that outstanding loans remain active until explicitly repaid or liquidated. Only balances corresponding to valid chain identifiers are retained.

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

Value of loans currently outstanding to borrowers.

Flying TulipFT

Active loans

Active loans

Competitive landscape

Chain breakdown