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 Active users (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of unique addresses that interacted with any Instadapp product within a 7-day rolling window. This metric provides insight into Instadapp's user engagement across its ecosystem of DeFi products including Fluid lending vaults, Fluid DEX trading, and Fluid Lite products. The calculation uses HyperLogLog probabilistic data structures to efficiently count distinct users across time windows while maintaining accuracy for large datasets.

## 2. Data sources

The metric relies on several types of blockchain and protocol-specific data:

- **Instadapp protocol events**: Parsed smart contract events from Instadapp's various products across multiple chains
  - Fluid Fluid Vault interaction events (`LogOperate`) from Arbitrum, Base, Ethereum, and Polygon
  - Fluid Fluid DEX swap events (`Swap`) from Arbitrum, Base, Ethereum, and Polygon  
  - Fluid Fluid DEX Fluid Lite swap events (`LogSwap`) from Ethereum with encoded swap data
  - Fluid Lite product events including supply and withdraw operations for iDAI, iETH, iWBTC, and iUSDC on Ethereum
- **Transaction records**: Blockchain transaction data from Ethereum, Arbitrum, Base, and Polygon containing user addresses and timestamps
- **Pool metadata**: Instadapp Fluid Fluid DEX Fluid Lite pool configuration data for decoding swap parameters

## 3. Step-by-step calculation

### Component A: Daily active user extraction

- **Purpose**: Identify unique user addresses that interacted with each Instadapp product on each day
- **Logic**: The system processes four categories of user interactions. For Fluid Fluid Vault users, it extracts addresses from `LogOperate` events across supported chains, joining with transaction records to get the `from_address` as the user. For Fluid Fluid DEX traders, it captures `Swap` events and similarly extracts user addresses from transaction records. Fluid Fluid DEX Fluid Lite traders are identified through `LogSwap` events on Ethereum, with additional logic to decode compressed swap data containing Fluid DEX ID, direction, and amounts. Fluid Lite users are tracked through various supply and withdraw events across iDAI, iETH, iWBTC, and iUSDC tokens, with specific parameter mappings for each event type to extract user addresses
- **Key fields**: Daily aggregation uses `block_timestamp` truncated to day level, `chain_id` for multi-chain tracking, `user_type` classifications like "Fluid Lend user", "Fluid Fluid DEX trader", "Fluid Fluid DEX Fluid Lite trader", and "Fluid Lite user", `product_id` values including "Fluid Vault", "Fluid DEX", "Fluid Fluid DEX Fluid Lite", and "Fluid Lite", and `user_address` extracted from transaction records

### Component B: HyperLogLog initialization for daily user sets

- **Purpose**: Convert daily user address lists into probabilistic data structures for efficient distinct counting
- **Logic**: Each day's unique user addresses are processed into HyperLogLog structures with 15-bit precision. This allows for approximate counting of distinct users while maintaining high accuracy and enabling efficient merging operations across time periods. The HLL structures are grouped by timestamp, chain, user type, and product to maintain dimensional granularity
- **Key fields**: `timestamp` for daily grouping, dimensional fields (`chain_id`, `user_type`, `product_id`), and `hll` containing the initialized HyperLogLog structure for each day's user set

### Component C: Rolling 7-day window creation

- **Purpose**: Generate continuous 7-day rolling windows to capture weekly active users without gaps
- **Logic**: A datespine is created from the earliest daily active user record to the current date minus one day, ensuring no missing dates. For each date in the spine, the system generates an array of the previous 6 days plus the current day, creating overlapping 7-day windows. This approach ensures that users active on any day within a 7-day period are counted in that period's WAU calculation
- **Key fields**: `timestamp` for each day in the analysis period, `joinday` representing each day within the 7-day lookback window for joins with daily user data

### Component D: HLL merging across time windows

- **Purpose**: Combine daily user sets within each 7-day window to count distinct users
- **Logic**: The system joins the 7-day windows with daily HLL structures, matching each window day with corresponding daily user data. HLL structures from the 7 days are merged using HyperLogLog partial merge functions, which maintain the distinct user count properties while combining multiple time periods. The final distinct count is extracted from the merged HLL structure
- **Key fields**: Window `timestamp`, dimensional groupings (`chain_id`, `user_type`, `product_id`), and merged `hll` structures containing user data from the full 7-day period

### Component E: Dimensional breakdowns

- **Purpose**: Create multiple views of WAU data across different dimensional cuts
- **Logic**: Four separate aggregations are created from the windowed data. The project-level breakdown merges all HLL structures regardless of chain, user type, or product, providing overall Instadapp WAU. Chain-level breakdown groups by chain while nullifying other dimensions. User type breakdown focuses on user categories while nullifying chain and product dimensions. Product breakdown aggregates by product type while nullifying other dimensions. Each breakdown uses HLL merge operations to maintain distinct user counting accuracy
- **Key fields**: `dimensions` field indicating the breakdown type ("project_dbt_tag", "chain", "user_type", "product_id"), relevant dimensional values with non-applicable dimensions set to null, and `user_wau` containing the final distinct user count

### Final aggregation

- **Combining components**: All dimensional breakdowns are combined using union operations, creating a single table with multiple analytical perspectives of the same underlying user activity data
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily timestamps represent the end date of each 7-day rolling window, with each day's WAU reflecting users active in the 7 days ending on that date
- **Final calculation**: The `user_wau` field contains the distinct count of users extracted from merged HyperLogLog structures, representing unique addresses that interacted with Instadapp products within the 7-day window ending on each timestamp

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

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

FluidFLUID

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown