Lenders deposit funds into Radiant Capital and receive interest payments from borrowers (supply-side fees).

Radiant Capital is a non-custodial omni-chain lending protocol built on Layer Zero. Radiant Capital was founded by an anonymous team and launched in 2022 on Arbitrum.

RDNT tokenholders own and govern the protocol. They currently take a cut of the total interest paid by borrowers (revenue).

governance

github

twitter

discord

etherscan

website

Lending

Radiant Capital

# Radiant Capital Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique user addresses that interact with Radiant protocol's lending pools within any 7-day period. This metric answers the business question "How many unique users are actively engaging with Radiant's lending services on a weekly basis?" The calculation uses HyperLogLog probabilistic data structures to efficiently compute approximate unique counts across rolling 7-day windows, providing breakdowns by chain, user type, and product dimensions.

## 2. Data sources

- **Blockchain events**: Parsed event logs from Radiant protocol's `LendingPool` smart contracts on Arbitrum and BSC networks
- **Event types**: `Borrow`, `Deposit`, `FlashLoan`, `Repay`, and `Withdraw` events from both Radiant v1 (Arbitrum only) and v2 (Arbitrum and BSC) contracts
- **Transaction data**: Arbitrum and BSC transaction records containing user addresses, block timestamps, and transaction hashes
- **User interaction data**: Smart contract event parameters identifying user addresses for different interaction types (borrowers, depositors, withdrawers, repayers)

## 3. Step-by-step calculation

### Component A: User event normalization
- **Purpose**: Extract and standardize user addresses from various Radiant lending pool events across different chains and contract versions
- **Logic**: Raw blockchain events from Radiant's `LendingPool` contracts are processed to identify user addresses from different event parameters. `Borrow`, `Deposit`, and `Withdraw` events use the `user` parameter, `FlashLoan` events use the `initiator` parameter, and `Repay` events use the `repayer` parameter. Each event is classified into user types: "Borrower" for borrow and flash loan events, "Depositor" for deposit events, "Withdrawer" for withdraw events, and "Repayer" for repay events. Events are tagged with chain identifiers ("arbitrum" or "bsc"), market sector ("lending"), and business segment ("lending")
- **Key fields**: `block_timestamp` for timing, `user_address` for user identification, `user_type` for interaction classification, `chain` for network identification

### Component B: Daily active user calculation  
- **Purpose**: Aggregate unique user addresses by day to create Daily Active Users (DAU) baseline data
- **Logic**: User addresses from the normalized events are aggregated by truncating `block_timestamp` to daily boundaries. Each unique `user_address` is counted once per day regardless of the number of transactions or interactions. The aggregation maintains dimensional breakdowns by `chain`, `user_type`, and `product_id` to enable downstream analysis. A timestamp grain of "day" is assigned to mark this as daily-level data
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing unique user addresses, dimensional fields for breakdowns

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user counts into probabilistic data structures for efficient approximate counting across time windows
- **Logic**: Daily active user data is transformed into HyperLogLog (HLL) sketches using BigQuery's `hll_count.init()` function with precision parameter 15. This creates memory-efficient probabilistic data structures that can estimate unique counts when merged across time periods. Each daily HLL sketch represents the unique users for that specific day and dimensional combination
- **Key fields**: `hll` sketch containing compressed user count data, maintaining all dimensional breakdowns

### Component D: Rolling window creation
- **Purpose**: Generate continuous 7-day rolling windows to calculate weekly active users without gaps in the time series
- **Logic**: A datespine generates every calendar day from the earliest available data to yesterday. For each day in the datespine, a 7-day window is created by joining with the current day plus the previous 6 days (total 7 days). This ensures every day has a complete 7-day lookback window. The window creation uses `generate_timestamp_array()` to create arrays of dates that are unnested and joined with the daily HLL data
- **Key fields**: `timestamp` for the window end date, `joinday` for each day within the 7-day window

### Component E: HLL merging and unique count extraction
- **Purpose**: Merge HLL sketches across 7-day windows to calculate approximate unique user counts for weekly active users
- **Logic**: For each 7-day window, HLL sketches from all days in the window are merged using `hll_count.merge_partial()` to combine the probabilistic data structures. The merged HLL is then processed with `hll_count.extract()` to produce the final approximate unique user count representing weekly active users. This process maintains dimensional breakdowns throughout the aggregation
- **Key fields**: `user_wau` containing the final weekly active user count

### Final aggregation
- **Combining components**: The calculation creates separate dimensional breakdowns for overall project level ("project_dbt_tag"), chain level, user type level, and product ID level. Each breakdown aggregates the appropriate dimensional fields while setting others to null. All breakdowns are combined using UNION ALL operations to create a comprehensive dataset
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 7-day rolling windows where each day represents the unique users active in that day plus the previous 6 days. No calendar week boundaries are used - every day gets its own 7-day lookback period
- **Final calculation**: The metric uses HyperLogLog probabilistic counting to estimate unique users across the 7-day windows, providing approximate but highly accurate counts while maintaining computational efficiency for large datasets. Results are standardized using the `finalize_metric_user_wau` macro with zero-filling for days with no activity

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

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

Radiant CapitalRDNT

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown