RFP Idea-47 proposes the issuance of a debt token to address the financial losses Radiant incurred from lending pool exploits on both BSC and Arbitrum.
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 solution is necessary to fairly compensate users and restore confidence as the protocol restarts. This debt token proposal aims to efficiently facilitate repayment to users.
Users with impacted deposits and other contract approval associated losses would receive debt tokens (DBT) on a 1:1 basis ($1 USD loss = 1 DBT).
The amount will be dictated by snapshot, after which no approval associated losses can be repaid retroactively that were not a part of snapshot.
Revenue Allocation:
A modifiable percentage of protocol revenue would be directed towards debt repayment, with governance voting to adjust this rate as needed.
The initial amount will be 10% of protocol revenue, taken from dLP revenue stream to distribution revenue as following:
25% to Lender
15% to OpEx
50% to dLP Lockers
10% to debt repayment
Liquidity Pool:
A liquidity pool will be established where users can trade their debt tokens at a discount (< 1:1), enabling immediate capital recovery at a loss. This also allows investors to recapitalize the protocol by purchasing discounted debt tokens, with the expectation of future revenue from the pool.
We recommend Radiant protocol initiate this pool by minting an additional 100k debt tokens to be paired against 100k USDC, sourced either from Radiant funds or by some interested third party.
These debt tokens would not have any claim on repayment, but be used for market making activity. Once the debt tokens have been repaid, these last 100k tokens would be burned and the USDC portion of the pool returned to the owner.
Repayment Mechanism:
As the protocol generates revenue, it would be directed to one of two places:
If debt tokens are priced <1 USDC: Buys back discounted debt tokens in the secondary market until price is back at 1 DBT / 1 USDC. The bought back DBT is burnt and removed from circulation.
If debt tokens are priced at ≥1 USDC, the remaining revenue will be deposited into a repayment contract from which debt token holders can claim $1 USDC per token, burning the token in the process.
Pro-Rata Distribution
Each deposit into the repayment contract will be allocated equally across all outstanding tokens
This prevents large holders from gaining unfair advantages in the redemption process
If any third parties want to provide funds to recapitalize the protocol in the future, it will be distributed per usual with 100% going to debt repayment, using the repayment mechanism as outlined above.
This will continue until all outstanding DBT is removed and burnt, and the POL that was initially seeded wound down.
Steps to Implement
Smart contract development and audit
Update revenue routing mechanisms
Develop debt token contracts
Implement repayment pool logic
User verification period
Publish snapshot of affected addresses
Two-week window for users to verify inclusion
Appeals process for missing claims
Deployment
Deploy token contracts
Initialize liquidity pool
Begin token distribution
Cost Analysis
Direct Costs:
Smart contract deployment
Security audit
Initial liquidity provision (100k USDC)
Indirect Costs:
10% allocation of future protocol revenue
Operational overhead for management and support
Voting
In Favor: Support for implementing the proposed steps.
Against: Opposition to the implementation of RFP-41.
With such an illiquid LP, how do you stop team members or insiders from creating anonymous addresses and trading on insider information to the detriment of depositors?
In cases like Celsius, FTX, and BlockFi, secondary markets required KYC for buying or selling claims. This ensured accountability—insider traders could face jail-time.
Insider trading is unethical and unfair as it extracts value from ordinary users.
2. How do you mitigate frontrunning and bots?
Wouldn’t the LP be vulnerable to frontrunning by bots or fast-acting traders, particularly during:
LP creation?
Planned buybacks?
This would unfairly disadvantage regular users.
3. How do you manage price swings in a small LP?
A $100k LP for a $50M TVL seems extremely small. Based on experience, an LP typically needs at least 30% of TVL if it’s the only LP.
For instance, how could a large third party buy $5M in debt using such a small LP?
The current setup seems to risk extreme price volatility.
If you increase the LP and magically get 15M for the LP, that would just sit in the LP and not go to depositors.
Dollarization / Token Distribution
4. How do you avoid unfairly transferring wealth between user groups?
The protocol assumes that:
Borrowers of BTC still hold BTC.
Borrowers of USDC still hold USDC.
However, dollarizing claims at different points in time can create significant wealth transfers between groups.
User2 now has $60k USDC + claim of $40k = $100k total.
But they should have $90k claim + $60k USDC = $150k total.
In this example:
$30k is effectively taken from long BTC users and given to short BTC users. So you essentially punish those who made the correct market decision and bailout those who were wrong.
An additional $20k is redirected to DLP holders. DLP holders (shareholders) should be the ones bailing out depositors, not the other way around.
How do you prevent such imbalances across all user groups?
5. When will assets be dollarized?
You don’t specify a snapshot date for dollarization. Depending on the date chosen:
Some groups benefit, while others lose.
This could create tension between user groups and reduce the chances of this proposal being accepted.
All of DeFi has the same situation of insider trading risk. The nature of how groups communicate with anonymous devs through teams means the industry is ripe with insider trading issues. Generally you have to track doxxed insiders and if there’s a case of insider trading you take to court. With devs being anonymous its just a risk for any proposal. Nothing prevents users from insider trading in much of any market beyond the risk of going to jail.
Most projects will not announce cashflow payments for this reason, they will randomly do buybacks or send fees to some collector randomly and announce something along the lines of “we will be distributing 100k in USDC on random days over the course of the next month”. You can monitor mempool transactions to see when stuff comes up and team might want to use something like the flashbots RPC if its a concern.
The pool will likely be volatile. It is managed based on whatever market participants want to do. It would not make sense for the team to deposit in the LP with revenue so after it is seeded all protocol revenue goes to users holding debt. Users can deposit and MM if they’d like but this pool is not for whales. Can trade large amounts OTC if whales want to. It will likely just be a benefit for smaller depositors.
Yes denominating in stables means over times the opportunity cost of everything changes and people will miss out on profits. You could argue forcing people to hold crypto as well causes people to be locked out of certain decisions.
I don’t think it makes sense to denominate the protocol debt in crypto because debt will be chasing a moving target. If people do not like denominating in stables then I imagine that will be expressed as we start to vote on stuff.
Snapshot would be day of hack I’d imagine. Date is arbitrary can pick 24 hours after or whatever.
Usually, you can choose whether to participate in a market or not. Here, you would have no choice. If someone has only traded BTC or ETH so far because of these reasons, you will force those to trade in a manipulated market he does not want to. This is not a risk for the other proposals.
Exactly. Smart individuals will secure better rates.
Then why implement this at all, when other proposals achieve the same without the volatility and also accommodate whales? Such as the CR idea from TheGames?
Maintaining the status quo is likely more aligned with users’ decisions than unilaterally changing things around.
Besides, everything is a moving target. All assets move relative to each other, even the USD.
I think it makes more sense that if you have 1 rToken for BTC the protocol owes you 1 BTC. If BTC was 40k I would still want my damn Bitcoin.
Even a few minutes of difference can mean 100k+ in losses for some users. This will probably make it impossible to pass this proposal.
1/2 would be alleviated by only allowing revenue to come in pro-rata and not allow the protocol to use the secondary market. Not sure there’s enough information asymmetry in any of this to really matter though