Overview

Radiant is a decentralized omnichain money market that allows for cross-chain lending-borrowing activity. This enables operations such as lending on one chain and withdrawing custom amounts on different chains.

Why the Project was Created

Radiant was created to solve the liquidity fragmentation problem across multiple DeFi chains. There are multiple different money markets in DeFi, each with its own liquidity and interest rates. To access capital, users must decide on what chain they want to use. For instance, if lenders on Arbitrum wanted to access their capital by withdrawing on Optimism, they could only do so by going through a series of cumbersome transactions. This liquidity fragmentation creates a suboptimal user experience for borrowers and lenders.

As an omnichain money market, the primary goal behind Radiant is to facilitate seamless cross-chain borrowing and lending. The ultimate achievement would be the consolidation of more than $20 billion of fragmented liquidity across the top 10 alternative chains.

Roadmap

The roadmap provided in the document is very broadly defined, and the team has mentioned that it is up to the DAO to direct it.

• Radiant V1 – Complete
  • Fork of AAVE with Stargate implementation and real yield.
  • Solely on Arbitrum.
• Radiant V2 – In progress
  • LayerZero OFT implementation.
  • Scalable to every EVM chain.
  • Emission extension to 2027.
  • Dozens of new assets are to be supported as collateral.
• Radiant V3 – To be confirmed
  • Forego Stargate for full LayerZero implementation.
  • Continuation of omnichain expansion.
• Radiant V4 – To be confirmed
  • Become the LayerZero for liquidity and yield.
  • Help onboard future crypto users.

The team has also mentioned that near-term changes include new chain deployments, partnerships, and assets being listed.

Team

Both the development team and the founders are anonymous. Over time, some public figures and members of the Radiant core team have been announced.

Github commits have been made with a development account that is not linked to any individual.

The core contributor team consists of 14 people, with the people below acting as the main public figures.

• Isaac Prada – Director of Communications
  • Degree in Aeronautical Engineering
  • Master in Automotive Engineering
  • Ph.D. in Mechanical Engineering and Aerodynamics
  • Ex F1 engineer
  • Former Formula 1 commentator for Cadena SER
  • Former Lecturer in Mechanical Engineering – Universidad Pontificia Comillas
  • Udemy instructor
  • CEO Keewit technology
• Aaron – Project manager
  • Degree in Economics and Mathematics
• Hung Vu – DAO Admin
  • Harvard Business School
  • Degree in Computer Science at Elmhurst University
  • 1st Vietnamese American Naval Aviator
  • Top 10 Tech Leader (Washington Post)
  • Former Chief of Technology at eChalk and VBrick Systems
  • Former Chief of Technology at Ad Exchange Group
  • Former Chief of Operations and Product at Meridian Knowledge Solutions

DeFi Subsector

As an omnichain money market, the success of Radiant will be determined not only by the adoption of the protocol but also by how much liquidity it manages to consolidate as a fully interoperable lending protocol. Over the past few years, there has been significant growth in the number of alternative blockchains that have been deployed to production. As a result of the falling market share and dominance of Ethereum, there is an increasing demand for a credit market that is not reliable on bridges and wrapped asset transfers.

Over the past 2 years, bridges have suffered multiple exploits as well. By using a cross-chain messaging protocol like LayerZero, Radiant is betting on a multichain future where the OFT standard becomes mainstream and removes the need for bridging or wrapping assets across chains.

Tapioca is currently Radiant’s main competitor. Not only does Tapioca compete against Radiant in terms of deploying an omnichain money market, but Tapioca also supports long-tail assets and introduces new functionality such as its own stablecoin, CDPs, options liquidity mining… Currently, Radiant only supports BTC, ETH, DAI, USDC, and USDT. As a result, the protocol is not able to meet the demand for long-tail assets that are often not supported by money markets such as Aave and Compound. In that realm, Radiant is at a disadvantage, since Tapioca can allow users to borrow against LP tokens, yield-bearing assets, and even NFTs.

Radiant is planning to onboard more than 20 collateral assets as part of its short-term roadmap. 

Chains

Radiant is an omnichain money market that operates across chains by building on top of LayerZero. This technology allows the protocol to route messages across different endpoints validated by an Oracle on multiple chains.

The protocol is available on the following chains:

• Arbitrum
• Binance Smart Chain
• Ethereum

The bridging trilemma involves finality, security, and composability. Connecting different chains adds many layers of complexity since every network has its own set of idiosyncrasies, mechanisms, and other nuances that its developers have to deal with. This problem is not solved by wrapped assets. For example, if the smart contract controlling the USDC tokens on Ethereum that back USDC.e on Avalanche are hacked, the wrapped USDC.e tokens would have no value whatsoever (custody risk).

Rather than deploying contracts on each chain they want to be present on, Radiant can sync its application state between the smart contracts on different chains. By using LayerZero, the protocol builds upon a communication protocol that enables smart contract executions across multiple chains. With one transaction, the protocol can send arbitrary messages from a source to a destination chain.

LayerZero

LayerZero is an interoperability protocol that facilitates interactions and integrations between separate blockchain networks and ecosystems. The core idea relies on an infrastructure that enables the transfer of messages between two on-chain endpoints: the oracle and the relayer. Instead of bridging assets, LayerZero removes the need for an intermediary protocol and uses a relayer that passes the messages to an oracle, and the oracle is responsible for confirming the receipt of the message.

LayerZero is a blockchain primitive that enables the deployment of applications on different chains while still allowing them to communicate with one another. The core difference between LayerZero and bridges is that LayerZero does not require any intermediary blockchains or consensus mechanisms. Because of this, LayerZero is considered a messaging protocol that allows for the seamless communication of applications across chains.

When a User Application sends a message from chain A to chain B, the message is routed through the endpoint on chain A. The endpoint then notifies the User Application specified Oracle and Relayer of the message and its destination chain.

The process consists of chain A compiling and transferring the message to LayerZero. LayerZero then shares the block ID of the request to the oracle. Subsequently, the off-chain relayer gets the content of the message while the oracle holds on to the block ID. Finally, now that the relayer has the message and the proof of the original transaction, it can prove that the request was made and passes along the block information of the original request.

Deposit

Lending on Radiant allows users to earn interest from borrowers repaying their debt. When users supply assets to a market, they receive rTokens, which are minted and burned upon deposits and withdrawals of the underlying asset. rTokens are interest-bearing assets that earn a yield on the underlying deposit (rUSDC for USDC, rUSDT for USDT…).

Similar to Aave’s aTokens, rTokens follow a rebasing model: each rToken is exchangeable 1:1 for the underlying. All interest is collected and distributed to rToken holders directly. This way, depositors will see a continuously increasing balance of rTokens in their wallets. 

Contract addresses for rTokens: https://docs.radiant.capital/radiant/contracts-and-security/arbitrum-contracts

Note that RDNT emissions are only activated for users who supply Dynamic Liquidity. 

Radiant currently supports ETH, BTC, DAI, USDC, and USDT.

After depositing an asset, users can determine whether or not they want to utilize it as collateral. By default, all deposits are enabled as collateral.

Note that depositing an asset as collateral is a requirement for borrowing but it also exposes your deposit to be partially liquidated if your balance becomes insolvent. 

Withdrawing assets can be done by navigating to the dashboard page and selecting the desired withdrawal amount. Users can withdraw their assets as long as:

• The funds are not actively being used to borrow against.
• The withdrawal would not cause a liquidation on your loans.

1-Click Loop and Lock

Radiant provides a loop and lock function that allows users to increase their collateral value by automating multiple deposit and borrow cycles.

Note that the loop and lock function will not be executed if doing so causes the user’s health factor to drop below 1.11. When that happens, the user should lower their leverage.

This feature automatically ensures dLP eligibility. This is done by automatically borrowing the ETH necessary to zap into a locked dLP position that maintains the minimum 5% dLP requirement for activating RDNT emissions. However, if a user is already eligible, then zero ETH will be borrowed.

• Slippage is fixed at 5%. If a user wishes to reduce this level, they should manually create the dLP position by going to Balancer themselves.
• The dLP will be locked for the user’s default locking length, which can be updated under the “Manage” page.

Looping positions can be unwound by improving the Health Factor, which can be done by depositing additional collateral or repaying outstanding loans.

Borrow

The health factor will increase or decrease depending on the fluctuations in the underlying token value of your deposits. For example, if a user borrows USDC against BTC collateral and the price of BTC drops due to market conditions, the value of the collateral will decrease, causing the borrower’s health factor to decrease and increasing the risk of liquidation.

Maintaining a strong health factor ensures that borrowers can access a flexible portfolio management strategy where they can decrease their likelihood of liquidation (low-risk strategy) and also improve their borrowing eligibility in order to leverage more collateral (high-risk strategy).

Similar to most decentralized money markets, loans are perpetual and borrowers can choose to repay their debt any time they want as long as they are not liquidated. The interest payment on the accrued debt continues to increase over time, which decreases the health factor of outstanding loans as well.

Loans must be paid back in the same asset that was borrowed. 

When a borrower’s health factor drops to 1 or below, a liquidation event will be triggered. This might happen when the value of the collateral asset decreases, or when the value of the borrowed debt increases.

To reduce liquidation risk, users can either repay any outstanding loans or deposit additional collateral in order to increase their health factor.

Liquidators are bots or automated systems that monitor collateralized positions and watch out for loans that might be eligible for liquidation. This enables liquidators to pay back part of the debt owed by borrowers and receive a portion of their collateral at a discount in return (known as the liquidation discount).

The liquidation mechanism serves as an incentive for third-party liquidators to participate in the health of the overall protocol by acting in their own self-interest (to receive discounted collateral). The outcome is that the action of liquidators ensures that borrowing positions are sufficiently collateralized across the protocol.

In order to borrow, users must deposit assets as collateral. Next, based on the amount of collateral that has been pledged, users will be able to borrow assets from a market based on the collateralization factor and the available liquidity of that market.

The Loan-to-value (LTV) ratio represents the maximum borrowing power of a specific collateral. For example, an 80% LTV means that users can borrow $0.80 for every $1 worth of collateral.

Liquidations

When users borrow assets, they should monitor their health factor in order to avoid being liquidated. This is a numeric representation of the safety of a borrower’s collateral assets relative to their outstanding debt.

The higher the health factor, the safer the user’s funds are against a potential liquidation. If the health factor of a borrowing position decreases to 1 or lower, a liquidation event will be triggered. When this happens, up to 50% of the borrowing debt is repaid and that value plus the liquidation fee is taken from the collateral available.

Note that the health factor of a position depends on the liquidation threshold of the user’s collateral relative to the value of the funds they have borrowed. 

As an example:

• A user deposits 10 ETH and borrows 5 ETH worth of DAI.
• If the user’s health factor drops below 1, their loan will be eligible for liquidation.
• A liquidator can step in to repay up to 50% of the borrowed amount (in this case, 2.5 ETH worth of DAI).
• In return, the liquidator will be able to claim the borrower’s ETH collateral at a discount. For instance, for a 7.5% liquidation bonus, the liquidator could claim 2.5 + 0.1875 (0.075 * 2.5) ETH for repaying the borrower’s debt (2.5 ETH worth of DAI).
• Next, the protocol claims 0.1875 ETH at a 7.5% bonus (15% total penalty).
• After the liquidation, the user will end up with 7.125 ETH (10 – 2.5 – 0.1875 – 0.1875 ETH) of supplied ETH collateral and 2.5 ETH worth of DAI borrowed.
• The total liquidation penalty is 15%
  • Half of the penalty (7.5%) is allocated as a bonus for liquidators
  • The other half of the penalty is reserved for the Radiant Growth Fund. This enables the DAO to fund initiatives without having to sell RDNT tokens on the open market.

Asset	LTV	Liquidation threshold	Liquidation penalty
WBTC	70%	75%	15%
USDT	80%	85%	15%
USDC	80%	85%	15%
DAI	75%	85%	15%
WETH	80%	82.5%	15%

Radiant also offers flash loans, whose functionality is inherited from Aave. This is an advanced technical feature that allows developers to borrow any available asset without putting up any collateral as long as the funds are returned within one block transaction.

Flash loans can be used for:

• Arbitrage between assets, without needing to have the principal amount to execute the arbitrage.
• Liquidating borrow positions, without having to repay the debt of the positions and using discounted collateral claimed to pay off the flash loan amount plus the fee.

The flash loan fee is initialized at 0.09% and can be updated by governance. This fee is shared with liquidity providers and the protocol is currently not capturing any premium from it. Nevertheless, the functionality allows for a fee split between liquidity providers and the protocol treasury.

Interest Rates

Radiant’s interest rates algorithm is calibrated to manage liquidity risk and optimize utilization. Borrow interest rates are derived from the utilization rate of a market. The utilization rate is an indicator that represents how much capital is available for borrowing within a pool.

• When capital is available, low interest rates incentivize borrowers.
• When capital is scarce, high interest rates incentivize borrowers to repay their loans and are also more attractive for depositors.

The closer the utilization rate is to 100%, the greater the liquidity risk, since there might be no capital available for lenders to withdraw their deposits. To manage this risk, interest rate models split the interest rate curve into two different parts: the part before the optimal utilization is reached (the slope is small), and the part that comes after the optimal rate has been surpassed (the slope increases sharply).

Investors

Investing Strategies

• A long position can be achieved by using the preferred asset as collateral to borrow a stablecoin (USDT, USDC, or DAI) and then using the borrowed stablecoin to buy the asset you want to go long. As the price of the asset increases over time, the user will be able to sell it for a profit and repay the stablecoin loan.
• A short position can be achieved by borrowing an asset with the user’s preferred collateral and then selling the borrowed asset on the open market with the expectation to re-acquire the asset at a lower price in the future. If the price of the asset decreases, the trader will be able to buy it back at a cheaper price, return the borrowed asset, and maintain the difference as profit.

Dashboard

Radiant’s dashboard informs users about their total rewards, their health factor, and the composition of their borrowing positions and deposits.

The rewards box can be interpreted as the rewards that the user gets based on how much utility their actions have provided to the protocol.

• Daily RDNT rewards show a user’s projected amount of RDNT rewards based on their current share of all dLP-eligible lenders and borrowers.
• Daily protocol rewards show a user’s projected amount of daily rewards from protocol fees.
• Total annual rewards show a user’s projected annual rewards in USD terms based on both RDNT rewards and protocol fees.

The lending box provides users with a breakdown of their deposited assets, borrowed assets, health factor, and borrowing power.

The borrowing power meter displays what percentage of a user’s total borrowing capacity has been met. In the example above, 40.56% of the user’s borrowing power has been utilized.

Dynamic Liquidity (dLP)

Dynamic liquidity is the mechanism design used by Radiant in order to enhance the utility of the RDNT token. By locking dLP, users can activate emissions. This entitles dLP lockers to 3 primary rewards:

• Activating RDNT emissions on deposits and borrows
• Earning a share in platform fees (paid out in blue-chip assets like ETH or BTC and stablecoins).
  • Borrowing fees.
  • Flash loan fees.
  • Liquidation fees.
• Obtain governance rights and voting power in the Radiant DAO.

In order to activate RDNT emissions on deposits and borrows, users must provide a minimum of 5% locked dLP tokens relative to the size of their deposits (in USD terms).

For example:

• A user that deposits $1M USDC on Radiant and has $0 dLP tokens locked, would earn a base rate APY, but not incentivized emissions.
• A user that deposits $1,000 USDC on Radiant and has $50 dLP locked would be eligible for RDNT emissions

The goal behind this mechanism is to create a constructive feedback loop that attracts more long-term liquidity while rewarding those users who are most aligned with the long-term success of the protocol.

Requiring locked liquidity tokens incentivizes long-term participation in the protocol. This way, users are committing to locking their liquidity for a set period of time and, therefore, are incentivized to retain their deposited collateral to activate RDNT emissions.

Radiant offers two locked liquidity pools for receiving platform fees and activating RDNT emissions:

• Arbitrum: Balancer 80/20 pool (80% RDNT & 20% ETH).
• BNB Chain: Pancakeswap 50/50 pool (50% RDNT & 50% ETH).

A dLP position can be created in 1 click with the zap functionality. This allows users to use ETH from their wallet or borrow ETH against their collateral assets in order to build RDNT/ETH (Arbitrum) or RDNT/BNB (on Binance Chain) LP position.

Zapping will never reduce a user’s health factor below 1.1

Next, the user can choose the Zap duration: the longer the lock, the higher the multiplier for the user’s share of platform fees. Locked dLP is subject to a binding variable lock which can not be unlocked early.

Fees generated from locked dLP can be claimed at any time with no penalty and users continue to receive fees during the entire lock period.

Platform fees are distributed linearly over a 7-day period.

The current maximum locking APR corresponds to a 1-year lock duration and is calculated using the 1-year-lock multiplier, 25x, multiplied by the 1-month-lock APR.

• The 1-month lock APR is calculated by dividing the total 1-month locker’s share of annualized protocol fees by the total 1-month locker’s share of the dLP pool size.

• The 1-month locker share of protocol fees is calculated by dividing the 1-month locker share of protocol power by the total protocol locking power.

• The total protocol locking power is calculated as
  • Total Protocol Locking Power = (1 Month Lockers Share of dLP Pool Size * 1 Month Locker Multiplier (currently 1x)) + (3 Month Lockers’ Share of dLP Pool Size * 3 Month Locker Multiplier (currently 4x)) + (6 month Lockers’ Share of dLP Pool Size * 6 month Lockers’ Multiplier (currently 10x)) + (12 month Lockers Share of dLP Pool Size * 12 Month Locker Multiplier))

Annual rewards represent the user’s projected annual rewards in USD terms based on both RDNT rewards and protocol fees.

Annual rewards = (Projected user daily RDNT rewards * 365) + (Projected user daily protocol fees * 365)

Your locked dLP represents the fluctuating value of dLP caused by the volatility of the underlying tokens – RDNT & ETH or RDNT & BNB.

dLPUSDValue = (TWAP(RDNT, 1hr) * rdntLP) + ETH price * ethLPLP supply

Where:

• dLP locked (global) is the total value of all dLP locked on the selected chain.
• rdntLP is how much RDNT is in the LP
• ethLP is how much ETH is in the LP.

Global daily platform fees vary based on the amount of borrowing interest, liquidations and flash loan fees collected by the protocol over a 24-hour rolling period. These daily fees are distributed linearly over 7 days.

A user’s share of the daily global fees is based on their locked dLP position in relation to the size of the globally locked dLP.

User’s share of daily global fees  = (user share of dLP * user avg dLP multiplier) / (total protocol dLP * global protocol avg multiplier)

Where the average multiplier is based on the lock length of the user each time they perform a lock/relock or zap/auto-compound into dLP. For example, a user with 1dLP locked for 1 year (25x multiplier) and 1 dLP locked for 1 month (1x multiplier) would have a total of 2dLP with a 13x average multiplier.

A user’s current lock APR is dependent on the average multiplier and is calculated by multiplying the global 1-month locking APR by the user’s average multiplier.

Maintaining Eligibility

Users must maintain a minimum 5% ratio between their total deposit value and the dLP value at all times in order to remain eligible. As a result, users should be aware of price volatility. For example, a user might have $5 of dLP and $100 of deposits, which means that the user meets the eligibility requirement. If the price of ETH declines by 5%, it would take the value of dLP below $5, which means that the user no longer meets the eligibility requirements.

The protocol needs to check the eligibility state constantly to determine “who is in, who is out.” 

• Users who are eligible will see a banner at the top of each page indicating that emissions are activated for them. 

• When users fall out of eligibility, a “boost inactive” notification will notify them about the amount of dLP required to regain eligibility.

To maintain eligibility, users are required to maintain a buffer zone above the 5% threshold to account for volatility.

Relock dLP

In order to ensure a continuous stream of platform fees, the Radiant front end will notify users when their lock expires. Expired locks will not receive platform fees and remove your eligibility for RDNT emissions.

The default lock length is set to 3 months (4x multiplier) unless the user has previously modified this value.

Users can enable auto-compound and auto-relock.

Auto relocks will lock all expired dLP upon expiration to the user’s default lock length.

Auto-Compound

Platform fees can be auto-compounded into dLP to increase the likelihood of maintaining the eligibility status. Auto-compounding occurs on a daily basis and can significantly increase dLP positions over time, as each future compound increases based on the previous compound.

A 3% fee is charged upon every compound event.

Auto-compounds are staggered and do not occur globally at one time via the bounty system to prevent gamification

Disqualification Bounties

“Gamification” through disqualification bounties is part of the maintenance of the protocol. Users can scan the protocol for wallet addresses that are no longer eligible for emissions (dLP to deposit % falling below 5%) and punish them by kicking them off. This increases global APRs for all eligible users and also rewards them with a bounty.

This disqualification system prevents expired dLP accounts from receiving platform fees and RDNT emissions when they don’t meet the 5% threshold.

Additionally, bounty hunters receive a base bounty for relocking dLP for users that have enabled “auto-relock” and for performing auto-compounds on behalf of users that have enabled this automated feature.

Expired dLP disqualifications can be prevented by toggling the “auto-relock” function in order to continue receiving platform fees without interruption.

​​

• Bounty hunters must maintain the 5% dLP threshold status and have deposited assets to claim bounties.
• Claimed bounties are paid in RDNT.
• The base bounty is dynamic, depending on the “searcher bot” demand and the price of RDNT.
• Bounties are prioritized so that only one bounty per account is available at a time, although there are up to 3 types of bounties:
  • Expired locks have the highest priority. The bounty for removing expired locks from the pool or re-locking dLPs with auto-relock enabled is the base bounty. 
  • The next priority is for emissions to ineligible users.  This prevents users who are not eligible from earning RDNT rewards and protocol fees when they fall below the eligibility threshold. This is compensated with the base bounty. 
  • The last priority bounty is for auto-compounding. When an auto-compound event is triggered, the protocol outsources the execution of the transaction to bounty hunters. These bounties are funded by the fee paid by the user that will be compounded.
• Performing an on-chain action within the Dapp (deposit/claim/lock) triggers a self-disqualification if the threshold is not met.

Vesting RDNT

To receive the full vested amount, users can exit early from their vest for a 25-90% penalty fee. Otherwise, they will have to wait for the 90-day full vesting period to receive the full amount.

The penalty fee paid is returned at a ratio of 90% to the Radiant DAO reserve and 10% to the Radiant Starfleet Treasury (RFP-11). 

Once RDNT is vesting, there is no exit penalty for zapping into locked dLP.

This allows users to unlock access to RDNT emissions and protocol revenue:

Note that zapping with vesting RDNT can only be executed for the full vesting amount. 

Vesting RDNT that has completed the 90-day maturation period can be withdrawn for the full amount.

Initiating an “exit early” transaction from the “currently vesting” panel will exit all separate vesting periods, with applicable penalties applied, while using the “exit early” option for each position will only apply to the selected vesting period.

RDNT OFT Bridge

RDNT, an OFT-20, is Radiant’s native utility token. Layer Zero Labs’ omnichain fungible token (OFT) interoperability solution enables native, cross-chain token transfers.

With LayerZero’s guarantee of valid delivery, the token is burned on the source chain and minted on the destination chain directly through the token contract.

Omnichain fungible tokens allow for composability across multiple blockchains, leading to no fragmented liquidity, smart contract or finality risk, or wrapped tokens with considerable custody risk.

RDNT as an OFT allows the token to exist on more dApps and blockchains than ever, allowing users to create more complex strategies and high-frequency arbitrage opportunities.

Bridging RDNT provides the following benefits:

• Hunt for higher platform fees on other chains.
• Access RDNT emissions in the money market on other chains by activating dLP eligibility.
• Arbitrage.

How to Use the OFT Bridge

After ensuring your wallet is connected to the Radiant protocol, navigate to the Bridge page.

Under “RDNT cross-chain bridge,” input the amount of RDNT you would like to bridge, select the destination chain you would like your tokens to be sent, and click “bridge RDNT” to confirm the transaction in your wallet.

The amount of bridge RDNT swapped = gasForTxn + airdroppedNativeOnTargetChain

RDNT Stargate Bridge

Radiant Capital provides users with a borrow & bridge function via the Stargate stable router interface.

As stated in the LayerZero whitepaper, “Bridges built on the Delta (∆) algorithm [of Layer Zero] conduct native asset transfers through unified pools of liquidity while achieving instant-guaranteed finality, the combination of which enables cross-chain composability.”

The flexibility afforded by the ∆ algorithm creates the opportunity to improve many existing applications, such as decentralized lending protocols like Radiant Capital by taking advantage of single-transaction cross-chain swapping of native assets across vast networks of chains.

Radiant V2 supports deposits on Arbitrum and BNB chains and can be borrowed to any EVM chain supported by Stargate Finance. Radiant is undergoing development testing and will enable full omnichain deposits and borrows in the near future.

How to Borrow & Bridge

Before borrowing & bridging, an asset must be deposited as collateral.

After collateral has been provided, visit the Dashboard and select the asset to be borrowed & bridged.

Input the amount to borrow, select the destination chain, and click continue. If this is your first time using Radiant Capital to bridge, you will need to approve the contract to use the selected asset and approve delegation to bridge funds.

Business Model

Users who simply deposit assets but don’t add value to the protocol earn natural market rates (highlighted in red in the image below), but are not eligible for RDNT emissions.

Economics

Coingecko: https://www.coingecko.com/en/coins/radiant-capital

Radiant’s economic model revolves around becoming the DeFi protocol with the lowest price-to-fee ratio (similar to the PE ratio in stocks) in all of crypto.

From an economic standpoint, Radiant measures its profitability and degree of success relative to the price-to-fee ratio of its competitors. This is achieved with a tokenomics model focused on the native RDNT token, such that protocol profitability is tightly coupled with the utility of the native token.

A low ratio is indicative of a protocol that generates a lot of revenue from fees and has a low market cap. 

In Radiant V1, protocol fees generated from borrowers were equally distributed between RDNT lockers & lenders (50% to lockers of single-sided RDNT, and 50% to lenders).

Radiant v2 aims to provide a stronger value proposition for liquidity providers by improving the ratio of protocol fee splits while concurrently reducing the dilutionary impact of vesting RDNT. This is achieved by splitting protocol revenue such that 60% of protocol fees will be allocated to lockers, 25% will be allocated to the base fee for lenders, and 15% is designated for the DAO-controlled Operating Expenses Wallet.

Revenue and supply-side fees: https://tokenterminal.com/terminal/projects/radiant-capital/revenue-share#revenue-share

Daily fees composition: https://tokenterminal.com/terminal/projects/radiant-capital/composition-by-contract#composition

TVL breakdown by chain: https://tokenterminal.com/terminal/projects/radiant-capital/composition-by-chain

Liquidity Mining

Only users with locked Dynamic Liquidity are eligible for receiving RDNT emissions:

• Liquidity mining emissions in the form of RDNT can be instantly claimed for the total amount as long as they are zapped into locked dLP tokens by pairing the claimed RDNT amount with WETH/BNB.
• Alternatively, emissions can be vested for 9 months. Users can claim vesting RDNT at the cost of an exit penalty fee in order to receive 10-75% of the rewards (decaying linearly over the 9-month period).

Locking dLP is a 1 to 12-month process and must be relocked upon maturity in order to continue earning platform fees.

Revenue Streams

Being a participant in the dLP system grants users the right to earn revenue from protocol fees. These fees are collected from borrowers paying interest on their loans, flash loans, and liquidation fees. As a result, the revenue is captured and distributed in blue-chips assets (such as BTC, ETH, or BNB) and stablecoins. This implementation was implemented as a result of RFP-7.

• 60% of platform fees are distributed to Radiant Dynamic Liquidity Providers (dLP).
• 25% of platform fees are distributed to lenders as their base APY.
• 15% of platform fees are allocated to a wallet owned by the DAO for operational expenses.

RFP-12 reallocates the portion of protocol fees allocated to operational expenses as part of the base lending interest and dLP incentives during new chain deployments. The purpose of this proposal is to temporarily redirect the OpEx Treasury percentage of protocol fees during the first two weeks of a new chain launch, in order to create an additional mechanism for incentivizing lenders, borrowers, and lockers, regardless of their eligibility for emissions.

• 15% of protocol fees generated by USDC and ETH would be redirected to the Base Lending Interest (25% → 40% of protocol fees received).
• 15% of protocol fees generated by all markets excluding USDC and ETH would be redirected to lockers of dLP (60% → 75% of protocol fees received).
• Adjust the operational expenses treasury from 15% → 0% of protocol fees.
• ​​Two weeks after launch, the parameters will return to the base state, meaning that the Treasury will receive the standard 15% of protocol fees.

Claiming Platform Fees (dLP lockers)

dLP lockers receive platform revenue from protocol fees. These are linearly distributed every 7 days and can be claimed at any time.

After clicking on “claim all”, the claimed fees will be represented as rTokens in the user’s wallet.

After that, users can withdraw back to the underlying or continue providing liquidity to the market as lenders.

Fee Breakdown

Borrowing fees are the main driver of economic activity in the ecosystem, but there is also a 15% liquidation penalty (half of which goes to the liquidator and half of which is accrued by the protocol) and flash loan fees (0.09%).

There is a penalty fee for early exits from vesting RDNT. This penalty fee is distributed as follows:

• 90% to the Radiant DAO reserve
• 10% to the Radiant Starfleet treasury

A 3% fee is charged upon each compound event for users who enable auto-compound. This fee is used to fund the bounty contract that rewards bounty hunters for participating in the maintenance of the protocol.

DAO Reserve

The Radiant DAO Reserve is a multi-sig wallet that, in accordance with RFP-2, serves as the router for RDNT emissions. This is governed by RDNT token holders and its actions are executed by the Council multi-sig.

On March 21, 2023 – Radiant was notified that the DAO would be receiving 3,348,026 $ARB tokens from the Arbitrum DAO allocation. The Radiant DAO has yet to decide how these tokens will be utilized. Current proposals suggest utilizing these funds to grow the Arbitrum arm of the DAO and achieve platform metrics that can make the DAO eligible for further grants or incentive programs. 

The initial suggested split would follow a suggested split with a 12-month horizon for the current grant:

• 40% of ARB to borrowers in order to encourage more borrowing and accrue more real yield fees for dLP lockers. This should be applied to each asset proportional to the RDNT emissions currently being emitted.
• 40% to dLP lockers shared between lockers proportional to their lock length. 
• 10% to depositors proportional to the RDNT emissions currently being emitted.
• 10% to the Starfleet treasury with no vesting

There would be a 90-day vesting for depositors and borrowers.

Radiant DAO Reserve wallet: https://etherscan.io/address/0x750129c21c7846CFE0ce2c966D84c0bcA5658497

Operating Expenses

Token incentives: https://tokenterminal.com/terminal/projects/radiant-capital/composition-by-chain

The team has 14 members, with salaries unknown.

Under RFP-7, v2 Design Proposal:

• 60% of protocol fees are streamed to Dynamic Liquidity (dLP) lockers
• 25% allocated as the base APY to lenders
• 15% streamed to a DAO OpEx wallet which will pay for salaries, exchange listings, community-sourced bounties, and marketing partnerships

The OpEx Treasury, which was created via RFP-7, is used to pay salaries and operational expenses that cannot be paid in RDNT (such as ongoing audits, hosting, software licenses, and market-making vendors).

Based on RFP-7, operating expenses would have been allocated approximately $352k for the month of April 2023, or $951k for the entire V2 fees accumulated.

However, it is important to note that while RFP-7 was passed in favor on December 27, 2022, v2 was only launched on March 19, 2023, hence the OpEx treasury would only accumulate from there on.

Additionally, under RFP- 12, the first 2 weeks of launch on a new chain would see fees meant for OpEx going to protocol users instead, only resuming back to normalcy after 2 weeks.

Tokenomics

RDNT is the native utility token of the Radiant DAO. Its economic model attempts to solve the inherent emissions problem faced by multiple protocols with their governance tokens, where the token provides no utility for token holders while the high emissions lead to excessive selling pressure.

In the past, most liquidity mining programs have failed to capture sticky liquidity. The reason for that is that LPs could simply deposit tokens, earn yield in the native token of the protocol, and sell those tokens later on to make a profit. 

Radiant V2 introduces various mechanisms in place to prevent mercenary farming while enhancing the utility for both protocol users and token holders. Governance Proposal RFP-4 voted in favor of using RDNT token emissions to incentivize participants to provide liquidity to the platform as dynamic liquidity providers (dLPs). This way, only users with locked dLP tokens would be eligible for RDNT emissions on their deposits and borrows. Additionally, being a participant in the dLP system grants users the right to earn revenue from protocol fees. These fees are collected from borrowers paying interest on their loans, flash loans, and liquidation fees. As a result, the revenue is captured and distributed in blue-chips assets (such as BTC, ETH, or BNB) and stablecoins.

RFP-4 Takeaways

• Initial emissions were unsustainable and led to too much inflation. While this sparked an early surge in deposits, the emissions model required changes in RFP-2 in order to reduce inflation.
• The original tokenomics meant that emissions for borrowers and lenders would expire after 24 months, which could leave the DAO with insufficient future runway.
• Single-side staking of the RDNT token gave users utility in the form of capturing protocol fees. As a result, there was a low incentive to provide liquidity to the protocol.
• Exit penalties were not fair or optimally designed. A user who exits on the final day of a vest should not be penalized in the same way as someone who exits right at the start.
• Fixed unlock periods created unnecessary FUD and game theory dynamics that were not particularly helpful or useful.

Radiant V2 migrated the RDNT ERC-20 token to a LayerZero OFT (Omnichain Fungible Token). This facilitates cross-chain interactions for users and allows the protocol to have native ownership of bridging contracts rather than relying on third-party bridges. As a result, the RDNT token can be transferred across chains without the need for wrapping assets or bridging from one liquidity pool on one chain to another on a different chain. 

The OFT standard relies on a generic messaging primitive that allows applications deployed on multiple chains to trustlessly transfer token balances to one another. Because of this, no tokens are bridged or wrapped through any middlechains – balances are modified through messages from the source chain to the destination chain. 

The tokenomics induce a “metagame” where users who use the platform as usual lenders/borrowers only get the base APY, while those who want access to protocol revenue and token emissions must lock their liquidity and have 5% of their TVL locked up in dLP. This creates some game theory dynamics where:

• If the price drops, the user is forced to keep zapping into dLP to keep earning.
• If the price increases, yields will go up too and users might want to deposit more TVL to take advantage of being over 5% on the ratio

The expectation of this mechanism design is to create a flywheel where higher prices lead to higher APRs that can attract increasing amounts of TVL. For this to work, there must be organic protocol use that allows the protocol to capture revenue. This would incentivize users to lock their dLP in order to access those earnings and be eligible for RDNT emissions.

Token Distribution

RDNT has a total supply of 1,000,000,000 tokens.

• 54% emitted as incentives for lenders and borrowers over a period of 5 years.
• 20% allocated to the team, released over 5 years with a 3-month cliff. 
  • 10% of the team allocation is locked at the genesis of the protocol and unlocks at the 3-month cliff.
• 14% allocated to the Radiant DAO Reserve made of:
  • 50% of supply-and-borrow incentives emissions from October 2022 to March 2023.
  • 85% of pool2 incentives from August 3, 2022, through February 2023.
  • Ratified by RFP-2.
• 7% allocated to core contributors and advisors released over one and a half years.
• 3%  allocated to the protocol treasury and for providing liquidity. 
• 2% emitted for Pool2 liquidity providers between August 3, 2022, through March 17, 2023.
  • Deprecated as ratified per RFP-8. 

Unlock Token Schedule

Governance

The Radiant DAO is meant to be governed by community members, who will have the right to submit and vote on proposals. In order to do so, users must have a dLP position. Its formation took place in RFP-1, where the Foundation took the initiative to serve the Radiant DAO in its initial stages and would provide the frameworks necessary to operate in a decentralized and community-focused manner.

The Council

The Council consists of 3 persons appointed by a plurality vote.

• The inaugural Council served for 6 months from September 17, 2022, until March 17, 2023.

All subsequent councils serve for a period of 12 months and council members may be removed or replaced if more than 2/3rds of token holders vote in favor of doing so.

• The second Council was supposed to be elected on March 17, 2023. However this deadline failed to be met and there has been no communication since, other than stating that the appointment is TBD. In the meantime, the team is running those operations.

The responsibilities of the Council include:

