RFP-47: Deploying Merged Claim Contracts for Radiant Depositor Reimbursement

Abstract

RFP Idea 47 proposes the long-term repayment of Arbitrum and BSC core lending market depositors by deploying claim contracts while merging assets and liquidating all outstanding loans.

This proposal outlines how funds will be distributed and not how they will be raised. A different proposal will be submitted that outlines how the Radiant DAO plans to raise funds, however, that aspect of the recovery plan is more dynamic as we engage partners and angel investors. Also, a separate follow-on proposal in Q1.2025 will address the unlimited approval losses.

Motivation and Rationale

On October 16, 2025, 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, a plan is necessary to start compensating depositors and restore confidence as the protocol restarts on Arbitrum and BSC while also delivering additional v3 features overall.

Remediation Goals

• Ensure maximum possible recovery value for deposits in exploited Arbitrum and BSC core lending markets.

• Design claim contracts with a focus on streamlined and efficient development cadence.

• Deploy a recovery UI for depositor reimbursement.

Key Terms

Claim Contract: A smart contract that allows users to securely claim assets or funds under predefined conditions.

Recovery Share: A recovery share in a claim contract represents a user’s proportional entitlement to deposited assets based on their claim in %.

Specifications

The Radiant DAO will deploy dedicated claim contracts on Arbitrum and BSC, enabling users to withdraw their tokens as the contracts are progressively recapitalized.

Distribution

• Users with impacted deposits would receive a %-based share on a 1:1 basis following a rToken merge process described below.

• Users with impacted loans would be liquidated and their loans deducted from their deposits. vdTokens are merged and converted using closing day pricing data on the day balances are recalculated.

• Each claim contract has its own set of %-based shares. For instance, someone might hold recovery shares exclusively in the WBTC contract.

Token Merges

Stablecoins

The following assets will be merged into a USDT (Arbitrum) claim contract:

• BNB: USDT & USDC

• Arbitrum: USDT, USDC.e, DAI, USDC, USDe

  BTC Denominations

  All BTC-related tokens will be merged into a single WBTC (Arbitrum) claim contract:

• BNB: BTCB

• Arbitrum: WBTC

  ETH Denominations

  All ETH tokens, including staked versions, will be merged into a single WETH (Arbitrum) claim contract:

• BNB: wBETH & ETH

• Arbitrum: WETH, wstETH, weETH

  Arbitrum Denominations

• ARB (Arbitrum) → ARB (Arbitrum)

  BNB Denominations

• WBNB (BNB) → WBNB (BNB)

  Double-Sided GMX LP Tokens

  The GMX LP tokens will be split into 50% BTC or ETH and 50% USDT:

• gmBTC (Arbitrum) → 50% WBTC (Arbitrum) and 50% USDT (Arbitrum)

• gmETH (Arbitrum) → 50% WETH (Arbitrum) and 50% USDT (Arbitrum)

Conversion Prices

The conversion will take place on the conversion effective date but will be no earlier than January 31, 2025. The price used for the conversion will be based on the daily closing price of the tokens on the conversion effective date, rather than their price on the date of the hack. The Dune API provides access to daily closing prices through its prices.day table. This table offers daily price data for tokens, aggregated at 00:00 UTC.

Example conversion calculations in Addendum 1.

Withdrawal Mechanism

• The claim contract will issue a %-based allocation based on the final tally of token merges. (For example: If you have 1 WBTC in a 10 WBTC claim contract, you have a 10% claim.)

• Capital injections will occur in multiple phases, and after each phase, the claim contract will allow users to withdraw assets proportionally to their share.

Loan Liquidations

The liquidation mechanism will prioritize leaving users with blue chip assets such as BTC and ETH.

Liquidation Logic

1. Loans are first repaid in-kind, meaning assets are deducted from the same type (e.g., ETH is used to repay ETH loans).

2. Loans are then repaid using USDT, then ARB, then BNB, then with BTC & ETH deposits, split equally at 50% each.

3. If either BTC or ETH deposits are depleted, the remaining loans are repaid using the other asset.

4. If all deposits are depleted, the user is fully liquidated, regardless of whether their balance is zero or negative.

Example liquidation calculations in Addendum 1.

Dust

1. All balances below $1 prior to merges will be classified as dust and set to zero**.** In these cases, balances under $1 are always treated as dust to simplify recovery efforts, reduce complexity, and streamline the process.

2. After merges, all balances below $10 will be classified as dust and set to zero. Retaining balances under $10 in the claim contracts would be gas-inefficient, as claims are repaid incrementally in small chunks. Balances below $10 would incur gas costs higher than the payouts received at each stage.

In-kind Recovery Claim Contracts

• This proposal involves merging assets into WBTC, WETH, WBNB, ARB, and USDT and distributing them through 5 in-kind claim contracts.

• Preserve the original crypto holdings for users as much as possible.

Repayment Schedule

Repayment could take many years. The Radiant DAO will make its best effort to fulfill its obligations while balancing financial stability and ensuring ongoing operations. The repayment timeline will depend on various factors, including available resources, future revenue streams, and unforeseen challenges. The Radiant DAO is committed to maintaining transparency throughout this process and will provide regular updates to all stakeholders regarding progress and any changes to the repayment schedule.

The Radiant DAO will attempt to allocate funds to the Recovery Claim Contracts on a semi-annual basis. The allocated amount will be distributed proportionally according to the Total Value Locked (TVL) of each claim contract.

Recovery UI

An easy-to-use interface will be provided to hack victims to review and verify on-chain information and follow the remediation process and status.

Recovery UI Deployment Phases

Phase 1: A view-only UI, where users can check their balances by copy-pasting their wallet address into a field. It will show the various merges and conversions after a RFP-47 is accepted.

After copy-pasting the user’s wallet address, the following is available:

• See their original crypto deposit and loan balances from the exploited contracts.

• See Hack-date and the plan effective date crypto prices for convenience.

• See their post-merge, post-liquidation balances (USDT, WBTC, WETH, WBNB, ARB).

• Link to the mathematics for verification purposes.

  Phase 2: Claim contracts will become available.

• Wallet connection will be enabled

• Claim contracts will be deployed and will be available in the Recovery UI.

Hacked Fund Recovery

If hacked funds are partially recovered the coins will be returned proportionally based on contract TVL into the RFP-47 claim contracts.

If sufficient hacked funds are recovered, the claim contracts outlined in this RFP will be fully repaid. Any remaining funds will be held in reserve to address additional losses as specified in the future Unlimited Approvals Exploit RFP. Regardless of whether you are part of the RFP-47 Claim Contract group or the Unlimited Approvals Exploit Victims group, the recovered coins from the hack will be returned to all users, to the maximum of their pre-hack balances minus any amounts already distributed.

Perceived Inequality

As with any plan, it’s impossible to account for every potential issue, whether perceived or real:

• An angel or DAO partner might deposit into one of the in-kind claim contracts.

• Prices could fluctuate.

• Radiant might raise enough funds, or might not raise enough.

Steps to Implement

User Asset Database

• Generate a snapshot (rToken and vdToken balances) based on the timestamp/block after the last legitimate transaction (non-hack) TX.

• Develop a methodology to ensure 100% data accuracy.

• Build a Web2 database from the snapshot.

• Merging all tokens into WBTC, WETH, WBNB, ARB, and USDT based on the merge logic.

• Merging then liquidating all loans as per the liquidation logic.

• Develop an off-chain user interface (UI) that allows individuals to verify their claims, show pre and post-merge assets, and show pricing data.

Contract Deployment

• Deploy claim contracts on Arbitrum and BSC.

• Add the ‘Recovery Contracts’ to the Radiant Recovery UI.

Cost Analysis

• Build, test, audit, and deploy new recovery UI.

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

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

Voting

In Favor: Support the implementation of RFP-47 as proposed.

Against: Rejecting RFP-47 as proposed.

Abstained: Undecided, but contributing to quorum.

---

These links lead to Google Documents with possible personal information exposure. Use a temporary Google account or access the document in a private browser tab.

Addendum 1: Example Calculations

Addendum 2: Notice to users