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. 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.
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.
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.
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.
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
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
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.
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.
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)
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.
@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.