• Fund the transition by the Foundation from the Treasury, including all employment contracts and grants to support community development.
• Sign transactions from the Council multi-sig to ensure that approved RFPs receive sufficient signatures (even if the Council member had voted “no” with respect to that RFP.
• Attend weekly meetings, vote on RFPs, and attend unofficial Community events hosted by the Foundation and ecosystem members.
  • Council members may choose the frequency with which they perform these activities at their own discretion as long as they adequately represent the community. Otherwise, they might be removed or replaced by another council member.
• Perform adjustments to economic parameters as per the outcomes of RFP votes.
  • In the instance of an Emergency Meeting, the Council may perform adjustments to economic parameters pursuant to a majority vote of Council members.
• Coordinate emergency meetings on behalf of the community, RDNT token holders, and the Foundation. 

RFP stands for Radiant Foundation Proposal.

The Radiant Starfleet Treasury

The Radiant Starfleet Treasury was introduced in RFP-11 to handle exit penalties and improve the incentives framework for protocol participants through the creation of the Starfleet leaderboard. This would be achieved by promoting the protocol’s longevity through longer locking times to ensure that higher percentages of dLP increase the amount of liquidity flowing into the protocol.

The proposal allocates 10% of RDNT that was previously earmarked for burning to the Starfleet treasury. This allocation comes from 10% of exit penalties and suggests rewarding users based on a weighted score that accounts for factors like gross dLP locked, dLP ratio, locking length, and keeping the auto-compound feature enabled.

Governance Glossary

The following are key terms used in the governance process of Radiant.

• RFP (Radiant Foundation Proposal) – a document proposing a new feature, project, activity, goal, piece of information, or change to any proposal that has already been implemented.
• RFP Idea – the first step in the process of creating an official RFP, which will be presented to the community for gathering informal feedback for a period of seven (7) days.
• RFP Draft – the second step in the process of creating an official RFP, which can only be submitted after the original RFP idea has gathered feedback from the community for seven days in the proper channel. An RFP draft must be submitted directly to a moderator via predetermined RFP templates.
• RFP Template – the preset format for an RFP draft, which will vary slightly depending on the nature of the intended RFP.
• RFP Author – the DAO member responsible for beginning the RDNT Foundation Proposal, starting with presenting the idea to the community via the proper RFP idea process. The RFP Author is responsible for incorporating relevant feedback, submitting the subsequent RFP draft via the proper RFP template to the Intake Administrator, and responding to questions or requests for clarifications from DAO members and moderators. A minimum of 2500 locked RDNT is required to engage as an RFP Author.
• RFP Categories – the predetermined classification system for organizing RFPs by their nature or intent. They are: Core Proposal, Ecosystem Fund Allocation Proposal (a subcategory of Core Proposal), Brand Decision Proposal (a subcategory of Core Proposal), Principles Proposal (a subcategory of Core Proposal), Process Proposal, and Informational Proposal.
• Core Proposal – a proposal that would be considered the main activities of the DAO, with subcategories that can be expanded on over time via proposal submission.
• Ecosystem Fund Allocation Proposal – a proposal about how the Ecosystem Fund should be spent. A subcategory of Core Proposals.
• Brand Decision Proposal – a proposal about to whom the community wants to attach its name. This is different from an Ecosystem Fund Allocation Proposal in that it can have associated costs to implement but is not at its core a proposal about Ecosystem Fund Allocation. A subcategory of Core Proposals.
• Process Proposal – a proposal about making a change to a process or proposing an implementation. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment of the DAO or Foundation.
• Principles Proposal – a proposal for establishing and/or updating the major principles behind the distribution of the RDNT token and fees, including, but not limited to, staking, RDNT tokenomics, and budget rules. A subcategory of Core Proposals.
• Informational Proposal – a proposal that provides general guidelines or information to the community but does not propose a new feature.
• Resubmission Proposal – a proposal that was previously submitted but did not pass either due to initial rejection by moderators or the Council or by not passing a vote. All proposal categories have a special template for resubmission that the Author must link to the original proposal, clearly state why it did not pass, and clearly explain how the resubmission is different.
• RFP Moderation – the act of reviewing an RFP to determine whether or not the RFP draft meets the predetermined and DAO-approved guidelines and therefore is eligible to move to the next step in the process. If an RFP passes RFP moderation, it becomes a Pending RFP.
• Pending RFP – the RFP status after it passes RFP Moderation.
• Post-Moderation Tagging – the process of tagging all Pending RFPs that have successfully made it through the RFP moderation phases. There are two tags given at this stage:
  • “Approved to Vote,” which is for any pending RFP where costs, content, and implications are considered to be straightforward and of no risk to the well-being of the DAO.
  • “Needs Administrative Review,” which is for any pending RFP with costs, content, or implications that are considered to be complicated or a potential risk to the well-being of the DAO and therefore must be reviewed by the Council of the DAO.
• Administrative Review – the process of evaluating pending RFPs that have been tagged as “Needs Administrative Review” to determine whether they should be halted or sent to vote by the community.
• Return for Clarification – a type of administrative classification that requires the RFP Author to clarify certain information regarding the Pending RFP. This classification would be given in cases such as the cost to implement being unclear, proposing to utilize a larger percentage of the Ecosystem Fund than is justified based on the value it would provide to the community or being in direct conflict with an active RFP.
• Return for Reconstruction – a type of administrative classification that requires the proposer to restart the proposal submission process because the Pending RFP violates DAO-approved requirements, or in cases of violation of the law, reasonable suspicion of fraud or other misleading information, or the pending RFP being at odds with the mission, values, or well-being of the Foundation or DAO.
• Weekly RFP Release – every Thursday at 9 PM ET, when all RFPs that are ready to go live are released together in a batch.
• Weekly Voting Close – when all RFPs in a Weekly RFP Release batch close for voting, which happens the following Wednesday at 9 PM ET.
• Live RFP – an RFP that has passed all required approval stages and is launched for the community to vote on it.
• Final RFP – an RFP that has completed the voting process. There are two subcategories here: Accepted and Rejected.
• Accepted Final RFP – an RFP that has met quorum requirements and received more than 50% of votes in favor of that RFP.
• Implementation of Accepted Final RFP – the process of implementing an RFP that has been accepted by the community via a vote, based on the predetermined steps laid out in the Draft/Template phases.

Proposal Criteria

The criteria for a proposal as listed as follows:

• The total cost of implementation and any financial impact of its effectuation must be clearly defined in order for a proposal to go to vote.
• If a proposal is ratified that directly impacts Radiant’s smart contracts (i.e., adjustment to emissions rates), it must pass through a 48-hour timelock before implementation.
• The Radiant team wallet (0x62d3…fc2d) will be ineligible to vote on any Snapshot proposals, with the exception of an “abstain” vote.
• All submitters must search through archived proposals to ensure they are not re-submitting a duplicate idea.
• If a suggested proposal directly conflicts with a proposal that is currently up for a vote, the second proposal should not go for a vote until a decision is made on the first proposal to avoid concurrent approval of opposing requirements.
• To avoid concurrent proposals that directly conflict with one another, any idea that directly impacts a proposal that is currently under consideration should not be submitted or voted on until consensus has been reached on the initial proposal.
• No conflict of interest (COI) proposal can be submitted for a vote until 90 days have passed since the original proposal was approved.
• The Council will not consider or vote on proposals that advocate hate speech, illegal activity, or explicit material or are out of line with the Foundation’s mission and values.

Proposal Process

There are 7 phases in the proposal process.

• Phase 1: RFP Idea
• Phase 2: RFP Draft
• Phase 3: RFP Moderation
• Phase 4: Post-Moderation Tagging
• Phase 5: Administrative Review
• Phase 6: Live RFP
• Phase 7: Final RFP

Phase 1: RFP Idea

• An RFP Idea is submitted as an idea via Discourse and must receive confirmation from the DAO Intake Administrator to ensure it complies with DAO-approved guidelines before it appears to the community.
• A minimum of 2500 locked RDNT is required to engage as an RFP Author.
• Pursuant to approval, the DAO Intake Admin will tag the RFP Idea with the appropriate proposal category and make the post viewable to the public.
• The person or people submitting the RFP Idea will be referred to as the “Author” or “Authors”.
• Multiple members can work together on an RFP Idea, but it should be submitted only once.
• The RFP Idea informally gathers upvotes and/or comments via the Discourse interface over a seven (7) day period.
• A minimum of one (1) locked RDNT is required to engage as an RFP commenter.
• At the end of the seven-day cycle, the pending RFP Ideas will be categorized as “Approved to Vote” or “Needs Administrative Review”.
• Pending RFP Ideas flagged for Administrative Review must be reviewed by the Council and sub-categorized as “Not Planned,” “Return for Clarification,” “Return for Reconstruction,” or “Approved”.

Phase 2: RFP Draft

• Once the seven-day feedback cycle has concluded, the RFP Idea will be archived. Pursuant to approval, a moderator will provide the eligible RFP Author with the appropriate template to submit to the DAO Intake Administrator as a formal Snapshot proposal.
• A proposal typically includes:
  • Abstract – Two or three sentences that summarize the proposal.
  • Motivation – A statement on why the Radiant Community should implement the proposal.
  • Rationale – An explanation of how the proposal aligns with the Radiant Community’s mission and guiding values.
  • Key Terms (optional) – Definitions of any terms within the proposal that are unique to the proposal, new to the Radiant Community, and/or industry-specific.
  • Specifications – A detailed breakdown of the platforms and technologies that will be used.
  • Steps to Implement – The steps to implement the proposal, including associated costs, manpower, any legal documentation (if applicable), and other resources for each step where applicable.
  • Timeline – Relevant timing details, including but not limited to start date, milestones, and completion dates.
  • Overall Cost – The total cost to implement the proposal.
• The Author will fill out the template based on the original RFP Idea, incorporating any feedback provided by the community that helps the idea better serve the DAO, including, but not limited to, lack of specificity in the proposal.
• The Author can add additional fields to the template if necessary to fully communicate the intentions, specifics, and implications of the RFP Draft.
• Proposals that did not make it through the initial Snapshot governance process and are being resubmitted should also include:
  • Link to the original proposal
  • The reason it was not approved
  • Changes that have been made and why it should now be approved
• Category Options
  • Core: Ecosystem Fund Allocation
  • Core: Ecosystem Fund Allocation (Resubmission)
  • Core: Brand Decision
  • Core: Brand Decision (Resubmission)
  • Core: Principles Core: Principles (Resubmission)
  • Process
  • Process (Resubmission)
  • Informational
  • Informational (Resubmission)
• The Intake Administrator may then continue communication with the Author to inform them of any incorrect or missing information that needs to be changed—or clarifications that need to be made—in order for the RFP Draft to comply with the DAO-approved guidelines and move to the next step.
• If the Author does not respond to a moderator’s request to change, update, or make clarifications on the RFP Draft within seven (7) days, the RFP Draft will be automatically rejected as having failed to comply with the DAO-approved guidelines.
• When the Intake Administrator confirms that an RFP Draft complies with the DAO-approved guidelines, they assign a number to the RFP for identification purposes throughout the rest of the process. From this point on, the RFP is referred to as “RFP-#: (Name) – (Category)”.

Phase 3: RFP Moderation

• The RFP is reviewed by the Intake Administrator and will either be approved or not approved based on whether it adheres to the DAO-approved guidelines.
• If an RFP is approved as complying with DAO-approved guidelines, it becomes a Pending RFP.
• If an RFP fails to comply with DAO-approved guidelines, it is eligible for resubmission unless in cases of violation of the law or reasonable suspicion of fraud or other misleading information.

Phase 4: Post-Moderation Tagging

• Pending RFPs that have passed RFP Moderation will then either be tagged as “Approved to Vote” or “Needs Administrative Review” as each term is defined and described in this Proposal.
• The “Approved to Vote” tag is given for any pending RFP whose costs, content, and implications are considered to be straightforward and of no risk to the well-being of the DAO.
• The “Needs Administrative Review” tag is given for any pending RFP whose costs, content, or implications are considered to be complicated or a potential risk to the well-being of the DAO. Any Pending RFP that is tagged as “Needs Administrative Review” must go through Phase 5.

Phase 5: Administrative Review

• When an RFP is tagged for review, the Council, serving in an administrative capacity, will determine whether further action is required prior to a Pending RFP proceeding to Phase 6.
• Pending RFPs that the Council determines do not require additional action will be tagged as “Approved to Vote” and proceed to Phase 6.
• If the Council decides to return a Pending RFP for further clarification or action, they must provide a clear explanation of why and tag it as either “Return for Reconstruction” or “Return for Clarification.”
• Reasons to tag as “Return for Reconstruction” or “Return for Clarification” may include but are not limited to:
  • Cost to implement unclear/not able to be calculated (tagged as “Return for Clarification”)
  • Proposes to use more than 5% of the Ecosystem Fund (tagged as “Return for Clarification”)
  • Conflicts with another proposal (tagged as “Return for Clarification”)
  • Proposal is at odds with the mission/values of the DAO (tagged as “Return for Reconstruction”)
  • Proposal is at odds with the well-being of the DAO (tagged as “Return for Reconstruction”)
  • Violations of law, or against advice of counsel for the Foundation (tagged as “Return for Reconstruction”)
  • Reasonable suspicion of fraud or other misleading information (tagged as “Return for Reconstruction”)

Phase 6: Live RFP

• Drafts that have passed their respective approval processes will become a Live RFP on Snapshot during the next Weekly RFP Release, which is when new RFPs are released in batches every Thursday at 9 PM ET.
• Administrators are the only ones who can post RFPs to Snapshot because they must ensure that each one has gone through the correct approval process.
• All RFPs released to vote will undergo a 24-hour delayed “warm-up phase,” in which the RFP is submitted to Snapshot for public view, but is not yet committed to the blockchain or eligible for voting. This affords the Author, Council, and/or Admin a supervisory window to correct any errata before the proposal details are rendered immutable. The warm-up phase only provisions for typographical or numerical errors and not for significant changes to the RFP content itself.
• Once live on Snapshot, Live RFPs are open to voting until Weekly Voting Close, which is when all Live RFPs from a given batch close for voting at approximately 9 PM ET on the Wednesday following their release.
• The voting options are “In favor,” “Against,” and “Abstain.” Voting “In favor” means the voter is in favor of implementing the RFP exactly as-is. Voting “Against” means the vote is against implementing the RFP exactly as-is — voters may vote “Against” to encourage the Author to resubmit the RFP after making changes. Voting “Abstain” means the votes are counted towards quorum but are neither “In Favor” or “Against” of implementing the RFP.
• The quorum requirement for a Live RFP will be 10% of the circulating supply of locked RDNT. Once a quorum has been met, a Live RFP may only be passed with greater than 50% of votes cast “In favor”. A Live RFP that has not received greater than 50% of votes cast “In favor” will not be passed. A Live RFP that has met quorum and achieved greater than 50% of votes cast “In favor” will be deemed an Accepted Final RFP.

Phase 7: Final RFP

• If by the Vote Close Time the Live RFP has not received any votes or is tied, it will be tagged as “Stalled” and be eligible for Resubmission. In all other cases, after the Vote Close Time, Live RFPs are moved to Final RFPs.
• There are two subcategories for the Final RFP status: accepted and rejected. Rejected Final RFPs will have the chance to be resubmitted via the appropriate Resubmission Template if the Author contacts a moderator to initiate this process. Accepted Final RFPs will move into implementation.

Governance Specifications

• DAO Hub
  • The Foundation website will provide an interface to educate DAO members on the governance process and provide easy access to the channels described below in order to streamline the DAO’s operation and enhance its utility.
• Communication Channel
  • Discourse is a forum framework, hosted and configured by the Radiant DAO, to be used as the initial point of discussion for matters of governance.
  • RDNT holders must go through a wallet authentication process to post ideas or give feedback to ideas via comments.
  • RFP Idea posts must be approved by a moderator to ensure they meet all predetermined guidelines and template requirements.
  • All posts and comments will be regularly monitored by both a team of moderators & administrators engaged by the Foundation and by the DAO community members themselves. There will be zero tolerance for hate speech anywhere on this platform.
  • The Author of an idea via a post in community.radiant.capital cannot edit the original post. If the Author wants to propose changes to the original idea, the Author must do this via the comments.
  • Seven (7) days after it has been posted, an RFP Idea is closed to community feedback and will be automatically locked by Discourse.
• Process for Draft Submission via Template
  • Once an idea is approved in community.radiant.capital after the seven-day community feedback cycle, a moderator will contact the Author to provide the appropriate template.
  • The Author should then submit an official RFP draft to the Intake Administrator using the template.
  • The administrator may then continue communication with the Author to inform them of any incorrect or missing information that needs to be changed—or clarifications that need to be made— for the RFP Draft to move to the next step.
  • If the Author does not respond to the Administrator’s request to change, update, or make clarifications on the RFP Draft within seven (7) days, the RFP Draft will be automatically rejected.
• Live RFPs (Phase 6)
  • Snapshot is a framework for on-chain, gasless voting.
  • RDNT holders must go through a wallet authentication process to vote on Snapshot.
  • Council Members are the only ones allowed to launch RFPs on Snapshot as they must ensure each RFP has gone through the correct approval process.
  • Snapshot Voting Criteria
  • Only locked RDNT will be eligible to vote.
  • New proposals that meet the required guidelines will be launched in batches every Thursday at 9 PM ET.
  • User balance of locked RDNT will be referenced by block height at proposal launch.
  • There will be a 24-hour “warm-up” period in order to allow a final review period for any superficial errors, as well as to encourage maximum voter engagement.
  • The standard voting options for a Live RFP are “In favor”, “Against”, and “Abstain”.
  • Voting “In favor” means the voter is in favor of implementing the RFP exactly as-is.
  • Voting “Against” means the vote is against implementing the RFP exactly as-is – one may vote “Against” to encourage the Author to resubmit the RFP after making changes. Voting to “Abstain” means the vote is neither In Favor nor Against implementing the RFP, but the vote weight still will be counted towards the quorum.
  • The voting for each proposal in each weekly batch will be open for voting for five (5) days, closing at approximately 9 PM ET on the following Wednesday.
  • A vote must reach greater than 50% of votes cast “In favor” in order to pass.
  • Furthermore, a vote must meet a quorum of 10% of the circulating locked RDNT supply, to be determined at the current block height when the vote is initiated.
  • Proposals that are approved by the holders of the requisite number of locked RDNT are moved to the Foundation for implementation.
  • Only Administrators can post RFPs to Snapshot in order to ensure that each one has gone through the correct approval process.

Risks and Security

Radiant’s core security focus revolves around oracle manipulation. The codebase inherits functionality forked from Aave and has also been audited by reputable security firms such as Zokyo, Peckshield, and Blocksec.

Because the code was forked from Geist, a fork of Aave, many of the contracts are upgradeable by the owner. To mitigate the concerns around upgradeability and increase transparency, all smart contracts are behind a timelock with a 2-day delay for any action.

The team has stated that it has no intentions to upgrade these contracts unless in a scenario where a critical vulnerability is found. 

Timelock: https://arbiscan.io/address/0x0b6F135db3A621AB9041AC261276D8F38E1dC7a9

Arbitrum contracts: https://docs.radiant.capital/radiant/contracts-and-security/arbitrum-contracts

Binance Chain contracts: https://docs.radiant.capital/radiant/contracts-and-security/bnb-chain-contracts

Audits

Radiant has spent ~$2M in security audits conducted by Layer Zero and Stargate.

Radiant V1 has been fully audited by Peckshield and Solidity, while Radiant V2 was audited by Peckshield, Zokyo, and Blocksec.

V1 Audits

• Smart contract audit report – July 28, 2022 – Peckshield
  • Medium: 2 (1 Resolved, 1 Mitigated)
  • Low: 4 (2 Resolved, 2 Confirmed)
• Smart contract audit report – July 22, 2022 – Solidity Finance
  • High: 1 (1 Resolved)
  • Informational: 1 (1 Resolved)

V2 Audits

• Smart contract audit report – March 5, 2023 – Peckshield
  • High: 2 (2 Resolved)
  • Medium: 4 (4 Resolved)
  • Low: 1 (1 Resolved)
• Smart contract audit – March 6, 2022 – Zokyo
  • Critical: 3 (3 Resolved)
  • High: 4 (4 Resolved)
  • Medium: 7 (7 Resolved)
  • Low: 4 (4 Resolved)
  • Info: 18 (17 Resolved, 1 Unresolved)
• Security testing report for Radiant V2 – March 21 2023 – BlockSec
  • High: 2 (2 Fixed)
  • Medium: 8 (7 fixed, 1 Confirmed)
  • Low: 7 (4 Fixed, 3 Confirmed)
  • Recommendations: 3 (2 Fixed, 1 Confirmed)
  • Notes: 1 (1 Confirmed)

Immunefi

In collaboration with Immunefi, Radiant has posted bug bounties with the scope of impact covering the v2 smart contracts and front end.

While BlockSecTeam, Peckshield, and Zokyo have thoroughly audited Radiant v2, the DAO takes the safety & security of the protocol and users with the utmost priority.

Bug bounty programs are open invitations to security researchers to discover and responsibly disclose potential vulnerabilities.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

• Smart Contract
  • Critical – $200k to $20k.
  • High – $20k to $5k.
  • Medium – $5k to $1k.
  • Low – $1k
• Websites and Applications
  • Critical – $20k
  • High – $6k
  • Medium – $2k

Radiant Risk Monitoring and Alerting platform

The platform was introduced on August 4, 2023, in collaboration with Chaos Labs, as an e2e analytics and observability tool.

This advanced system provides comprehensive analytics and observability, offering the Radiant community a gateway to abundant data and risk intelligence associated with the protocol, all under one unified platform.

The platform is designed to give users a more profound understanding of the Radiant protocol’s overall risk profile and health across all chains. This will support high-level decision-making processes by delivering critical data on assets spread across various chains, thereby equipping users with the necessary information to make strategic and informed decisions. Moreover, the platform promises to provide fine-tuned insights into Radiant usage patterns, trends, and real-time data analysis.

For example, the overview page showcases high-level metrics like total supply, borrow, TVL, collateral at risk of liquidation, and more.

+

Past Exploits

On January 4, 2024, Radiant announced that they had suffered a flash-loan-based exploit.

This occured on the new native USDC market on Arbitrum on January 2nd at 06:53:29 PM +UTC, leading to the protocol accruing bad debt in the WETH market totaling about 1.3% of total protocol TVL. The Radiant DAO Council invoked the emergency administrative controls to pause all Arbitrum markets to mitigate further damage.

On January 5, 2024, Radiant announced that after an extensive review of procedures by OpenZeppelin, independent Ethereum researchers, and white hats, the Radiant DAO Council has unpaused its lending and borrowing markets on Arbitrum.

A Snapshot proposal for the DAO regarding the methodology to repay the excess debt and fully recapitalize the Arbitrum WETH market was put up for vote, being RFP-27.

The liquidation bonus will initially be set to 1bps (lowest it can be set) to allow for a grace period for users to improve health scores, and will gradually be increased back to normal levels over the next 24 hours. Users whose collateral is liquidated due to asset price changes during the pause period will be handled case-by-case.

An analysis by ChaosLabs has shown that the total collateral at risk of liquidation was <$100K, and with a liquidation bonus of only 1bps, this should be even further minimized.

A port-mortem was published on January 20, 2024.

Project Investors

The founding team funded all development work and there were no VC investments. The expenses amounted to over $1.5M. RFP-7 ratified an operating expenses budget to be captured by 15% of protocol fees in order to pay for salaries, exchange listings, audits, and bounties… This would also encourage funding community initiatives without relying on grants or VC funding.

Additional Information

Partnerships

The following are entities that Radiant has partnered or integrated with.

• LayerZero Labs – An omnichain interoperability protocol. Radiant Capital is treading the frontier of Decentralized lending innovation by creating DeFi’s first omnichain money market.
• Chainlink – The industry-standard Web3 services platform connecting the world’s data and systems to blockchains. Radiant Capital has a working relationship with the Chainlink team to ensure the highest level of security on the Oracle price feeds.
• Lido – A liquid staking protocol. Radiant has partnered with LIDO to allow lending and borrowing of wrapped staked ETH within the Arbitrum money market.
• Arbitrum Official Portal – Radiant has been selected by Offchain Labs to be listed on the Arbitrum Official Portal.
• Balancer Labs – Balancer is a decentralized automated market maker (AMM) protocol built on Ethereum that represents a flexible building block for programmable liquidity.
• PancakeSwap – PancakeSwap is the leading decentralized exchange on BNB Smart Chain, with the highest trading volumes in the market
• Binance Labs – Binance Labs invests in technical teams that build and support the decentralized web.
• Plutus DAO – The Arbitrum-Native Layer 2 Governance Blackhole and Home of Exotic Liquid Staking Derivatives.
• Phishfort – Phishing and brand protection. Safeguarding customers, brand equity, and revenue.
• Magpie – Magpie is a Multi-chain DeFi platform providing Yield & ve-tokenomics boosting services.
• Stella – A leveraged strategies protocol with 0% cost to borrow.
• Bithumb Exchange – Bithumb is one of South Korea‘s largest crypto exchanges, with $205 million daily trading volume and 170+ listed cryptocurrencies.
• CamelotDEX – Camelot is an Arbitrum native DEX.
• Furucombo – Furucombo is a multi-chain DeFi aggregator designed to simplify, optimize, and automate complex DeFi transactions.

FAQ

• Was there a seed round, presale, or VC investment?
  • Funding for Radiant was completely bootstrapped by the team. All expenses have been paid out-of-pocket: development, multiple audits, marketing, salaries etc.
  • There was no private sale, IDO, or VC involvement, which aligns with our ethos of decentralization with no bias.
• Why is my health factor declining on borrowed assets?
  • Borrowed assets accrue interest that is paid from deposited collateral. Over time, this may lower one’s health factor.
  • It is recommended to monitor your health factor and ensure it stays above 1. Deposit more funds or repay loans to increase your health factor and avoid liquidation.
  • For more information, please review the Health Factor page.
• What is looping & locking and what is the process to unwind a loop?
  • Looping is an automated process that provides an opportunity to earn a yield on a greater collateral value by repeating the deposit and borrow function with up to 4x leverage.
  • The loop and lock function of Radiant may not execute if the selected leverage would cause your health factor to drop below 1.11. If the loop transaction fails to execute, lower your leverage using the sliding scale.
  • Additionally, the loop & lock feature automatically ensures dLP eligibility. If a user is already eligible, zero ETH will be borrowed. As you can see in the video below, there will be zero ETH borrowed if a user is NOT required to add more dLP.
  • If a user is ineligible for RDNT emissions, the loop & lock tool will automatically borrow the ETH necessary to zap into a locked dLP position to maintain the minimum 5% dLP requirement for activating RDNT emissions. Slippage is fixed at 5%. If a user wishes to reduce slippage, it is recommended to manually create a dLP by visiting the Balancer Pool directly.
  • Lastly, the dLP will be locked for your Default Locking Length, which can be updated under the Manage page.
  • Unwinding a loop is a manual process that requires the repayment of outstanding loans. This may require a few cycles of withdrawing deposited collateral to repay the loan while ensuring your health factor remains above 1. Alternatively, deposit more collateral, improve your health factor, then begin the manual unwind process.
• What is the difference between vesting and locking RDNT?
  • RDNT emissions from lending and borrowing must undergo a 90-day vesting process.
  • Users must actively initiate the vesting period in the “Manage Radiant” section.
  • Users can claim their vested RDNT early for a 25-90% exit penalty at any point during the vesting process. Remember that you can not partially exit early– all currently vesting RDNT will be withdrawn with their respective exit penalties applied.
  • Locked RDNT liquidity providers receive 60% of protocol fees and cannot be unlocked until the locking period has ended.
  • For a full breakdown, visit the Manage Radiant section of the GitBook.
• What is zapping dLP?
  • Zapping allows you to form a locked RDNT liquidity position in one click using RDNT and ETH/BNB in your wallet or borrowed from the money market.
• How is daily revenue distributed?
  • Platform fees are distributed linearly over a 7-day period as they are earned.
  • Daily revenue will fluctuate based on platform fees (borrowers paying interest on loans) and flash loan fees.
• How is “Max dLP Lock APR” calculated from the Markets page?
  • How is the Maximum Locking APR calculated?
  • Definition: Current maximum dLP locking APR (1-year lock duration)
  • Calculation: 1 Month Locking APR * 1 Year Lock Multiplier (25x)
  • Example: 1 month locking APR
  • Definition: Current locking APR for 1 month
  • Calculation: (Total 1 Month Lockers’ Share of Annualized Protocol Fees) / (Total 1 Month Lockers’ Share of dLP Pool Size)
• How is “Your Share” of dLP calculated?
  • (User share of dLP * user avg. dLP Multiplier) / (Total Protocol dLP * Global Protocol avg. multiplier)
• How is “Average Multiplier” for locked dLP calculated?
  • The average multiplier is based on your lock length selected each time you perform a lock/relock or zap/auto-compound into dLP.
  • Calculation: For example, User 1: – Total: 2 dLP locked / 13x Avg. Multiplier – 1 dLP Locked for 1 year (25x multiplier) – 1 dLP Locked for 1 month (1x multiplier)
• How are “Total Annual Platform Fees” calculated?
  • Amount of projected protocol fees received by a user over the course of 365 days, based on an extrapolated 24h sample of Global Protocol Fees Calculation:
  • (User Daily Protocol Fees * 365)
• How is “Your Current Lock APR” calculated?
  • Definition: User Specific Lock APR depending on Avg. Multiplier Calculation: (Global 1 month Locking APR * User Avg Multiplier)
• I claimed my revenue but only received rTokens, how do I retrieve my claimable fees? Where did the funds go?
  • rTokens are interest-bearing tokens represented as ‘rXXXX’ in your wallet (example: rUSDC for USDC).
  • rTokens represent your deposited collateral within Radiant Capital.
  • To convert them to the underlying asset, they may be withdrawn from the lending dashboard.
  • It is recommended to not attempt to transfer or trade rTokens.

Community Links

• Website: https://radiant.capital/  
• App: https://radiant.capital/ 
• Twitter: https://twitter.com/RDNTcapital 
• Discord: https://discord.gg/radiantcapital
• Telegram: https://t.me/radiantcapitalofficial 
• Youtube: https://www.youtube.com/c/RadiantCapital 
• Blog: https://medium.com/@RadiantCapital/ 
• Governance proposals: https://community.radiant.capital/
• Governance voting: https://dao.radiant.capital/