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 revenue per user (ARPU) Methodology

## 1. Overview

Average revenue per user (ARPU) for Fluid is calculated to measure the daily revenue generated per active user across the protocol's ecosystem. Insight is provided into the monetization efficiency of Fluid's DeFi products by dividing total daily revenue by the count of distinct active users (daily). All Fluid products are encompassed in the calculation, including Fluid Vault, Fluid DEX, Fluid DEX Lite, Fluid Lite, Venus Flux, and Jupiter Lend partnerships.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: Fluid Vault and liquidity layer revenue

- **Purpose**: To calculate revenue generated from lending and Fluid Vault operations.
- **Logic**: Liquidity layer revenue is calculated by tracking daily changes in the accumulated revenue balances from resolver state data, combined with collected revenue events. Fluid Vault revenue is calculated by combining collected revenue from `LogRebalance` events and uncollected revenue, which is determined as the difference between Fluid Vault supply/borrow totals and underlying liquidity positions.
- **Key fields**: `revenue`, `total_supply_vault`, `total_borrow_vault`, `total_supply_liquidity`, `total_borrow_liquidity`

### Component B: Fluid DEX and Fluid DEX Lite fee calculation

- **Purpose**: To calculate trading fees and arbitrage fees from Fluid DEX products.
- **Logic**: Fluid DEX and Fluid DEX Lite trading fees are calculated by multiplying the trade amount of the input asset (determined by the swap direction) by the trade fee rate. Arbitrage fees are computed from supply and borrow operations that indicate arbitrage activity. A portion of the swap fees is allocated to the protocol treasury based on the configured revenue cut per pool.
- **Key fields**: `amount_0`, `amount_1`, `trade_fee_rate`, `revenue_cut`, `arbitrage_fee`

### Component C: Fluid Lite asset management revenue

- **Purpose**: To calculate performance and withdrawal fees from Fluid Lite vaults.
- **Logic**: Performance fees are calculated by applying time-based fee rates to accumulated yield, which is tracked via changes in unclaimed revenue variables from state data. Withdrawal fees are collected directly from `LogWithdrawFeeCollected` events. Historical fee rates are maintained through fee update events.
- **Key fields**: `amount`, `fee_rate`, `unclaimed_revenue_amount`

### Component D: Jupiter Lend revenue share

- **Purpose**: To calculate the revenue share from the Jupiter Lend partnership.
- **Logic**: Interest accrual on active loans is calculated over time based on utilization curves. Running balances of active loans are maintained, and interest rates are applied using single or dual kink models based on `Operate` and `UpdateTokenConfig` instructions from the `Liquidity` program on Solana. A 50% share of the accrued interest is allocated as protocol revenue.
- **Key fields**: `active_loan_balance`, `interest_accrued_this_period`, `fee`

### Component E: Active users (daily) tracking

- **Purpose**: To count distinct active users (daily) interacting with any Fluid product.
- **Logic**: active users (daily) are identified from transaction records associated with protocol interactions. User addresses are extracted from transaction senders and event parameters across four categories: Fluid Vault users (from `LogOperate` events), Fluid DEX traders (from `Swap` events), Fluid DEX Lite traders (from `LogSwap` events), and Fluid Lite users (from deposit and withdrawal events). Distinct active users (daily) are aggregated to prevent double-counting across products and chains.
- **Key fields**: `user_address`, `user_dau`

### Component F: Revenue aggregation and USD conversion

- **Purpose**: To aggregate and normalize all revenue streams to USD.
- **Logic**: Revenue streams from all products are summed daily by chain and product type. All revenue amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. Daily granularity is maintained with UTC day boundaries.
- **Key fields**: `revenue`, `price_usd`

### Component G: Average revenue per user (ARPU) calculation

- **Purpose**: To compute the final average revenue per user.
- **Logic**: Total daily revenue is divided by the total count of distinct active users (daily) for each 24-hour window. Values are generated with daily granularity using UTC day boundaries.
- **Key fields**: `revenue`, `user_dau`, `arpu`

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

FluidFLUID

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape