# Discussion: Reducing Long Tail Asset Risk **URL:** \ **Category:** General\ **Created:** [November 22, 2022, 8:02pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748 "2022-11-22T20:02:48Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![monet-supply](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/monet-supply/32/33_2.png) [@monet-supply](https://governance.aave.com/u/monet-supply)\ **Post date:** [November 22, 2022, 8:02pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/1 "2022-11-22T20:02:48Z")
Hi all, Many of you may be aware of Avi Eisenberg’s “highly profitable trading strategy” on Mango Markets. In the aftermath of this manipulation attack, Aave froze reserves of several low liquidity assets including BAL, REN, and CVX. However, the CRV market was not frozen and it seems that the protocol is now at risk of accumulating significant bad debt due to a tactical short position that Avi entered with the intention of precipitating a short squeeze. This has so far resulted in his initial position accumulating around [$1.5 million of CRV denominated bad debt](https://aave.blockanalitica.com/wallets/0x57e04786e231af3343562c062e0d058f25dace9e/). In a worst case scenario, continued price action could lift CRV far above fair market value and allow users to withdraw excessive liquidity from other assets based on inflated collateral value (although CRV liquidation threshold is only 61% so this risk is relatively lower). I’d like to open discussion on potential mitigation measures to reduce imminent risk to the protocol from manipulation of low liquidity assets. While these parameters could be optimized, I think it’s best to avoid analysis paralysis and implement some common sense changes as soon as possible. Some initial suggestions: - Reduce liquidation threshold to 80% for any assets that currently have a higher value (DAI, USDC, TUSD, ETH, stETH) - Reduce max LTV to 75% for any assets that currently have a higher value - Freeze reserves (prevent new deposits and borrows) and set max LTV (initial margin) to 0% for low liquidity assets at risk of similar short squeezes that are listed as collateral (BAT, CRV, DPI, ENJ, ENS, MANA, MKR, SNX, xSUSHI, YFI, ZRX) I believe the above changes will significantly reduce risk to the Aave v2 ETH market while further optimizing changes can be considered through governance. Aave v3 includes significant improvements to risk management options, which could allow for greater capital efficiency and wider asset listings once launched on mainnet. Discussion and other suggestions from the community are welcomed. Hopefully an existing delegate or service provider will be able to submit consensus changes in the coming days, potentially without including the standard Snapshot voting process in the interest of expediency. ---
**Author:** ![jarnMod](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/jarnmod/32/2513_2.png) [@jarnMod](https://governance.aave.com/u/jarnMod)\ **Post date:** [November 22, 2022, 8:34pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/2 "2022-11-22T20:34:42Z")
I agree that we need short-term action to prevent further exploits like this. The tweet about the small amount of bad debt like a million dollars may be fine for the team, but for users it’s a cardio at best. I lack the critical knowledge to contribute to the solution, as I don’t even know how V3 supposedly prevent this. My concern is the safety of AAVE as a user who supplies fund to the protocol. I’m more concerned about the AAVE core team’s lack of communication than anything else. I spend time on AAVE discord and I don’t know if any team member shows up to provide update on the team behave. Maybe it’s world cup syndrome but it’s still not fun. **With my limited knowledge. I support OP suggestion on the 2nd and 3rd point. I don’t think 1st will be necessary and per my understanding, the least change should be the fastest to implement. Speed is of essential on this issue**. My current idea is maybe the liquidation threshold should be dynamic given the amount of AAVE staked? Like they come in new and suddenly borrow a big chungus out of AAVE, that’s a weird sign on the get go, no? How about if they do that, their liquidation threshold as untrusted new user is like 50%. Because we don’t know you. Instead, if the user is around for a while. Been supplying coins for years and stake AAVE for a while to boot, they’re less likely to attack the protocol all the sudden. So, their liq is like 80%. Of course if they play something funny their AAVE gonna get slash and their “credit rating” is cut. Maybe that credit rating can be NFT like Uniswap too. I don’t mind ghosty nft card for supplying fund for a year. Please consider quick and decisive reaction to the problem, team, as OP has said. If you can’t solve it out right, at least mitigate this risk or communicate more. Much appreciated and shout out to AAVE Discord. You guys are smart cookies. ---
**Author:** ![CometShock](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/cometshock/32/2514_2.png) [@CometShock](https://governance.aave.com/u/CometShock)\ **Post date:** [November 22, 2022, 9:28pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/3 "2022-11-22T21:28:39Z")
Crossposting another discussion topic started shortly after this one: > [@\[ARC\] V3 Supply Cap Recommendations for Uncapped Assets (Fast-track)](https://governance.aave.com/t/arc-v3-supply-cap-recommendations-for-uncapped-assets-fast-track/10750): > > The objective of this proposal by Chaos Labs is to recommend supply caps for v3 assets that are currently uncapped. This proposal follows the fast-track process for increasing supply caps as outlined [here](https://governance.aave.com/t/arc-v3-supply-borrow-cap-management-fast-track-process/8045). It’s important to note that these are initial supply caps for these assets and will be iterated upon. The recommendations for every asset on every chain take into consideration: Asset Market Cap Asset Counter Party Risk Asset Volume Asset Liquidity (DEX and CEX based) Historical Liquidations… ---
**Author:** ![Jommi](https://avatars.discourse-cdn.com/v4/letter/j/db5fbb/32.png) [@Jommi](https://governance.aave.com/u/Jommi)\ **Post date:** [November 22, 2022, 10:05pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/4 "2022-11-22T22:05:42Z")
So are we going to explore having Gauntlet pay for some of this bad debt as they promised in > [@Insolvency Refund from Gauntlet](https://governance.aave.com/t/insolvency-refund-from-gauntlet/10048): > > Summary To increase our alignment with Aave and put “skin in the game,” we will refund a portion of our service fee should our risk parameter optimizations incur losses for the DAO during Gauntlet’s engagement. Our ultimate goal is to protect the protocol - we stand behind our work and want the community to have confidence in our optimizations. Motivation Two main motivations are driving this effort from Gauntlet. First, we want to signal our commitment to rigorous risk management for the DA… You can see from the thread below that: - They have 0 clue there were risks for bad debt before the Mango Exploiter did his first exploit - Even then failed to actually provide the right assessments to cover > [@\[ARC\] Price Manipulation Implications on Aave: October 2022](https://governance.aave.com/t/arc-price-manipulation-implications-on-aave-october-2022/10262): > > The recent Mango market exploit has brought to the forefront of the DeFi community the risk of liquidity attacks on lending platforms. Here is a great Twitter thread from @[joshua\_j\_jim](https://twitter.com/joshua_j_lim/status/1579987648546246658?s=46&t=q1NuYJ8isG-4kWHYZGuldg) showcasing how the user exploited Mango’s low market liquidity to drain $100M from the Mango market. This liquidity attack reaffirms the high risk of oracle pricing manipulation for low liquidity assets. Gauntlet is continuing to analyze Aave’s V2 assets to measure the future risk of liquidity attacks and will fo… Why are we paying Gauntlet millions instead of actually putting out a tender for multiple players to offer their risk services to AAVE? Now, after bad debt is accrued they come with spray and pray effort to save grace and freeze a huge amount of markets. > [@\[ARC\] Risk Parameter Recommendations for Aave V2 ETH (2022-11-22)](https://governance.aave.com/t/arc-risk-parameter-recommendations-for-aave-v2-eth-2022-11-22/10757): > > Summary A proposal to make parameter changes on Aave V2 ETH. Given that the market situation of these assets is currently volatile, out of an abundance of caution, we recommend temporarily freezing the following markets: YFI CRV ZRX MANA 1inch BAT sUSD ENJ GUSD AMPL RAI USDP LUSD xSUSHI DPI renFIL MKR Motivation Aave V2 lacks many of the risk controls that Aave V3 solves for (supply caps, borrow caps, isolation mode, e-mode, etc). Out of an abundance of caution and given the community’s curre… ---
**Author:** ![michwill](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/michwill/32/2515_2.png) [@michwill](https://governance.aave.com/u/michwill)\ **Post date:** [November 22, 2022, 10:23pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/5 "2022-11-22T22:23:12Z")
Concern is clear, but actually the problem was too high LTV for borrowing low liquidity assets. For borrowing CRV against USDC it is more than 80%+ while for borrowing USDC against CRV it is 55%. Latter is safe, former is not. If not possible to make symmetric, borrowing at that high LTV should probably be disabled. This was done for CVX btw - it is possible to borrow against CVX but not possible at the moment to borrow CVX. Long-term though, better to have similar LTV for both sides of the same pair. ---
**Author:** ![oneonlymechanic](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/oneonlymechanic/32/2520_2.png) [@oneonlymechanic](https://governance.aave.com/u/oneonlymechanic)\ **Post date:** [November 22, 2022, 10:33pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/6 "2022-11-22T22:33:08Z")
Rather than making it symmetric, there should be two separate parameters, one for the collateral asset, another for the borrow asset. Similar to what Euler has done. ---
**Author:** ![michwill](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/michwill/32/2515_2.png) [@michwill](https://governance.aave.com/u/michwill)\ **Post date:** [November 22, 2022, 10:40pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/7 "2022-11-22T22:40:38Z")
It depends on what you mean here. But borrowing ETH against USDC and CRV against USDC are two very different things. Of course, ideal would be parameter pairs like LTV[A,B] and LTV[B,A] but not sure if possible ---
**Author:** ![michwill](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/michwill/32/2515_2.png) [@michwill](https://governance.aave.com/u/michwill)\ **Post date:** [November 22, 2022, 10:47pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/8 "2022-11-22T22:47:25Z")
Just to sink that in. Current LTV when borrowing literally anything against USDC is 87%! ---
**Author:** ![ProfitMaxi](https://avatars.discourse-cdn.com/v4/letter/p/3be4f8/32.png) [@ProfitMaxi](https://governance.aave.com/u/ProfitMaxi)\ **Post date:** [November 22, 2022, 11:05pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/9 "2022-11-22T23:05:15Z")
I don’t like Gauntlet and they were pretty useless while working with Balancer. They are now showing incompetences with risk management at AAVE. We should break up the deal with them and find another service provider ---
**Author:** ![bneiluj](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bneiluj/32/2519_2.png) [@bneiluj](https://governance.aave.com/u/bneiluj)\ **Post date:** [November 22, 2022, 11:42pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/10 "2022-11-22T23:42:15Z")
Yes that’s crazy. Being able to borrow long tail assets against USDC above 80% is really not safe. ---
**Author:** ![oneonlymechanic](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/oneonlymechanic/32/2520_2.png) [@oneonlymechanic](https://governance.aave.com/u/oneonlymechanic)\ **Post date:** [November 22, 2022, 11:43pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/11 "2022-11-22T23:43:14Z")
Indeed. in my param pair example. let’s say USDC has collat ratio of 0.8 and borrow ratio of 0.9. Crv has collat ratio of 0.5 and borrow ratio of 0.6. To borrow CRV against USDC, total amount allowed will be 0.8 \* 0.6 = 0.48 To borrow USDC against CRV, total amount allowed will be 0.5 \* 0.9 = 0.45 Not sure if this is possible though in Aave. ---
**Author:** ![monet-supply](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/monet-supply/32/33_2.png) [@monet-supply](https://governance.aave.com/u/monet-supply)\ **Post date:** [November 22, 2022, 11:57pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/12 "2022-11-22T23:57:45Z")
I don’t think this feature is currently available, but would definitely prove useful to allow the largest assets (eg. ETH, USDC, WBTC) to maintain maximum capital efficiency while avoiding overborrowing of smaller assets. ---
**Author:** ![oneonlymechanic](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/oneonlymechanic/32/2520_2.png) [@oneonlymechanic](https://governance.aave.com/u/oneonlymechanic)\ **Post date:** [November 23, 2022, 12:12am UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/13 "2022-11-23T00:12:55Z")
Yeah that’s what I thought. Otherwise would have been a straightforward yet tangible improvement. ---
**Author:** ![cwellington](https://avatars.discourse-cdn.com/v4/letter/c/c37758/32.png) [@cwellington](https://governance.aave.com/u/cwellington)\ **Post date:** [November 23, 2022, 3:03am UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/14 "2022-11-23T03:03:54Z")
Get the notional size of bids in the orderbook compared to the notional borrowed on AAVE. If the borrowed amount of a coin is greater than 5% (or X%) of the depth of bids in the orderbook, then prevent borrowing or some other deterrent (high APR, liq threshold lowering for new borrows, etc.). For example: Assume $100M is being borrowed on ETH. Calculate the weighted average liquidation price from the orderbook of $100M bids. Assume there is $100M of bids within 1% depth of the orderbook. That’s a 1% impact on the price, but on other pairs there could be 5% or 10% depth of bids, which is much more risky. The percentage difference of the current price and the weighted average liq price is the risk associated with slippage. ‘Overaccounting’ for this percentage at all times could mitigate the “bad debt”; however, this assumes the implication that the bids will remain and aren’t spoofed. ---
**Author:** ![ccb\_roci](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@ccb\_roci](https://governance.aave.com/u/ccb_roci)\ **Post date:** [November 23, 2022, 4:03pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/15 "2022-11-23T16:03:00Z")
I cannot comment on the validity of Gauntlet recommendations, but I do agree with @monet-supply that common sense updates to less liquid assets should be taken ASAP; including a reduction of LTVs across the board for remaining assets to buy ‘breathing room’ until a proper post-mortem and next steps can be planned with data. Some may have seen from my previous posts that RociFi credit scores can be used for Aave risk management. We also generate a _ **fraud score** _ which assesses the probability that an address is a _fraudulent actor_, i.e. has known ties to hacks, phishing, exploits, etc.; with 1 being the lowest (best score) and 10 as the highest. We discriminate users on this criteria given those with higher scores are more likely to ‘steal’ money from our protocol. **Note:** the credit score curated to Aave community thus far has been _ **without** _ fraud score inclusion. **Idea:** This isn’t a complete solution, i.e. still requires integration with service provider like Gauntlet, Chaos Labs, etc., but assessing Aave users _ **fraud score + credit score** _ based on asset pool utilization could give Aave an ‘early warning’ system for these types of “profitable strategies.” **For example,** if the CRV pool’s borrow utilization went from 1% to 10% of higher fraud score borrowers, Aave could proactively lower LTVs or discontinue borrowing in a particular pool to mitigate bad debt risk until further investigation took place. The above combined with credit scores for good borrowers could offer a robust way to track risk from the user to the protocol level. We stand ready to answer any questions. **Note:** For transparency, we have never integrated our fraud score with another lending protocol (we only use it for RociFi). So, the explained benefits are theoretical but could easily be tested in PROD with minor tech integration. * * * Breakdown of Avi’s attack wallet -` 0x57E04786E231Af3343562C062E0d058F25daCE9E` - Credit score 10, bad credit - Fraud score 10, highly likely bad actor (which we know with certainty in this case) - 14 total borrows, all-time - Wallet age of 374 days - $0 in total debt repaid, all-time - 385 liquidations, all-time - $78.4M total liquidated amount, all-time ---
**Author:** ![Jommi](https://avatars.discourse-cdn.com/v4/letter/j/db5fbb/32.png) [@Jommi](https://governance.aave.com/u/Jommi)\ **Post date:** [November 25, 2022, 1:05pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/16 "2022-11-25T13:05:55Z")
So they’ll just transfer the USDC 10 times over to a new wallet, and have a clean score. What then? ---
**Author:** ![ccb\_roci](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@ccb\_roci](https://governance.aave.com/u/ccb_roci)\ **Post date:** [November 25, 2022, 7:14pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/17 "2022-11-25T19:14:49Z")
Hey @Jommi - can you be a bit more specific? Talking transferring USDC from the bad wallet to a fresh wallet? If so, there will be a transaction linkage that can be traced back to the original fraud wallet, thus a higher fraud score can be assigned to the new one. Talking transferring USDC from an exchange to a fresh wallet(s)? If so, yes, that would make it difficult to detect fraud. However, if the attacker need to break up the funds and send it to multiple ‘burner’ accounts to obfuscate his intentions before transferring to one main account for the attack, two things occur. (1) Increases the cost of the attack (which could make it uneconomical) (2) Leaves similar transaction linkages that are common in fraud actors, which could enable fraud detection of the attacking wallet using scoring. The described behavior is very common with phishers / hackers / exploiters. ---
**Author:** ![digi7287](https://avatars.discourse-cdn.com/v4/letter/d/b9bd4f/32.png) [@digi7287](https://governance.aave.com/u/digi7287)\ **Post date:** [November 28, 2022, 4:01pm UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/18 "2022-11-28T16:01:37Z")
@monet-supply The CRV attack wasn’t an attempted short squeeze, it was an attack on the reported oracle price (by massively dumping crv to wick price low enough to withdraw all collateral - the exact opposite of a short squeeze everyone thinks it was) and if AAVE keeps under this assumption, it’s going to find itself at risk of significant attacks in the future. I submitted a bug bounty detailing the exact CRV attack well before it happened and was ignored and not paid a bug bounty. While all these debates about the proposals are fine, imo AAVE would find more utility (1) getting the facts right on this attack (it was not targeted at CRV liquidity/short squeeze; it was targeted at outdated price oracles); (2) paying out bug bounties to dedicated white hat systems analyzers like myself who have submitted bug bounties detailing the exact nature and path of this exploit well before it occurred, which if heeded, would’ve saved AAVE the $1.5m in bad debt it accrued, and the $20-$40m that was actually vulnerable. See me comment here: [Risk Parameter Updates for Aave v2 Ethereum Liquidity Pool (2022.11.25)](https://governance.aave.com/t/risk-parameter-updates-for-aave-v2-ethereum-liquidity-pool-2022-11-25/10824) ---
**Author:** ![steviejay](https://avatars.discourse-cdn.com/v4/letter/s/b77776/32.png) [@steviejay](https://governance.aave.com/u/steviejay)\ **Post date:** [December 19, 2022, 9:28am UTC](https://governance.aave.com/t/discussion-reducing-long-tail-asset-risk/10748/19 "2022-12-19T09:28:47Z")
it makes sense. at least i know ill be getting something for my contribution