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 Supply-side fees Methodology

## 1. Overview

Supply-side fees measures the portion of total fees generated across Fluid protocols that is distributed to liquidity providers and suppliers, rather than retained as protocol revenue. The flow of value back to the supply side of lending and Fluid DEX protocols is represented by this metric. Total fees generated across all products are aggregated, protocol revenue is subtracted, and the remaining portion is allocated to the supply side.

## 2. Data sources

Data is sourced from the following on-chain and external inputs:

- **Blockchain events**: `LogOperate` and `LogCollectRevenue` events from `FluidLiquidity` and `FluidLiquidityProxy` contracts, `LogRebalance` events from `FluidVaultT1` and `FluidVaultT2` contracts, `Swap` events from `FluidDex` and `FluidDexT1` contracts, `LogSwap` events from `FluidDexLite` contracts, `collectRevenueLog`, `updateFeesLog`, and `LogWithdrawFeeCollected` events from `iETH`, `iDAI`, `iUSDC`, and `iWBTC` contracts, and `Operate`, `UpdateTokenConfig`, `UpdateRateDataV1`, and `UpdateRateDataV2` from the `Liquidity` program, alongside on-chain state snapshots from resolver and Fluid Vault contracts, covering Ethereum, Arbitrum, Base, Polygon, and 2 other chains
- **External data**: End-of-day asset price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Total fees calculation

- **Purpose**: Gross fees generated across all products are calculated.
- **Logic**: Fees are aggregated from five main sources. Jupiter Lend fees are calculated from daily interest accrued on active loans multiplied by protocol fee rates. Fluid Vault and Venus Flux fees are determined by tracking daily increases in borrow balances, with borrowing operations from `LogOperate` events subtracted. Fluid DEX and Venus Flux fees are calculated by combining trading fees (where the swap-direction-appropriate asset amount is multiplied by the trade fee rate) and arbitrage fees from supply/borrow imbalances. Fluid Lite fees are derived from asset management yield divided by time-varying fee rates from fee update events.
- **Key fields**: `interest_accrued_this_period`, `fee` (Jupiter Lend), `total_borrow_vault`, `borrow_amount` (Fluid Vault), `amount_0`, `amount_1`, `trade_fee_rate` (Fluid DEX), `supply_amount`, `borrow_amount` (Fluid DEX arbitrage), `amount`, `fee_rate` (Fluid Lite)

### Component B: Protocol revenue calculation

- **Purpose**: The portion of fees retained by the protocol as revenue is determined.
- **Logic**: Revenue is summed from multiple streams. Fluid and Venus Flux revenue is derived from daily changes in uncollected revenue tracked by resolver snapshots, plus collected revenue events. Daily changes are calculated by comparing cumulative revenue amounts from resolver data between consecutive days. Fluid Lite revenue is comprised of asset management performance fees and withdrawal fees collected through contract events. A 50% share of total fees from Jupiter Lend is contributed as protocol revenue. Cumulative balances are compared between consecutive days across revenue streams to determine daily increases.
- **Key fields**: `revenue` (from resolver), `amount` (from collection events), `uncollected_supply_revenue`, `uncollected_borrow_revenue` (Fluid Vault calculations), `total_supply_liquidity`, `total_supply_vault` (Fluid Vault deltas)

### Component C: Jupiter Lend special allocation

- **Purpose**: The specific 50% supply-side allocation for Jupiter Lend is handled.
- **Logic**: For Jupiter Lend specifically, exactly 50% of total fees are allocated to the supply side. This is represented by the predetermined revenue sharing model where half of Jupiter Lend fees are distributed to liquidity providers and half are retained by the protocol.
- **Key fields**: `fees` (from Jupiter Lend), multiplied by 0.5

### Final aggregation

- **Combining components**: Total fees and protocol revenue are aggregated across all products. Supply-side fees are calculated by subtracting protocol revenue from total fees. For Jupiter Lend, since protocol revenue is defined as 50% of total fees, this calculation naturally results in a 50% allocation to the supply side.
- **Currency conversion**: All asset amounts are converted to USD using end-of-day price feeds matched by timestamp and asset address, with amounts normalized by decimal precision based on asset metadata.
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation to the day level.
- **Final calculation**: The final metric is calculated as `fees_supply_side = fees - revenue`, ensuring suppliers receive their allocated portion of value generated across all protocols.

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

Portion of fees distributed to service providers or supply-side participants.

FluidFLUID

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown