Liquidity providers deposit funds to the lending pool and receive a portion of the interest (supply-side fees).

TrueFi is a non-custodial lending protocol built on Ethereum offering undercollateralized loans for verified borrowers. TrueFi was founded by Rafael Cosman and launched in 2020.

TRU tokenholders own and govern the protocol. They currently take a cut of the interest and an origination fee (revenue). TrueFi’s investors include a16z, BlockTower Capital, Alameda Research etc.

github

twitter

discord

etherscan

website

Lending

TrueFi

# TrueFi Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with the TrueFi lending protocol within any 7-day rolling window. This metric answers the business question "How many distinct users are actively engaging with TrueFi lending activities each week?" The calculation uses HyperLogLog data structures to efficiently count unique users across overlapping time windows while providing dimensional breakdowns by chain, user type, and product.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Ethereum blockchain event logs**: Parsed events from TrueFi smart contracts across three protocol versions (v1, v2, v3)
  - TrueFi v1 and v2: `Pool_Joined` and `Pool_Exited` events capturing lending pool deposits and withdrawals
  - TrueFi v3: `ManagedPortfolio_Deposited` and `ManagedPortfolio_Withdrawn` events for managed portfolio interactions
- **Chain availability metadata**: Configuration data defining which blockchain networks are supported for metric calculation
- **Event parameters**: User addresses (`staker`, `lender`), transaction timestamps, and transaction hashes from each blockchain event

## 3. Step-by-step calculation

### Component A: User event normalization
- **Purpose**: Standardize raw blockchain events into consistent user activity records
- **Logic**: Extract relevant TrueFi lending events from Ethereum blockchain logs. Parse `Pool_Joined` and `Pool_Exited` events from v1/v2 contracts, and `ManagedPortfolio_Deposited` and `ManagedPortfolio_Withdrawn` events from v3 contracts. Extract the user address from event parameters (`staker` for v1/v2, `lender` for v3) along with block timestamp and transaction hash.
- **Key fields**: `block_timestamp`, `transaction_hash`, `chain`, `user_type`, `user_address`

### Component B: Daily active user calculation
- **Purpose**: Identify unique users active on each day
- **Logic**: Aggregate the normalized user events by truncating `block_timestamp` to daily boundaries. Count distinct `user_address` values for each day, creating a daily active user dataset. Classify users as either 'Depositor' (from join/deposit events) or 'Withdrawer' (from exit/withdrawal events) based on the event type. Apply chain availability filtering to ensure only supported networks are included.
- **Key fields**: `timestamp` (daily), `chain`, `user_type`, `product_id`, `user_dau`

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user sets into efficient probabilistic data structures for set operations
- **Logic**: Transform the daily active user data into HyperLogLog sketches using `hll_count.init` with precision 15. This creates compact representations of user sets that can be efficiently merged across time windows. Group by timestamp, chain, user type, and product dimensions to maintain all analytical breakdowns.
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll`

### Component D: Rolling window generation
- **Purpose**: Create 7-day rolling windows for each date in the analysis period
- **Logic**: Generate a complete date spine covering the full analysis period to avoid gaps in the time series. For each date in the spine, create a 7-day window by generating dates from 6 days prior through the current date using `generate_timestamp_array`. This creates a join table that maps each analysis date to all dates in its 7-day window.
- **Key fields**: `timestamp` (analysis date), `joinday` (dates within the 7-day window)

### Component E: Window-based user aggregation
- **Purpose**: Merge user sets across 7-day windows using HyperLogLog operations
- **Logic**: Join the rolling window structure with the HLL sketches on matching dates. For each analysis timestamp, collect all HLL sketches from the 7-day window. Use `hll_count.merge_partial` to combine the sketches, effectively creating a union of all users active within the window. This produces the set of unique users active in each 7-day period.
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, merged `hll` sketches

### Component F: Dimensional breakdowns
- **Purpose**: Create separate aggregations for different analytical perspectives
- **Logic**: Generate four dimensional views from the windowed user data. Create project-level aggregation by merging all HLL sketches regardless of chain, user type, or product. Create chain-level breakdown by grouping and merging sketches by `chain_id`. Create user type breakdown by grouping by `user_type`. Create product-level breakdown by grouping by `product_id`. For each breakdown, null out the non-grouped dimensions to maintain consistent schema.
- **Key fields**: `dimensions` (breakdown type), dimension-specific fields, `user_wau` (extracted count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, maintaining the dimensional identifier and associated grouping fields
- **Count extraction**: Extract final user counts from merged HLL sketches using `hll_count.extract`, converting probabilistic sketches back to integer counts
- **Schema standardization**: Apply the `finalize_metric_user_wau` macro to ensure consistent field names, data types, and metadata across all metric outputs
- **Zero-filling**: Fill missing dates with zero values to create complete time series without gaps
- **Final calculation**: The final WAU value represents the count of unique users who performed any TrueFi lending action (deposit or withdrawal) within each 7-day rolling window, broken down by the specified dimensions

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

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

TrueFiTRU

Active users (weekly)

Active users (weekly)

Competitive landscape