RFP-47: Improving Novin's Proposal

PLEASE NOTICE: this is built upon @Novin 's proposal as linked here
*So before proceeding, carefully read his proposal.

I improved some of the points, expanded others and removed some possible weak points. Many parts aren’t touched at all, unless specified.

@Novin ty for this proposal. It has some sense in it, although there are a lot of “if”s, it’s still much better than the nothingness we’ve seen till now. I Opened a new topic cause my reply was so long that having in the comments was pointless.

TL;DR

  • The above proposal, especially if we get a flywhell, might work
  • Users should get the NET deposited rToken if they looped, or any difference even the slightest. In any case, no debt rtokens should exist if there is a rToken of the same nature, and viceversa
  • Collapsing categories (eth, btc, USD) is very smart and reduces the contracts to audit
  • The earlier an exploited depositor quits, the less he gets, and viceversa. No IOU or trading tokens involved
  • Someone adding to the protocol will get more if he waits for the protocol to recover, as in Pendle’s PT token. Exit will be possible relatively soon for the fair value, minus a fee that gets lower and lower if the protocol is getting closer to be fully recovered
  • Same applies for repaying a borrow
  • Open allowances early losers are grandfathered in cause it’s hard to say it was their fault
  • All the other points from Novin’s stand, included a minor increase in RDNT emission to incentivize deposits

FEASIBILITY and STARTING CONCEPTS

  • The exploited market should be a fully separated section of the website. Identical, but with a “switch” to move between “Normal” markets and “Exploited” markets
  • It’s pretty evident that this needs quite a flywheel to begin with; that means, some real, non-withdrawable capital. Might be coming from team, angels, Binance, Arbitrum – as long as it comes. It’s pretty evident that the higher the % you start with, the much higher the chance that fees cover in the long run the debt. They might even get their deposit back. More on this later
  • I didn’t make a precise simulation, but i think that nothing below 50% would give a real chance to cover in less than 5y. 75% on the other side would make the recovery “trivial”. Above 75% i would cry for joy
  • On the other side, 33-50% would give us hope if the team makes a flawless execution. 25-33% we might still do it in maaany years. Below 25% I don’t know how long this might take; problem is, 50% is nowday about 30M but I hope team works well.
  • Dollarazing the assets it’s terrible. Users lost BTCs, they want BTCs. So, good point
  • Making a simplified version of the assets makes a lot of sense. Take a snapshot at exploit date – all form of BTCs, ETHs and so on, per chain, are collapsed
  • Communism won’t work, so no socialized losses. I didn’t have any on eth/base, only ARB/BNB so go figure how much i’d love to, but it would be horrible
  • Core mkts should not be open, at all, till this is ready. RIZ should be reopened cause people might have to repay debts, but core mkts should stand still also generating a bit of revs to help here. I don’t love it but what’s the point?
  • The RDNT users’ Recovery Community Council is a great idea. This will give whales that lost a lot the option to help, representing the vast majority of the losses, as long with small depositors with good ideas. The election process should be fast, and with a gov vote. They will help pinpointing all the variables that are in the proposal

THE BASIC CONCEPT: COLLATERALIZATION RATIO, or CR

This is pretty simply the ratio of the (tokens on RDNT)/rTokens, per single chain. So if there are 100 rBTCs exploited and somehow we “get” 20 into the recovery protocol, it’s 20%. Should be the same chain-wide to avoid possible tricks

STARTING OPERATIONS AND AUTO-UNLOOPING

  • Forcing people to repay with a 10% LTV (see original proposal) on a non-withdrawable token is VERY bad. In the end if you had 1M in the protocol and even “just” 500K out (net loss, 500K), your deposit is worth 100K and you need to repay 400K to eventually withdraw someday. Yes it will increase the coverage % of the protocol, but in the end, you are forcing people to deposit. They won’t
  • On the other side i am extremely in favor of a minor LTV for these “r-debt” tokens. Say, if a token has 80% LTV going for 70% if not 65% - a 10-15% bp cut
  • This comes at the cost of liquidating some positions, but i have a couple of soft solutions:
  1. A 1 month grace period. Place your bets. If you have an HF of 0.95 due to lower LTV and you think this might be worth, reduce debt or increase capital, i don’t care. If you don’t agree, be partially liquidated. You still have skin in the game. Deposits are STILL un-withdrawable for a while
  2. More important: when tokens are created, deposit the NET amount. Say that user A had 1 BTC deposit and 0.5 borrowed. Just cancel that out, and give him 0.5 BTCs in rWBTC recovery market. He was unlooped already and his net loss is at stake. This becomes more important considering later points
  • I totally agree that tokens should NOT be tradeable. It creates a looot of insider trading possibilities and leads to more issues than solutions
  • Depositors should get the interest in kind by the way, to stimulate deposits. The RDNT portion is still subject to 5% rule
  • Depositors CAN borrow even from exploited contracts, as explained later, after the withdraws reopen

FORCED REPAYMENT BEFORE DEPOSIT

If User A has 10 ETH borrowed and 0 in deposit, he can’t deposit ETH before fully repaying his debt in that kind, but forcing him to put 10 ETH if the collateral is just 20%, is just plain stupid. See next point(s) for more

EARLY WITHDRAWS CONSIDERING THE SIZE OF THE WALLET

This point should be quickly deleted. It creates different incentives for different users, and also is against the biggest losers of this tragedy. There should be no differences at all, and if any that should just be the opposite

rTOKENS FOR DEPOSITORS AND REPAYMENT aka DEPOSIT BONUS

Let’s go to the juice. No one will deposit for a non-withdrawable token that is even partially missing without incentive. The main concept is that users should get more for their deposits in-kind. It increases debt, but it’s like buying a PT token on Pendle, in the end. Problem for depositor is, there no set date, but there is a solution (next point) in form of early withdraws. Please notice: you can’t have a debt in the token you are depositing, as stated above, or you can game the system

The deposit bonus should be the reverse of CR. So if you deposit 1 BTC and CR is at 20%, you get 5 rBTCs. You are buying BTC at a 80% discount, as with PT, but with no set date. Migth even lead to some fomo if RDNT recovers! Formula is:

rToken received=(deposit)/CR

Please notice that CR stays the same. It’s now (20+1)/(100+5), or 20%. Therefore, the sooner you deposit, the higher the “bonus” cause fee will slowly lower that range, but the more deposits are there, the faster repayment happens and having the same CR with higher operating capital is much better.
Of course, that’s why having more than 50% is much easier to start with…

Very same should happen if you repay. Say that you have 100 ETHs debt token, and current collateralization is 20%. With 20 ETH you close your debt. It’s exactly the same logic applied. If, one day, the protocol recovers or simply the ratio goes up, you made a lot of money leveraging there.

PROTOCOL REVENUES

The portion that is overheads or team should be go partially to token repayment, pro quota per market, in the form of a buyback in case of non-denominated token. But team should still get money to make this worthwhile. Yes, they messed up hard. No, they won’t work for free.

Fees from ALL the working parts of the protocol (eth/base, RIZ, new announced products and so on) should partially go to a buyback fund that once in a while buys, pro quota, all the tokens in the basket, in a share quota value in $. If there are 10M$ of BTCs to recover, 5M$ ETH, 5M$ USD it’s 50%-25%-25%. This way the CR won’t change dramatically in different markets and should stay the same on every chain, or you might create discrepancies as explained later.

Please notice, these tokens deposited to the protocol WILL NOT create a rToken equivalent. So if protocol buys 1 BTC, and the CR of BTC is 20/100, simply the CR will go to (20+1)/100=21% improving the “health” of all the hacked users.

DLP should get their full value in terms of revenues, or a very minor cut. This to give utlity to RDNT token. I also expect a goodwilling gesture from team. Ofc, the full value of the collateral posted, even at a low CR, will be used to calculate the 5% threshold, for the same reason.

REOPENING WITHDRAWALS

This can be simplified and probably helps a lot. Withdraws are closed for a fixed amount of time, say 6 months after the 1 month grace period or so. Might even be less, like 2 months, if team feels confident to go.
After that, users can actually withdraw what they want, but with a penalty to avoid that you can freeroll here. Let’s say a 15% of missing CR is applied; this would increase the redemption ratio of users that withdraw later, creating a positive game theory loop

CR= Collateralization ratio
rTR= rTokens that the user wants to redeem
15%= penalty in this model

Formula applied will be:

rTR * CR - (1-CR) * 15% * rRT * CR, Or
(rTR * CR) * (1-(1-CR) * 15%)

It’s way easier with an Example

Users A and B both have 100 ETHs. There are currently 1000 ETH in rTokens, with CR being 40% (i.e. there are 400 ETHs in the protocol).

User A wants to close his adventure on RDNT, and cashes out. He should get 100 * 40%=40 ETHs, but the penalty is applied: 40 * (1-60% * 15%). A gets 40 * (1-9%)= 36.4 ETH. In the protocol there are now 900 rTokens and 363,4 ETHs, for a ratio of 40,4%

If B withdraws later, he would get slightly more:
100*40,4%=40,4ETH
Penalty is slightly lower: (1-40,4%)*15%=8,94%
User B gets 36,788 ETHs. Protocol is healtier now, there are 800 rETH and 326,612 ETH (CR is 40,83%).

So if users want to quit, they know their losses. The more you keep skin in the game, more fees are generated. If you want an early exit, you improve all subsequent exits. No trading or other potential issues involved.

Please notice that if a user tries to game the system by depositing to get the bonus, he would lose money

Let’s get back to the user depositing 1 BTC and getting 5 rBTCs. If he leaves he gets:

(5 * 20%) * (1-80% * 15%), or 0,88 BTCs

Please notice that he could DO money if he’d deposited at a 20% CR, waits some time and withdraws later. I won’t do the math cause it’s pretty evident, but creates another positive loop feedback for also external users looking for a sort of fixed bond with an early exit possibility

TAKING A LOAN IN EXPLOITED MARKETS

This works in the very same way. AFTER withdraws are open, if you have the health factor (that remember, is reduced by 0.15) to take a loan, take it. Please notice that the amount you actually get is the CR fraction

Example: user has 10 rBTCs and no loans. BTC is at 60% LTV. Let’s say BTC is at 90K$, and user wants to take a USDT loan against his 900K$ “exploited collateral”, so the max he might ask for is 540K$. The CR is 30%. User asks for 500K$; he gets 150K$ and the whole 500K$ are added as debt, of course. That’s the reason for having CR at the very same lvl across different rTokens, or you might create some minor exploits. The buybacks will help to correct these small differences

If his health factor drops below 1, liquidation will happen as usual. The CR of the protocol will improve nonetheless.

If he just takes the loan and stands above HF1, he pays borrowing interests, generating revenues from the protocol that, in the long run, will improve the CR.

If he pays back, the formula is already explained. Please notice, that if the CR went up from 30% to 40%, he now needs to pay back 200K$ (plus the borrow interest)
So, in the end, users can get some liquidity if they want to, but in this case it’s negative leverage unless protocol literally dies

If many user max out their loans cause they don’t care, they will be liquidated and protocol’s CR WILL go dramatically up improving all other users’ potential recovery. Also in this way, we generate more fees

STOLEN TOKENS FOR OPEN ALLOWANCE

This is another very tricky point. It’s impossible to say that users that got their money stolen literally at the hack time are guilty, as probably the users in the very subsequent hours.
But the more time passes, the more it’s hard to salvage them. Hell, this might even be exploitable by the hacker himself.
My idea is, we should put a cut block for users losing money. If you were attacked before the snapshot, your loss is added to the rToken of that kind. So you had 100 USDT? You’ll get 100 rUSDT going for the recovery as above. If you are still with opens allowance days later, I am sorry, but we can’t suffer consequences if you didn’t pay attention (i spent hours and 1000$'s revoking allowances that very night. No, I won’t ask for them). Probably a 24h grace period is fair. Nothing above that. I would leave this open to a vote by DAO, but nothing above that cut

IF WE PAY EVERYTHING?

If all money is paid back (or a recovery happens), CR is at 100%, the recovery rdnt protocol is paused and merged with “normal” protocol. Mark the date on the calendar and have a party every year.

In case of late recovery of hacked funds, the DAO should already decide what might happen. Logic dictates, all the funds are converted pro-quota in the current $ exploited tokens (like in the point above “Protocol Revenues”, for buybacks). If for a miracle there is more than needed, we should give back to angels and investors, pro quota. In the very unlikely case that it’s more than that, it goes to treasury and we put up a vote.
If we repay everything, in any way we should consider to give money back to angels/partners, even at the cost of some less revenues. We made a miracle.

TIMELINE and DEVELOPMENT

I am not a tech guy, more a math guy as you might guess. The contracts above from a math standpoint, once you set variables, are trivial from a logical perspective. I have no idea on how much development is needed and MORE THAN ALL how long audits might take cause if it’s poorly written and there is a way to exploit the protocol to remove deposits for more than the fair share. Therefore I have a suggestion that might lead to implement this waaay faster.

At least at the beginning, and until it’s CLEARLY safe (might be NEVER) any action that removes capital from these contracts is TIME QUEUED, like if you unstake Eth. We might start with 72h window and reduce it the more we get confident, or getting a sort of ok from team to speed up – ONLY if we are sure that this can’t lead to another exploit.

This gives time to team to revert the operation if something is fishy, or in the worst case scenario to pause the protocol. The more we get confident, the lower the timequeues. Of course, the reduction itself should be time-queued at contract level so that no one can change those 72h without approval.

I am not loving it, but this way i’d feel MUCH SAFER to leave capital in my exploited markets or even to add some.
Please notice, deposits or repayments if your HF is dropping are still possible. It’s just removing assets that is delayed.

OUTRO

I don’t know if RDNT can come back to life. I am sure that we need some help and a flywheel, and i think that if team goes with a plan to partners there is some hope. The more we get, the faster, the better

Team must come with a clear plan on fees that they can add on this. Many of them lost money in the protocol so that would be beneficial in any way. Also, don’t even think of creating anything without a timelock.

If users recover trust, fees will keep flowing in. Users that want to quit cause they lost hope will leave and can leave, improving subsequent exits. Probably, if by any chance we get to 90% CR one day the last 10% will be very fast cause users will take a minor haircut with joy, and people that “bought” the rToken at discount will have generated a load of money (also, there are more fees).

I again thank Novin, and I hope to get some feedbacks here also from team

“Forcing people to repay with a 10% LTV (see original proposal) on a non-withdrawable token is VERY bad.” → This isn’t what my proposal says. Original loans will have legacy LTV. I fully agree with you.

“Depositors should get the interest in kind” → Yeah, but I would rather use the loan interest to repay/reduce the deposits than to pay out interest on deposits.

" * Depositors CAN borrow even from exploited contracts, as explained later, after the withdrawals reopen" → You can borrow right away just the LTV is super low and should match the available real coins in the contract.

“If User A has 10 ETH borrowed and 0 in deposit” → How is this even possible? To have a 10 ETH loan you either had to have 13+ ETH deposited or 23k USDC deposited or something similar.

" rTOKENS FOR DEPOSITORS AND REPAYMENT aka *DEPOSIT BONUS" I like this concept but notice this is a ton of extra development. And I didn’t want to propose anything that would be this much dev, considering how slow Radiant is already. My proposal redeploys the existing contracts as is.

“Please notice, these tokens deposited to the protocol WILL NOT create a rToken equivalent.” → Yeah, obviously when radiant deposits they just use the normal contract deposit function, not the one that generates rTokens.

“This is another very tricky point. It’s impossible to say that users that got their money stolen literally at the hack time are guilty, as probably the users in the very subsequent hours.” → Yes they are. They should manage their wallet allowances. Doesn’t matter when they were drained. I know this sounds evil, but depositors should come first.

“I am not a tech guy” → Yeah. I am though. So to develop what you propose will take the radiant dev team 6 months with a full round of external audits and security audits, considering past performance I would not net on a fast deployment. This is my biggest issue with your addendum to my proposal. Otherwise, I would prefer your proposal as well.

Otherwise, we agree on everything as I see it.

  1. Then i probably didn’t get it, cause i assumed that you wanted to make a TVL that is very low, forcing people to repay or being liquidated. And honestly i would take the hit rather than fully repaying. But maybe i didn’t understand

  2. I get your point, if deposits aren’t possible at all. In my model protocol is somehow operative therefore you should get interest, or you won’t be able to attract anyone

  3. This is very tricky mate. If I can borrow fully, this might end to first come, first serve

  4. I just mean, at re-deployment same in kind rtoken and debtoken can’t exist. So you have 1 BTC 100K USD and 50K USD debt; you cancel out those 50 and unloop

  5. This is pretty important to speed up the process without inflating too much. There is one single added variable that is CR. I can’t know if it’s a ton cause in the end it’s literally one signle division to add to the process.
    Also consider that in my idea, withdraws are closed and when they open, they are delayed. I am sure it will need testing and audits. I am happy to wait

  6. Fine ofc

  7. Guess we partially disagree. The moment the protocol “asks” for unlimited approval as preset, I can’t blame the users. The difference, by the way, isn’t insane. Might be handled in a subsequent moment if by a miracle we recover, but i really can’t put it all on users.
    Full disclosure: i am impacted, although it’s just a very low % of my loss

  8. I am sure, but we can centralize some operations to avoid issues and i am a big fan of waiting 2-3 months if needed and then recover 5 times faster. A plan that might lead to repayment of the angels is easier to sell. I am a math and econ guys, and literally i had to think for years of how people might exploit a model long term or reduce the surface of potential attacks from an economical standpoint; therefore, i guess we complete and might find common ground then round the angles

But the TLDR is always:

  • We need some money to start
  • We need the team to work on this and don’t mess up
  • We need info from them

@Novin What do you think of the merit in creating the LP so impacted users can exit their rTokens at a discount and allow speculators/partners/other parties to recapitalize RDNT by acquiring these rTokens to be repaid with future protocol rev as suggested here by @TheGames and @cptgrumpus in his proposal? Or is not compatible with your proposal in some way?

You can read more about the issues of a Secondary Market and Dollarization in my response here: RFP-47b: Debt Token Issuance to Recapitalize Depositors - #8 by Novin

Aside from that, an LP secondary market is incompatible with my proposal since loans are also involved. You could sell your collateral rTokens while having a loan and never have to pay back your loan. It might be feasible if a user had no loans, but then you can throw out my entire proposal.

A @TheGames style secondary market (not LP-based) could work and would address some of my concerns. However, it is quite engineering-heavy, and I’m uncertain how quickly it could realistically be implemented.

Additionally, the goal of “allowing speculators, partners, or other parties to recapitalize RDNT” is already achievable in my proposal. Anyone can deposit funds into the contract to earn RDNT rewards, and we can significantly increase these rewards if necessary. It’s also possible to offer OTC RDNT rewards to major partners to encourage them to deposit into the contract. And they would get back their deposits later.