RFP Idea-47a: Creating an Isolated Fractional Reserve Market to Reimburse Radiant Depositors on BSC and Arbitrum

Radiant Foundation Proposals (RFPs)
1

Abstract

RFP-47 proposes the orderly repayment of BSC and Arbitrum core lending market depositors by cloning the existing core lending market contracts and deploying them into an isolated market using a fractional reserve-type system.

Motivation and Rationale

On October 16, 2024, Radiant suffered a sophisticated security breach, resulting in the loss of over $50 million in user assets. While the team collaborates with authorities to retrieve funds, an immediate plan is necessary to fairly start compensating depositors and restore confidence as the protocol restarts on BSC and Arbitrum.

Useful Links

Announcement: x.com

Post-mortem: x.com

AMA: x.com

Goals

  • Recover 100% of the value of the deposits.
  • Maintain existing investment objectives and the current status quo.
  • Create a plan with a robust incentive structure.
  • Maximize recovery of outstanding loans.
  • Restore as much TVL as possible on the BSC and Arbitrum chains.
  • Sustain RDNT emissions for affected deposits.

Key Terms

Isolated Market: An isolated market operates without interaction with other markets. This separation causes the market to have unique supply, demand, and LTV dynamics.

Fractional Reserve System: A fractional reserve system is a banking structure in which banks keep only a fraction of their depositors’ money in reserve.

Dollarizing Assets: Dollarizing assets refers to converting assets into U.S. dollars or dollar-denominated assets.

IOU (I Owe You): An IOU (I Owe You) is a written acknowledgment of a debt, indicating that one party owes a specified amount to another. In Web 3, it is usually an ERC20 token.

Max LTV: The Maximum LTV ratio represents the maximum borrowing power of a specific collateral. For example, if a collateral has an LTV of 75%, the user can borrow up to 0.75 worth of ETH in the principal currency for every 1 ETH worth of collateral.

Soft Bailout: New deposits from third parties, made with the expectation of the eventual return of their capital.

Hard Bailout: New deposits from third parties, made without the expectation of the eventual return of their capital.

Considerations

Reducing Development Overhead

Reducing development overhead is essential so that the team can focus on new features and thus maximize protocol revenue in the future. To achieve this, we propose redeploying existing contracts, which will allow the team to focus on high-impact work rather than tasks regarding the exploit. The new contracts can also be deployed much faster and with much better security as no additional security audit would be necessary.

Preserving the Intent of Depositors

Preserving the intent of depositors is crucial in our recovery plan to ensure that their original positions and investment goals are respected as much as possible. To achieve this, we should work toward fully restoring each depositor’s balance to pre-incident levels, prioritizing compensation that reflects their initial investment intent. Additionally, we will aim to maintain the same access and withdrawal conditions as originally agreed upon, so depositors can continue managing their assets according to their own strategies within the same Radiant UI as before.

Bailout and Partner Investments

In our recovery plan, bailout and partner investments play a central role in restoring lost assets and re-establishing stability within Radiant Capital. The bailout involves an infusion of emergency funds from Radiant’s core team, stakeholders, and strategic allies, specifically aimed at covering depositor losses swiftly and recapitalizing the new contracts. This immediate financial support will serve as a bridge to mitigate losses and help regain depositor trust.

Shared Responsibility and RDNT Inflation

As depositors, our view is that RDNT token holders, as the primary investors in Radiant Capital, should contribute to the recovery effort, given their stake in the platform’s success. To do this effectively without discouraging new investment, we propose a carefully structured approach to minting new RDNT tokens. Setting the amount of newly minted tokens and determining an optimal disbursement rate is essential to balance recovery needs with long-term value preservation.

Communalizing Losses Across Chains

Communalizing losses across chains is not possible any longer as ETH and Base have been reenabled unilaterally by the team. Nor would we have preferred such an approach.

Dollarizing Assets

To ensure an equitable recovery process that respects the distinct value of assets across different chains, we are committed to avoiding dollarizing assets. Dollarizing assets, meaning converting all losses into a single dollar-equivalent debt token could unfairly disadvantage users based on the investment portfolio and loans they held at the date of the hack. Instead, our recovery plan will recognize and preserve the value of individual assets in their native form wherever possible.
By compensating users in the native tokens, we avoid the risks of forced conversions such as unequal treatment, bad debt, currency volatility, and undesired tax implications.

