# User Mau Methodology

## 1. Overview

Active users (monthly) measures the number of distinct wallet addresses that interact with Flying Tulip Lend over a 30-day rolling window. Each address is counted once per 30-day window regardless of how many transactions are performed, making this metric a reliable indicator of unique monthly engagement with the lending protocol. Both depositor and borrower activity are captured, reflecting the full range of supply-side and demand-side participation in Flying Tulip Lend.

## 2. Data sources

- **Blockchain events**: `Deposit`, `Withdraw`, `Borrow`, `Repay`, and `RepayFor` events from Flying Tulip contracts, covering Ethereum and Sonic

## 3. Step-by-step calculation

### Component A: Participant address extraction

- **Purpose**: Identify the wallet address associated with each lending interaction
- **Logic**: For `Deposit`, `Withdraw`, `Borrow`, and `Repay` events, the `u` field is extracted as the participant address. For `RepayFor` events, the `borrower` field is used instead, capturing the address of the borrower on whose behalf the repayment is made. Each extracted address is tagged with a user type — either Depositor (from `Deposit` and `Withdraw` events) or Borrower (from `Borrow`, `Repay`, and `RepayFor` events). Only non-removed events are included.

### Component B: Monthly aggregation

- **Purpose**: Ensure each address is counted once per 30-day window per chain
- **Logic**: Addresses are deduplicated by truncating block timestamps to the 30-day window boundary. A distinct set of addresses is produced per 30-day window, chain, and user type, so a wallet that deposits and borrows within the same 30-day window contributes one record per user type but is not double-counted within a single type.

### Component C: Chain availability filtering

- **Purpose**: Exclude data outside approved freshness windows
- **Logic**: Each chain's data is joined against a chain freshness reference. For active chains, only rows up to the last approved timestamp are included. For archived chains, rows are clipped at the archived date, except where the archival strategy is designated as project-only, in which case historical data passes through without clipping.

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

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

Active users (monthly)

Lending

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.

Flying Tulip Lend

Active users (monthly)

Active users (monthly)

Chain breakdown