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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who interacted with Radiant's lending protocol within a 30-day rolling window. This metric provides insight into user engagement and protocol adoption by tracking distinct wallet addresses that perform lending, borrowing, depositing, withdrawing, or flash loan activities across Radiant's supported blockchain networks. The calculation uses HyperLogLog data structures for efficient distinct user counting at scale and provides breakdowns by blockchain, user type, and product categories.

## 2. Data sources

The MAU calculation relies on the following raw data sources:
- **Parsed Radiant LendingPool events**: Blockchain events from Radiant V1 and V2 LendingPool smart contracts deployed on Arbitrum and BSC networks
- **Borrow events**: Records of users borrowing assets from the lending pools, containing borrower addresses and timestamps
- **Deposit events**: Records of users depositing assets into lending pools, containing depositor addresses and timestamps  
- **FlashLoan events**: Records of flash loan transactions, containing initiator addresses and timestamps
- **Repay events**: Records of loan repayments, containing repayer addresses and timestamps
- **Withdraw events**: Records of users withdrawing assets from lending pools, containing user addresses and timestamps
- **Transaction metadata**: Block timestamps and transaction hashes from Arbitrum and BSC blockchains

## 3. Step-by-step calculation

### Component A: User event extraction
- **Purpose**: Extract and normalize all user interactions with Radiant's lending protocol
- **Logic**: Parse blockchain events from Radiant's LendingPool contracts across multiple chains (Arbitrum and BSC) and protocol versions (V1 and V2). Extract user addresses from five types of lending events: `Borrow`, `Deposit`, `FlashLoan`, `Repay`, and `Withdraw`. Each event type captures different user roles - borrowers initiate loans, depositors provide liquidity, flash loan initiators perform arbitrage, repayers pay back loans, and withdrawers remove their deposits. The system processes events from both Radiant V1 and V2 contracts to capture the complete history of protocol usage.
- **Key fields**: `block_timestamp` for timing, `user_address` for unique user identification, `user_type` classification (Borrower, Depositor, Repayer, Withdrawer), `chain` identifier (arbitrum, bsc), and `transaction_hash` for deduplication

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily distinct active users using HyperLogLog for scalable counting
- **Logic**: Group user interactions by calendar day using timestamp truncation to daily boundaries. For each day, create HyperLogLog sketches initialized with precision parameter 15 to enable efficient distinct user counting. Maintain separate HyperLogLog structures for different dimensional breakdowns including chain, user type, and product categories. The HyperLogLog approach allows accurate distinct user counts while minimizing memory usage for large-scale data processing.
- **Key fields**: `timestamp` truncated to day, `user_dau` containing unique user addresses, `hll` HyperLogLog sketch data structure, dimensional attributes (`chain`, `user_type`, `product_id`)

### Component C: Date spine generation
- **Purpose**: Create continuous daily time series to ensure complete temporal coverage
- **Logic**: Generate a date spine spanning from the earliest user activity date to one day before the current timestamp. This ensures the MAU calculation includes all days even when no user activity occurred on specific dates. The date spine supports incremental processing by limiting the range to recently modified data plus a safety buffer for late-arriving events.
- **Key fields**: `timestamp` for each calendar day in the analysis period

### Component D: Rolling window construction
- **Purpose**: Build 30-day rolling windows for MAU calculation
- **Logic**: For each date in the date spine, create a 30-day window spanning from 29 days prior through the current date (inclusive). Use cross-join logic to associate each target date with its corresponding 30-day lookback period. This generates the temporal framework needed to aggregate daily user activity into monthly active user counts while maintaining a rolling window approach that updates daily.
- **Key fields**: `timestamp` for the target date, `joinday` for each day within the 30-day window

### Component E: Window-based user aggregation
- **Purpose**: Combine daily HyperLogLog sketches across 30-day windows
- **Logic**: Join the rolling window framework with daily HyperLogLog sketches to collect user activity across each 30-day period. For each target date and dimensional combination, gather the HyperLogLog sketches from all days within the corresponding 30-day window. This step prepares the data for HyperLogLog merging operations that will produce the final MAU counts.
- **Key fields**: `timestamp` for target date, `hll` containing daily user sketches, dimensional attributes for breakdown categories

### Final aggregation
- **Combining components**: Create four separate dimensional breakdowns of MAU data by merging HyperLogLog sketches across 30-day windows. The project-level breakdown provides overall protocol MAU by merging all user activity regardless of chain or user type. Chain-level breakdown shows MAU separately for Arbitrum and BSC networks. User type breakdown segments MAU by lending activity (Borrowers, Depositors, Repayers, Withdrawers). Product-level breakdown enables future segmentation by specific Radiant products or features.
- **Currency conversion**: Not applicable - MAU is a count-based metric measuring user activity rather than monetary values
- **Time aggregation**: Use calendar day boundaries with 30-day rolling windows that update daily. Each date represents the MAU for the period ending on that date, spanning the current day plus the previous 29 days
- **Final calculation**: Extract final MAU counts using HyperLogLog merge and extract operations. Merge partial HyperLogLog sketches across the 30-day window using `hll_count.merge_partial()`, then extract the distinct user count using `hll_count.extract()`. Apply the `finalize_metric_user_mau` macro to standardize output schema, handle missing data with zero-filling strategy, and ensure consistent formatting across all Token Terminal metrics. Union all dimensional breakdowns into a single result set with appropriate dimension labels and null values for non-applicable dimension columns.

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

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

Radiant CapitalRDNT

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown