Hey, this is Yaron from the Risk DAO.
At the Risk DAO we monitor bad debt of lending markets (recently added also Moonwell - you can find a link to it from the twitter channel), and publish research material, e.g., on bugs that stem from bad debt Lesson Learned from Bad Debt Related Bugs | Risk DAO.
The DAO is also engaged by few lending platforms to do on-going risk analysis, however we are not engaged with Moonwell, and my interest with Moonwell is mostly academic.
There is no doubt that nomad asset holders were severely affected by the hack, and would potentially suffer even more by a change in the value of the collateral factor.
Further, there is uncertainty on whether the fair market value of nomad assets could bounce back.
However, it is my view that as a principle, a DeFi lending platform configurations and price oracles should reflect the true market conditions. The hope that nomad asset price would bounce back is in principle similar to the hope that any other speculative asset price would go up, and a lending market should not rely on it imo.
As it is currently very hard for the price oracle to reflect the true market price, it is imperative to change the value of the collateral factors.
However, i have some doubts on the assumptions that it will be easy for borrowers to repay their nomad assets debt. In particular, as the nomad bridge halted operation, it might not be easy to obtain large amounts of some nomad assets. wbtc.mad is one example for that.
Hence, reflecting that original market price for the debt assets, while making it artificially lower for the collateral might be unfair to borrowers.
However (2), I didn’t perform any analysis on weather it is a real issue. And if, e.g., most of the debt is from looping, than it should be pretty easy to repay.
Yes, it was a risk offset by the yield the deposits would generate in such situation. There was no risk where someone would propose to set up the collateral factor to 0 and liquidate them when they cannot do anything to prevent this, which is the nature of your proposal.
IYour statement is incorrect. The collateral is worth, at least, 20 cents on the dollar. Nomad has recovered around 37M (https://etherscan.io/tokenholdings?a=0x94a84433101a10aeda762968f6995c574d1bf154) out of the 186M that was stolen. This is the lowest value to be redeemed in the future. If anything, cf should settle at 20% of its initial value (around 0.12) and never 0. The proposal to set it to 0 holds no merit as it is based on a wrongful assumption.
If the proposal does want to consider those situations it should describe the mechanism and the plan to payback. If not, these sorts of statement are pinky promises that hold little value.
I respectfully disagree. Its very much aligned with this thread. Its in the protocol interest to explore all situations that can amend the risks generated by the exploit of the bridge officially promoted by moonbeam. It is on moonwell’s best interest that these intentions should be clear and the path to move forward should not be compartmentalized.
bkase proposal aims, exclusively, to shift the risk to users and omits any other mechanism to cover the losses created by:
a) Moonbeams official promoted bridge being exploited
b) Moonwell unilateral decision to use nomad assets
To shift the blame to users while trying to justify it on wild speculation like liquidity crunches or risk of shorting assets is misleading.
The proposal is damaging to the protocol long-term as it incentivizes liquidations at the lowest possible value of the collateral, while misaligning the interests of the users affected by Moonwell’s unilateral decision to use nomad assets.
nujhe, you are free to create another proposal with those goals in mind. Brandon does not have to include your wish list in his proposal. His proposal seems more narrowly focused on safely re-enabling borrowing.
The Nomad team has not shared the amount that will be returned of each asset, and different ratios were recovered, so it is impossible to know whether USDC.mad is worth $0.20 on the dollar or $0. Further, there is no firm timeline on when the assets will be redeemable, which makes their speculative value uncertain.
A lending protocol cannot function properly if it cannot value collateral. This impacts borrowers and suppliers, so it seems disingenuous to say that this damages users. IMHO what is damaging users more is the inability to borrow, which means suppliers don’t want to supply liquidity. When borrows are re-enabled, suppliers should have more confidence to supply liquidity, which will help the Moonwell protocol recover and benefit all users.
Please feel free to create a proposal or proposals with these options. While some of them would require extensive development time like #1, the community would benefit from considering them.
From my understanding, the only users that could be impacted are (a) those not paying attention during a governance proposal time lock and (b) the less than $100k of user’s collateral that is tied up with looped FRAX which could be paid back by dipping into foundation or protocol funds hypothetically (as I’ve mentioned I currently do not support this as I feel folks who have entered that position took on the risks just like many others who have lost money here, but I’m sure someone could propose it and maybe the community will vote to refund these folks).
The vast majority of the bad debt stays with the protocol and is not pushed to users. Am I missing any details in understanding here?
I think it’s more nuanced than what you’re saying: It doesn’t matter what it’s worth hypothetically only what it’s worth at this moment in markets that are liquid. Even if the approach were to instead change the oracle price to match the market price on stellaswap, Liquidity for mad usdc on stellaswap for example is extremely thin, I think it would be too dangerous to allow this to be collateral at any market price (we’d be setting up the protocol to accrue more bad debt).
It is really a matter of numbers, and these numbers were not reported in the original post, so idk if it is a real concern or not.
From fairness point of view, telling a guy with ETH.mad collateral and USDC.mad debt that his collateral is not longer valid because of the price de-peg, while his debt is still 100% seems unfair.
From a system point of view, as the nomad bridge halted operation, and stella swap liquidity is way bellow $1m, e.g., for USDC,mad <> USD.multi-chain, then it is not clear how easy it will be to repay the debt. And in theory could even bump USDC.mad price above $1, which is again a penalty for borrowers.
So maybe concern is a strong word, and it is more about fairness. And if there are no real users who are affected by it (due to current user composition) then it might be a non issue.
I agree it is nuanced but that assessment is contradictory with your proposal and statement that the assets are worthless.
It is factual that Nomad has recovered 37M.
There are 4 total accounts that have FRAX both borrowed/supplied (folded or looped):
Account 1 is already liquidatable at 0.98 health, however it isn’t likely to be liquidated because it has $349,872.29 FRAX borrowed against $349,832.55 of USDC.mad collateral with only $948.75 FRAX collateral supplied. In other words, this borrower has higher expected value to never repay the loan.
Account 2 has $50,026.96 USDC.mad collateral and $107,935.15 FRAX borrowed, as well as $109,222.43 FRAX supplied. This account is looping/folding FRAX against their original USDC.mad collateral, so they are at risk of having their FRAX collateral liquidated if FRAX liquidity arrives. It should be noted that most of their FRAX collateral was borrowed in the first place, so it is hard to accurately quantify the potential loss for this account.
Account 3 has $3,856.07 USDC.mad collateral and $6,565.59 FRAX borrowed, as well as $6,701.63 FRAX supplied. This account is looping/folding FRAX against their original USDC.mad collateral, so they are at risk of having their FRAX collateral liquidated if FRAX liquidity arrives. It should be noted that most of their FRAX collateral was borrowed in the first place, so it is hard to accurately quantify the potential loss for this account. They also have a small amount $465.01 of GLMR borrowed.
Account 4 has $30,291.76 USDC.mad collateral and $40,417.62 FRAX borrowed, as well as $40,754.81 FRAX supplied. This account is looping/folding FRAX against their original USDC.mad collateral, so they are at risk of having their FRAX collateral liquidated if FRAX liquidity arrives. It should be noted that most of their FRAX collateral was borrowed in the first place, so it is hard to accurately quantify the potential loss for this account. They also have $644.33 of GLMR supplied that is at risk of liquidation.
As far as I can tell, these 4 accounts are the only accounts that would have no ability to repay their looped positions (because there is no FRAX liquidity) unless they buy FRAX on the market somewhere.
Looking further into the data:
Bad Borrower 1 has $1,909,648.82 FRAX borrowed against $1,907,130.22 in USDC.mad collateral. This is the largest “bad loan” in the FRAX market and will likely never be repaid. This borrower originally supplied $3,178,550.37 in USDC.mad, but the FRAX they borrowed is worth more than the likely recovery amount, so they have a higher expected value to never repay the loan.
Bad Borrower #2 is the same as Account #1 above, and will also likely never repay their FRAX loan
The only difference between the top 2 “bad borrowers” that are going to most likely keep $1.9m and $349k FRAX) and the other 3 accounts above are that they didn’t try to maximize their rewards by looping or folding (resupplying their FRAX and borrowing more).
In order for these 3 accounts to get liquidated, the following would have to happen:
The governance proposal to reduce CF to 0 would need to pass.
Additional FRAX liquidity would have to arrive such that liquidators had Frax to redeem.
-or- Liquidators would have to seize mFRAX at a 7% discount (liquidation bonus) and wait until liquidity arrived to redeem (withdraw) it. Most liquidators do not hold capital and use flash loans, so this seems unlikely.
My recommendation: if the 3 potentially negatively impacted accounts do suffer liquidations as a result of this, they could create a governance proposal to use WELL tokens in the treasury to compensate them for liquidation losses, although I suspect the community would deem it unfair to compensate these borrowers without compensating other subsets of impacted users.
As Luke shared, all the data is publicly explorable with retool which I shared a link to in my original post https://moonwell.retool.com/embedded/public/35601b95-b039-4fca-8959-788d153d14a2 . This particular scenario you are describing (whcih I queried for with ETH collateral > 0.01 and USDC borrowed > 0.01) matches 6 users, 5 of them are borrowing negligible amounts (under 100$ each) and the other person who has a meaningful amount borrowed of usdc, also has a meaningful amount of GLMR borrowed which means they’ve actually gained money than if they would have held their nomad assets at this current discount price. This is actually contributing to some of the bad debt in the protocol (ie this scenario is unfair for the protocol, the user has the upper hand).
I have similar suspicions. If the protocol is operating normally, there is no reason for any reimbursements. The problem is created by this proposal, which is why it should be taken into consideration on it and not as a different proposal or a new proposal to deal with the effects of this one.
As it stands bkase proposal creates a problem for a subset of users and doesn’t propose a solution for it.
I see. And also thanks to @bkase for his reply.
I agree that according to these numbers it seems like a non issue.
As for loop accounts, there isn’t a single FRAX available anywhere on moonbeam?
Because technically you can unwind in steps. Repay 1 FRAX debt and withdraw 1 FRAX collateral (ideally in the same tx if it is a smart contract owner),
Of course for $1 gas costs are huge (probably even on moonbeam), but for $1k it might be reasonable even for $1m qty.
There is FRAX available, but right now there is a large FRAX supplier running a bot and he withdraws any liquidity that gets supplied or repaid on the next block, so it makes it extremely challenging for people to unwind their positions.
A Moonwell contributor is at work right now on a feature that will use the batch pre-compile on Moonbeam to do a batch repay/withdraw/repay/withdraw loop to do this in a single transaction so the bot can’t steal your liquidity.
Closing topic as MIP-1 was successfully passed by the community and executed! Thank you to all of the community members who took part in this historic milestone!
