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

# DEX trading volume methodology

## 1. Overview

DEX trading volume is the total value of trades involving a specific asset executed on decentralized exchanges, broken out by the exchange and product where the trade was executed (venue). Integrated venues include Uniswap, Aerodrome, PancakeSwap, and Fluid, among others, with coverage expanding as more are added.

## 2. Data sources

- **EVM chain events**: Swap and trade events from decentralized exchange contracts, covering EVM-compatible chains (Ethereum, Arbitrum, Base, Polygon, Optimism, and others)
- **Solana instructions**: Swap and trade instructions from decentralized exchange programs, covering Solana
- **Hyperliquid native spot**: Spot trading data from Hyperliquid
- **Asset metadata**: Token addresses and decimal precision
- **External data**: End-of-day price feeds

## 3. Step-by-step calculation

### Component A: Extract trade events and instructions

- **Purpose**: Retrieve raw trade data from decentralized exchange contracts, programs, and native spot feeds.
- **Logic**: On EVM-compatible chains, swap and trade events are parsed from decentralized exchange contracts. On Solana, swap and trade instructions are parsed from decentralized exchange programs. For each trade, the raw amounts of both traded tokens (the token sold and the token bought) are extracted along with the pool address, chain, and product identifier. For Hyperliquid, native spot trading volume is retrieved directly.
- **Key fields**: `amount_0` (raw quantity of first token), `amount_1` (raw quantity of second token), `token_address_0` (address of first token), `token_address_1` (address of second token), `timestamp` (block timestamp), `trading_volume` (raw trading volume for native spot)

### Component B: Normalize amounts and apply valuation

- **Purpose**: Normalize token quantities and calculate the USD value of the trade.
- **Logic**: Raw token amounts are normalized by decimal precision retrieved from asset metadata. Normalized amounts are multiplied by end-of-day price feeds from the price pipeline. To mitigate wash trading and mispricing, a conservative valuation is typically applied where the total trading volume of the trade is determined by taking the lesser USD value of the two legs (the token sold and the token bought). However, for trades involving exactly one tokenized stock, the valuation is determined solely by the tokenized-stock leg to prevent mispricing from unpriced counterparties. Hyperliquid native spot trading volume is retrieved pre-valued and is not subject to this valuation logic.
- **Key fields**: `trading_volume` (calculated USD value of the trade), `token_address_0` (address of first token), `token_address_1` (address of second token)

### Component C: Resolve trade legs and final aggregation

- **Purpose**: Attribute trading volume to each individual asset and aggregate by venue.
- **Logic**: Each trade is typically split into two distinct legs to represent both sides of the transaction, where one leg is categorized as a sell for the token sold by the trader, and the other leg is categorized as a buy for the token bought by the trader. Hyperliquid native spot trading volume is excluded from this split as it is retrieved pre-split by trade direction. The trading volume is then aggregated by summing the USD values across trade directions, assets, chains, and venues.
- **Key fields**: `trade_direction` (direction of the trade leg), `token_address` (resolved token address), `trading_volume` (aggregated USD volume)

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

Value of trades involving the asset on decentralized exchanges, counted on both sides of each trade, broken out per venue.

Flying TulipFT

DEX trading volume

DEX trading volume

Competitive landscape

Chain breakdown

Venue breakdown