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

# Asset transfer count methodology

## 1. Overview

Asset transfer count is defined as the number of user transactions that move assets between addresses. It is utilized to reflect how frequently assets are used for payments, trading, or other onchain activity. The metric is calculated daily for each tracked asset across all supported blockchains. By aggregating these transfer events, a comprehensive view of onchain utility and transactional velocity is provided.

## 2. Data sources

- **EVM chain events**: ERC-20 token transfers, covering EVM-compatible chains (Ethereum, Arbitrum, Base, Polygon, Optimism, and others)
- **Solana instructions**: SPL token transfers
- **Other blockchain events**: Token transfers, withdrawals, and mint events across non-EVM chains (Solana, Aptos, Near, Polkadot Asset Hub, Stellar, and others)
- **Asset metadata**: Token addresses and decimal precision

## 3. Step-by-step calculation

### Component A: Extract and count raw transfer events

- **Purpose**: Identify and count individual token transfer events on a daily basis for each asset.
- **Logic**: On EVM-compatible chains, ERC-20 token transfers are parsed and counted. On Solana, SPL token transfers are parsed and counted. On Aptos, Near, and Ripple, token transfers and withdrawals are parsed and counted. On Stellar, classic token withdrawals and Soroban token transfers are aggregated. On Sui, token withdrawals and token mint events are aggregated. On Cardano, UTXO withdrawals and token mint events are aggregated. On Polkadot Asset Hub, `Transferred` events from the `assets` pallet are parsed.
- **Key fields**: `token_address`: The unique identifier of the token contract or asset. `block_timestamp`: The timestamp of the transaction block.

### Component B: Daily aggregation and zero-filling

- **Purpose**: Aggregate the daily transfer counts per asset and ensure continuous time-series data.
- **Logic**: The extracted transfer counts are aggregated daily for each token address on its respective chain. For days where no transfer activity is recorded for a tracked asset, the time series is filled with zero values to ensure a continuous daily record.
- **Key fields**: `timestamp`: The day of the activity. `asset_transfer_count`: The daily count of transfers per token on a specific chain.

### Component C: Final aggregation

- **Purpose**: Combine the daily transfer counts across all supported chains for each asset.
- **Logic**: The daily transfer counts from all individual chains are combined. Token addresses are mapped to unique asset identifiers using asset metadata. The final daily asset transfer count is then aggregated across all chains for each asset.
- **Key fields**: `timestamp`: The day of the activity. `asset_transfer_count`: The total aggregated daily transfer count for the asset.

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

Number of transfer transactions involving the asset.

Flying TulipFT

Asset transfer count

Asset transfer count

Competitive landscape

Chain breakdown