Fluid acts as a lending, vault, and DEX platform for seamless DeFi interaction.

Fluid is a non-custodial lending, vaults, and DEX protocol built by Instadapp. Instadapp was founded by Samyak Jain & Sowmay Jain and launched in 2018.

FLUID tokenholders own and govern the protocol. They currently earn a cut of the fees generated through Fluid lending, vault and DEX services. Instadapp's investors include Coinbase Ventures, Pantera Capital, Robot Ventures, etc.

github

twitter

etherscan

website

Lending

Fluid

# Fluid Average fees per user (AFPU) Methodology

## 1. Overview

Average fees per user (AFPU) is calculated as total daily fees divided by active users (daily), reflecting the average fee paid per active user over a fixed 24-hour window. Insight is provided into revenue efficiency and user monetization across Fluid's DeFi infrastructure platform, which is comprised of Fluid Vault, Fluid DEX, Fluid Lite, and Solana-based Jupiter Lend services. This metric is essential for evaluating the economic value generated per participant and assessing the overall growth and sustainability of the protocol's fee-generation mechanisms.

## 2. Data sources

- **Fees**: Derived from the Fees metric
- **Active users (daily)**: Derived from the Active users (daily) metric

## 3. Step-by-step calculation

### Component A: Fee revenue collection for Fluid Vault, Fluid DEX, Fluid Lite, and Jupiter Lend

- **Purpose**: To aggregate all fee-generating activities across Fluid Vault, Fluid DEX, Fluid Lite, and Jupiter Lend
- **Logic**: Five distinct revenue streams are combined into daily USD totals. Jupiter Lend fees are derived from interest accrued on active loan balances multiplied by protocol fee rates. Fluid Vault fees are calculated from daily borrow balance increases, excluding amounts from new borrowing operations to isolate interest accrual, with BNB Chain fees categorized under Venus Flux. Fluid DEX trading fees are calculated by multiplying the trade amount of the input asset (determined by the trade direction) by the applicable trade fee rate, with BNB Chain fees categorized under Venus Flux. Fluid DEX arbitrage fees are captured as the absolute difference between simultaneous supply and borrow operations on the same asset. Fluid Lite management fees are calculated by dividing collected revenue events by their corresponding fee rates to determine gross yield.
- **Key fields**: `interest_accrued_this_period`, `fee`, `total_borrow_vault`, `amount_0`, `amount_1`, `trade_fee_rate`, `supply_amount`, `borrow_amount`, `amount`

### Component B: Daily active user counting for Fluid Vault, Fluid DEX, Fluid DEX Lite, and Fluid Lite

- **Purpose**: Count distinct users across Fluid Vault, Fluid DEX, Fluid DEX Lite, and Fluid Lite using distinct count aggregation
- **Logic**: Unique active users (daily) are identified across four product categories. Fluid Vault users are extracted from `LogOperate` events from `FluidLiquidity` and `FluidLiquidityProxy` contracts by joining with transaction records to retrieve user addresses, with BNB Chain users categorized under Venus Flux. Fluid DEX traders are identified from `Swap` events from `FluidDex` and `FluidDexT1` contracts, with users resolved from transaction `from_address` fields, with BNB Chain users categorized under Venus Flux. Fluid DEX Lite traders are captured from `LogSwap` events from `FluidDexLite` contracts using similar transaction joins. Fluid Lite users are identified from `supplyLog`, `withdrawLog`, `Deposit`, and `Withdraw` events from asset management contracts. Users are categorized by user type and product for dimensional analysis.
- **Key fields**: `user_address`, `from_address`, `block_timestamp`, `transaction_hash`

### Component C: Fee tier and rate management

- **Purpose**: Apply correct fee rates and tiers based on temporal state changes
- **Logic**: Temporal joins are used to match trades and operations with their applicable fee structures at the time of execution. For Fluid DEX trades, the latest fee tier configuration that was active when the trade occurred is identified, with duplicate configurations resolved by selecting the lowest fee tier. For Jupiter Lend, rate model parameters are forward-filled, including single and dual-kink interest rate curves. For Fluid Lite vaults, fee rate intervals are applied based on when rates were updated through governance events.
- **Key fields**: `trade_fee_rate`, `fee_rate`, `block_number`, `rate_at_utilization_zero`, `rate_at_utilization_kink`

### Component D: USD conversion and decimal correction

- **Purpose**: Normalize all monetary amounts to USD using consistent pricing and decimal handling
- **Logic**: Asset amounts are normalized by decimal precision and converted to USD using end-of-day price feeds through temporal joins. Native asset conversions are handled by mapping placeholder addresses to wrapped asset equivalents across different chains. Decimal corrections are applied before USD conversion to avoid precision issues with large numbers.
- **Key fields**: `decimals`, `price_usd`, `token_address`, `chain_id`

### Component E: Final aggregation

- **Purpose**: Combine daily fees and active users to calculate the final average fees per user
- **Logic**: Daily fee totals are summed across all product categories and chains, while active users (daily) are aggregated using distinct count aggregation to handle overlapping users across products. All fees are converted to USD using end-of-day price feeds with temporal matching to ensure consistency. Both fees and users are aggregated to daily boundaries using day-truncation functions. Average fees per user (AFPU) is calculated by dividing the sum of all daily fees in USD by the count of distinct active users (daily), with zero-filling applied for days with no activity.
- **Key fields**: `fees`, `user_dau`, `afpu`

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

FluidFLUID

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape