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 Revenue Methodology

## 1. Overview

Radiant revenue represents the protocol's share of lending fees collected from borrowers across Radiant v1 and v2 deployments. The metric combines fee transfers from both protocol versions, with v1 generating revenue through direct token transfers to fee recipients on Arbitrum, and v2 generating revenue through fee distribution events across Arbitrum, BSC, and Ethereum. V2 applies a 75% protocol fee split, meaning the protocol retains three-quarters of collected fees while distributing the remainder to other stakeholders.

## 2. Data sources

- **V1 token transfers**: Arbitrum token transfer events filtered by specific fee recipient addresses to capture protocol fee collection
- **V2 fee distribution events**: Parsed `NewTransferAdded` events from `MiddleFeeDistribution` contracts on Arbitrum and BSC, and `MultiFeeDistribution` contract on Ethereum
- **Market configuration data**: `ReserveInitialized` events from `LendingPoolConfigurator` contract on Arbitrum for v1 markets, plus hardcoded v2 market mappings across all supported chains
- **Token metadata**: Symbol and decimal information for asset identification and normalization
- **End-of-day price feeds**: USD conversion rates for v1 fee amounts that are collected in native tokens

## 3. Step-by-step calculation

### Component A: V1 fee transfers
- **Purpose**: Captures protocol revenue from Radiant v1 lending operations on Arbitrum
- **Logic**: Monitors token transfer events where the recipient (`to_address`) matches specific fee collection addresses (`0xc2054a8c33bfce28de8af4af548c48915c455c13` or `0xf90c69d16599a5c657a05fe76cd22fd9cab44598`). These transfers represent market tokens (aTokens) being sent to the protocol as fees. The system joins transfer data with market dimension data to identify the underlying asset and obtain proper token symbols. Raw transfer `value` amounts are corrected for token decimals and converted to USD using end-of-day price feeds.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `token_address` (market token), `value` (raw transfer amount), `asset_address` (underlying asset), `asset_symbol`

### Component B: V2 fee transfers  
- **Purpose**: Captures protocol revenue from Radiant v2 lending operations across Arbitrum, BSC, and Ethereum
- **Logic**: Parses `NewTransferAdded` events emitted by fee distribution contracts when fees are allocated. On Arbitrum and BSC, these events come from `MiddleFeeDistribution` contracts, while Ethereum uses a `MultiFeeDistribution` contract that combines multiple fee functions. The `lpUsdValue` field in these events contains fee amounts already denominated in USD with 18 decimal precision. Since only 75% of v2 fees belong to the protocol (with 25% distributed to other stakeholders), the system multiplies all v2 fee amounts by 0.75.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `lpUsdValue` (USD fee amount), `asset` (market address for fee context)

### Component C: Market dimension mapping
- **Purpose**: Provides mapping between asset addresses, market tokens, and metadata for proper fee attribution
- **Logic**: Combines dynamic market discovery with static configuration. For v1, extracts market information from `ReserveInitialized` events on the `LendingPoolConfigurator` contract, which announce new lending markets. For v2, uses hardcoded market configurations including asset addresses, market addresses (aTokens), variable debt tokens, and symbols across supported chains. This mapping enables proper identification of which underlying assets generated fees.
- **Key fields**: `chain`, `version`, `asset_symbol`, `asset_address`, `market_address`, `variable_debt_token_address`

### Final aggregation
- **Combining components**: Union v1 fee transfers (after decimal correction and USD conversion) with v2 fee transfers (after applying 75% protocol split). Both streams are standardized with common dimensions including timestamp, chain, business line ('Lending'), market sector ('lending'), and business segment ('lending').
- **Currency conversion**: V1 fees are converted from native tokens to USD using end-of-day price feeds via the `convert_usd` macro. V2 fees are already in USD and require no conversion.
- **Time aggregation**: All timestamps are truncated to daily boundaries using `timestamp_trunc(block_timestamp, day)` to create daily revenue totals.
- **Final calculation**: Sum all fee amounts by day, chain, and asset. Apply the `finalize_metric_revenue` macro with 'fill_zeros' strategy to ensure consistent API formatting and handle missing data points. Filter results based on chain availability to include only supported networks.

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

Radiant CapitalRDNT

Archived

Revenue

Revenue

Competitive landscape

Chain breakdown