Outstanding Debt

In our recovery plan, it is important to recognize that outstanding debt, such as loans taken out by users, should be treated as a liability that needs to be repaid. Just as depositors have a claim to their assets, borrowers have a responsibility to repay their loans, and this responsibility should remain intact throughout the recovery process.
By maintaining the debt portfolio, we not only generate interest fees but also immediately restore $30 Million in loan TVL to the protocol.

Trading IOUs

The trading of IOU (I Owe You) tokens in our recovery plan could lead to significant risks and unintended consequences. Allowing IOU tokens to be traded could result in market speculation, creating price volatility that undermines the stability of the recovery process. Users might be incentivized to sell their IOU tokens at a discount, potentially leading to further losses and destabilizing the compensation system.
Additionally, tradable IOUs could create confusion and uncertainty for depositors, making it difficult to track and evaluate the actual value of their claims. Instead of tradable IOUs, we propose a more secure, non-transferable recovery mechanism that guarantees compensation in a clear, transparent, and predictable manner.

Unlimited Allowances

While Radiant is fully responsible for deposits in their contracts, users do bear responsibility when it comes to managing their Web3 wallet allowances. As part of our recovery plan, it has been decided that victims of the unlimited allowances exploit could only be repaid after depositors are fully covered. First and foremost, our focus is on compensating depositors.
Therefore, this proposal does not cover users who incurred losses through the unlimited allowances exploit.

Should this even be a DAO Vote?

We believe that the decision to fully reimburse depositors should not be subject to a DAO vote, as all prior hacks have been covered 100% without the need for a DAO vote. The fundamental principle of protecting user deposits and maintaining trust in the platform should take precedence, and given that all previous incidents were addressed with full in-kind reimbursement, this should be treated as a given.
The DAO vote should therefore be solely focused on the logistics of how to reimburse 100% of the affected assets, rather than whether reimbursement should occur. By limiting the vote to these practical considerations, we can expedite the recovery process and maintain the integrity of Radiant Capital’s commitment to its users.

Specifications

Radiant will launch a dedicated, secondary core lending smart contract as an isolated market specifically for hack victims, referred to as “Pre-Hack Isolated Markets,” on both BSC and Arbitrum. This isolated market will operate on a fractional reserve-based system, independent of the primary contracts.

These contracts will function similarly to the main contracts, with only minor adjustments to certain variables in the contract structure. To avoid confusion for new users, these isolated markets will be accessible through a separate tab or URL on the Radiant website. Development and deployment of these isolated markets will begin once the main markets are fully operational on BSC and Arbitrum.

Token Distribution:

  • Users with impacted deposits would receive rTokens on a 1:1 basis on the newly deployed BSC and Arbitrum fractional reserve contracts. The amount will be dictated by the already existing rTokens on the exploited BSC and Arbitrum contracts.
  • Users with impacted loans would receive variableDebtTokens on a 1:1 basis to their existing tokens on the newly deployed BSC and Arbitrum fractional reserve contracts. The amount will be dictated by the already existing variableDebtTokens on the exploited BSC and Arbitrum contracts.

Contract Characteristics:

  • Withdrawals are disabled for the first 12-24 months. Later ‘Optional Feature: Early Withdrawal’ can be implemented in a new RFP.
  • Deposits are enabled so borrowers can deposit additional collateral and third parties can soft bailout the contract.
  • Borrowing is enabled with the pre-hack LTV levels preserved for existing loans. For new loans an initial Loan-to-Value (LTV) ratio for each token will be set for 0% in the first month (to allow for self liquidation), then gradually increasing to pre-hack levels as the markets are recapitalized.
  • Repayment is enabled and a 1-month grace period will be in place during which liquidations will not be possible for loans.
  • Looping is disabled.
  • Unlooping is enabled.
  • Flash loans disabled.
  • Liquidation penalty is 0%.
  • Deposits will earn a fixed 5% RDNT emission reward to incentivize holding. (If locked DLP requirements are met, otherwise the reward is 0%.)
  • Deposits will not earn in-kind interest for the first 24 months or until the contract reaches 100% recapitalization.
  • Loans will not earn RDNT rewards to promote loan repayment.
  • Loans will have in-kind interest rates to promote loan repayment. (Either dynamic, depending on supply/demand. Or a hard-coded values of 10% for stables and 5% for the rest.)

Optional Token Merges: To reduce complexity these tokens could be merged:

  • All Stablecoins would be merged into USDT or USDC.
  • All BTC denominations into a single BTC market. (WBTC and BTCB respectively.)
  • All ETH denominations (staked version as well) into a single ETH market.
  • All Arbitrum denominations into a single Arbitrum market. (Only on Arbitrum chain.)
  • All BNB denominations into a single BNB market. (Only on BSC chain.)

The rest of the tokens will be converted into the appropriate categories.

Optional Feature: Early Withdrawal

Withdrawals are allowed based on the Collateralization Ratio (CR) concept proposed by @TheGames.
Withdrawals are only enabled for net assets. (Deposit Amount - Loan Amount = Net Deposit Amount)

  • CR = Collateralization Ratio
  • rTR = rTokens the user wants to redeem
  • 15% = withdrawal penalty

Formula:

The withdrawal amount is calculated as:

rTR * CR - (1 - CR) * 15% * rTR * CR

Or simplified:

(rTR * CR) * (1 - (1 - CR) * 15%)

Example

Initial Setup:

  • Users A and B both hold 100 ETH.
  • There are 1000 ETH in rTokens, with a CR of 40% (400 ETH in the protocol).

User A’s Withdrawal:

  1. User A decides to exit RDNT and cash out.

    • User A should receive: 100 * 40% = 40 ETH.
    • After applying the penalty:
      40 * (1 - 60% * 15%) = 40 * (1 - 9%) = 36.4 ETH
    • User A receives 36.4 ETH.

  2. Protocol updates:

    • Remaining rTokens: 900
    • Remaining ETH: 363.4 ETH
    • New CR: 40.4%

User B’s Withdrawal:

  1. User B withdraws after User A:

    • User B should receive: 100 * 40.4% = 40.4 ETH.
    • Penalty calculation:
      (1 - 40.4%) * 15% = 8.94%
    • B receives:
      40.4 * (1 - 8.94%) = 36.788 ETH

  2. Protocol updates:

    • Remaining rTokens: 800
    • Remaining ETH: 326.612 ETH
    • New CR: 40.83%

This mechanism ensures the protocol remains healthier with each withdrawal.

The New Loan Flywheel

The contract operates with pre-hack Loan-to-Value (LTV) rules for existing loans. And post-hack Loan-to-Value (LTV) rules for new loans.
For instance, a user holding $100,000 in WBTC and $50,000 in USDC wouldn’t face liquidation; they simply wouldn’t be able to borrow additional funds beyond the post-hack LTV.

The key concept is incentivizing users to repay their loans, especially if Radiant injects additional capital into the contract. This repayment behavior would initiate a positive feedback loop: as some users repay loans, the market is recapitalized more, encouraging even more users to do the same to reduce their interest burden. This cycle helps restore liquidity and stability, increasing the availability of real assets in the contract.

Non-repayment, however, comes at a cost. Borrowers who fail to repay their loans would accrue interest fees, which, combined with restrictions on withdrawals, would gradually reduce their deposits, finally liquidating them. This ensures that participants who fail to act responsibly toward the new contract ultimately pay a price.

Another key aspect of this design is collecting interest from users attempting to exit the contract. If someone with no loans takes out a loan to access liquidity, they become an interest-paying borrower, contributing to fee generation. This mechanism not only helps generate revenue but also aids in recapitalizing the market. In essence, users are paying a fee to secure some of their funds.

Manual Loan Repayment via Deposit Deduction

For users who prefer to avoid holding loans and accruing interest, and who do not wish to deposit additional funds into the contract, there is an option to manually offset loans using existing deposits during the first month of the start of the new contract. As long as the loan hasn’t been liquidated, you can settle it directly against your deposits.

This feature allows you to repay your loan by deducting the loan amount from your deposit at current market prices, with no liquidation fee (0%). The calculation is straightforward:

Deposit Amount - Loan Amount = New Deposit Amount

How this will be implemented depends on additional developer feedback.

Seeking Soft Bailout

Instead of pursuing an unrecoverable bailout from partners and third parties, proposing a bailout where they could recover their capital within a few years while they help the Radiant community might be more appealing. This approach could be further incentivized by offering OTC RDNT rewards for big partners. While the standard 5% RDNT reward would apply for everyone else.

Optional Feature: Different rToken for new Depositors

Additional RDNT rewards could be allocated to encourage new deposits into the isolated contract.

A separate rToken could be issued for hack victims and another for new depositors. New depositors would receive variable RDNT rewards based on the shortfall relative to total rTokens and would have the option to withdraw their funds (contingent on available liquidity) fully.
New depositors would risk not having immediate access to their funds for higher RDNT rewards. As the hole is filled the risk reduces in tandem with the rewards.

Optional Feature: Recovery Community Council

Following the hack, a new subgroup (hack victims) emerged whose incentives may not fully align with those of the broader community. To address this, a Recovery Community Council consisting of 3-5 depositors could be established to represent the interests of this subgroup, monitor RDNT rewards and facilitate coordination with the core team throughout the recovery process.

Contract Recapitalization:

  • Existing loan portfolio interest.
  • Loan repayment and unlooping.
  • New deposits from third parties (Soft Bailout).

Radiant will also contribute capital to the isolated market, ensuring assets reach 1:1 to rTokens:

  • A 0-20% increase in the RDNT supply, with newly minted coins gradually sold over a 24-month period. (Math: If Radiant does well, with a 20% RDNT inflation, RDNT only has to do a 3-4X to pay everyone fully back in-kind in 2 years. Just from the inflation.)
  • A flexible percentage of protocol revenue directed to these markets, with adjustments made through governance voting. Initially, this will be set at 0-20% of protocol revenue.
  • Any bailout funds that Radiant receives directly. (Hard Bailout)
  • Any recovered assets will also be directed to these markets.

If funding from Radiant’s contribution exceeds 100% of the required amount, the surplus will flow back into the Radiant treasury.

RDNT Burn

Once the isolated market is fully recapitalized, the RDNT supply initially minted for this purpose will be repurchased from the open market and burned. Implementing this burning process will require a new RFP proposal at that time.

Steps to Implement

User Asset Database

  • Generate a snapshot based on the timestamp/block of the last legitimate transaction (non-hack) TX.

  • Build a Web2 database from the snapshot. (Firebase, MySQL, or another suitable option.)

  • Develop an off-chain user interface (UI) that allows individuals to verify their claims.

  • Optional Step: Merging all tokens into BTC, ETH, USDT, BNB, and Arbitrum (ARB).

  • Update the interface to enable users to offset their loans off-chain. Off-set happens at current prices using price oracles.

  • Loan off-set phase will be available for 1 month.

  • Finalize the database and publish the final data as an Excel document for final manual checks.

Contract Deployment

  • Clone existing core lending market smart contracts on BSC and Arbitrum.

  • Make the modifications outlined in the proposal.

  • Perform security audits.

  • Deploy the new isolated market.

  • Mint rTokens and variableDebtTokens once all adjustments are done.

  • Burn keys after minting the rTokens and variableDebtTokens is complete.
    (Therefore no additional tokens can be minted. Only by depositing funds into the market.)

  • Add a new tab ‘Pre-Hack Markets’ (Title pending) to the Radiant UI.

External Stakeholders

  • Reconnect with Binance and other centralized partners for potential collaboration.

  • Draft and submit an Arbitrum DAO proposal timed to coincide with the launch of the new isolated contract.

  • If grants are approved, request deposits into the contract through the ‘direct deposit function’ to ensure instant liquidity.

Cost Analysis

  • Build, test, audit, and deploy new smart contracts.

  • Increase RDNT token supply to support recovery goals.

  • Cover ongoing costs for management, support, and infrastructure.

Voting

In Favor: Support for implementing the proposed steps.
Against: Opposition to the implementation of RFP-47.
Abstain: Undecided, but contributing to quorum.

2

This topic was automatically closed after 7 days. New replies are no longer allowed.