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 Fees Methodology

## 1. Overview

The Instadapp fees metric measures total fee revenue generated across Instadapp's five product lines: Jupiter Lending (Solana), Fluid Vaults, Fluid Fluid DEX trading, Fluid DEX arbitrage operations, and Fluid Lite asset management. The metric captures both interest-based fees (lending, borrowing) and performance-based fees (trading, asset management) by analyzing blockchain events, state changes, and operational data across multiple chains. Each component calculates fees in native tokens before converting to USD and aggregating daily.

## 2. Data sources

- **Solana program instructions**: Liquidity program instruction logs for Jupiter lending operations, including borrow/repay events, supply/withdrawal events, interest rate model updates, and fee configuration changes
- **Multi-chain event logs**: Parsed `Swap` events from FluidDex contracts on Ethereum, Arbitrum, Base, and Polygon; `LogSwap` events from FluidDexLite contracts on Ethereum; `LogOperate` events from FluidLiquidity contracts across supported chains
- **Fluid Vault state snapshots**: Daily API call results to Instadapp Fluid Vault contracts providing total supply/borrow balances across three ABI versions (v0, v1, v2)
- **Asset management events**: Revenue collection events (`collectRevenueLog_event`, `LogCollectRevenue_event`) and fee rate change events from Fluid Lite Fluid Vault contracts on Ethereum
- **State snapshots**: Daily unclaimed revenue amounts from Fluid Lite Fluid Vault state variables and Fluid DEX pool configuration data
- **End-of-day price feeds**: Token price data for USD conversion across all supported chains and tokens
- **Token metadata**: Decimal places and symbol information for proper amount calculations

## 3. Step-by-step calculation

### Component A: Jupiter lending revenue
- **Purpose**: Calculate lending fee revenue from Jupiter protocol on Solana based on interest accrual
- **Logic**: Collect all lending operations (borrows, repays, supplies, withdrawals) from Solana Liquidity program instruction logs. Gather interest rate model configurations (single-kink v1 and dual-kink v2 models) and fee rate updates from instruction events. Process events sequentially per token using a deployed JavaScript UDF that maintains running loan balances and calculates interest accrued between events based on utilization rates and active rate models. Apply temporal fee rates to interest accrued amounts where fees equal interest accrued multiplied by the fee rate active at that time
- **Key fields**: `mint` (token address), `borrow_amount`/`supply_amount` from operations, `interest_accrued_this_period` from UDF calculation, `fee` rates from configuration events

### Component B: Fluid Fluid Vault fees
- **Purpose**: Calculate borrowing interest fees from Fluid Fluid Vault operations across multiple chains
- **Logic**: Extract daily Fluid Vault state snapshots showing total borrow balances from three different ABI versions. Calculate day-over-day changes in `total_borrow_vault` amounts for each Fluid Vault and token. Subtract actual borrowing operations captured in `LogOperate` events from FluidLiquidity contracts, excluding operations to the reserve contract address. The remaining balance increase represents organic interest accrual which becomes fee revenue. Filter any negative values to zero as these represent repayments or liquidations rather than fees
- **Key fields**: `total_borrow_vault` from state data, `borrow_amount` from LogOperate events, Fluid Vault addresses and token mappings from constants

### Component C: Classic Fluid DEX fees
- **Purpose**: Calculate trading fees from Fluid Fluid DEX swap operations based on volume and fee tiers
- **Logic**: Parse `Swap` events from FluidDex contracts across Ethereum, Arbitrum, Base, and Polygon to extract trading data including swap direction, input amounts, and output amounts. Convert `amount_in` values to human units using token decimal metadata. For each trade, apply the fee tier that was active at the time of the trade using temporal joins with trading pair configurations. Calculate fees by multiplying trading volume by the applicable fee tier percentage. Aggregate all trades daily by token and chain
- **Key fields**: `swap_0_to_1` direction flag, `amount_in` trade size, `fee_tier` percentage from pool configurations

### Component D: Fluid DEX Fluid Lite fees  
- **Purpose**: Calculate trading fees from Fluid Fluid DEX Fluid Lite operations using encoded swap data
- **Logic**: Process `LogSwap` events from FluidDexLite contracts on Ethereum containing encoded swap data. Use JavaScript UDF with bitwise operations to decode the swap data extracting Fluid DEX ID, swap direction, and adjusted amounts (stored in 9-decimal precision). Convert adjusted amounts to human units by dividing by 10^9. Match trades to Fluid DEX pool configurations using Fluid DEX ID and apply temporal fee tiers. Calculate fees using the same volume multiplied by fee tier approach as classic Fluid DEX
- **Key fields**: `swapData` encoded value, decoded `amount_in_adjusted` and `amount_out_adjusted`, `dex_id` for pool matching

### Component E: Fluid DEX arbitrage fees
- **Purpose**: Capture arbitrage fees from simultaneous supply and borrow operations on Fluid DEX pools  
- **Logic**: Identify `LogOperate` events from FluidLiquidity contracts where the user address matches known Fluid DEX pool addresses. Filter for events with both non-zero supply amounts and borrow amounts that are not equal, indicating arbitrage activity. Calculate arbitrage fee as the absolute difference between supply and borrow amounts when both operations occur in the same transaction. Process separately for token0 and token1 operations within each pool to capture fees on both sides of trading pairs
- **Key fields**: `supply_amount` and `borrow_amount` from LogOperate events, Fluid DEX pool addresses for filtering, token addresses for fee allocation

### Component F: Fluid Lite asset management fees
- **Purpose**: Calculate performance fees from Fluid Lite Fluid Vault asset management strategies
- **Logic**: Track revenue through two channels: collected revenue from direct collection events and uncollected revenue from daily changes in state variables. For uncollected revenue, calculate daily changes in `unclaimed_revenue_amount` state snapshots, where positive changes represent newly accrued but unclaimed fees. Combine both collected and uncollected amounts, then apply temporal fee rates to determine total fees using the formula: total fees equals yield amount divided by fee rate (since fee rate represents the protocol's percentage share). This calculation gives the total fee amount before the protocol split
- **Key fields**: `amount` from collection events, daily changes in `unclaimed_revenue_amount`, `fee_rate` from configuration events applied temporally

### Final aggregation
- **Combining components**: Union all fee components using consistent schema with daily timestamps, chain identifiers, and product identifiers. Each component contributes its calculated fee amounts in USD after individual currency conversion
- **Currency conversion**: Apply end-of-day token price feeds to convert all native token amounts to USD using the `convert_to_usd_and_correct_decimals` macro, which handles both price conversion and decimal place corrections based on token metadata
- **Time aggregation**: Truncate all timestamps to daily boundaries and aggregate fees by day, chain, and product. Handle time zone consistency across all components  
- **Final calculation**: Use `finalize_metric_fees` macro with fill_zeros strategy to ensure consistent daily time series output, filling missing days with zero values. Apply chain availability filters to exclude data from periods when chain indexing was incomplete

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

Total value users pay to use a protocol (gross fees, user-paid fees).

FluidFLUID

Fees

Fees

Competitive landscape

Chain breakdown