This is an interesting topic, given the quite specific nature of the scenario.
Currently, the majority of the total borrowings of the pool (73%) are still ONE. The majority of those come from accounts using stablecoins (mainly USDC) or ONE (“recursive” positions) as collateral, price movements would affect the following way:
If the price of ONE goes down, it means that the borrowed value is lower and lower, and with it, lower the potential insolvency of the pool. At the same time, positions using ONE as collateral (on an aggregated of ~$1.7m of collateral on positions with ONE, there is ~$687k in aggregated borrowings, with ~$457k being ONE borrowings, so “recursive”) and borrowing assets that would recover in price, would be potentially under liquidation. But considering that ONE has an LTV of 25% and a Liquidation Threshold of 45%, together with that the drop in price has not been until now too big (~ -25% in 7 days), those positions should still be protected, and they don’t even account for much of the borrowings.
If the price of ONE goes up, the borrowed value is higher, which means that the potential insolvency of the pool is bigger, as more liquidations should have been triggered.
As a rule of thumb, there is a high-level interpretation for potential insolvency: as the majority of borrowings are on ONE and the assets used as collateral on those have a higher Liquidation Threshold (e.g. USDC) or they are the same ONE asset itself, potential insolvency will be lower as the price of ONE is lower, no matter other positions in the market. This is especially true if we assume a scenario where the assets affected by the exploit would not be backed back by Harmony.
Would have been great to get this in writing beforehand, but in my view bridge exploits should fully void any safety module protection for Aave protocol deployments on external chains. Aave has basically no control over bridge safety (other than making the decision not to deploy on a particular chain like Harmony in the first place), and even with a proof of reserve oracle mechanism it is likely that markets would become insolvent based on existing cross collateralized positions.
If Aave does commit to covering insolvencies caused by 3rd party bridge hacks, in a worst case scenario this could cause severe impact to other, unrelated Aave markets - safety module funds available for covering other users would decline significantly, and AAVE collateralized loans on other chains could face stress or potential insolvency.
Imo the most sensible stance is to isolate bridge operator risk to the specific platforms involved - so if eg. Harmony bridge is hacked, users of Harmony Aave deployment would not benefit from safety module recapitalization. In my view this does not detract from Aave’s reputation for safety, but rather enhances it (as users can be sure Aave will have sufficient capital to cover losses that are within their sphere of influence).
Unless we are talking about only unbacked bridge-hacked assets;
I don’t agree that this would inspire confidence in Aave’s reputation - I think that this would result in an exodus from users on both alt L1 and Mainnet L2 Aave deployments.
Why would I (the lender) ever put funds into Aave again if my deposits ( of backed assets) are not honored?
I understand that this boils down to Aave/SM covering ‘bad debt’, but if this line of thinking is followed then the only Holy deployment of Aave is on Mainnet Ethereum and the rest should be looked at as akin to completely unbacked insecure CEX lending programs subject to averse events like bridge exploits.
Covering 1USDC, having been exploited, is a tougher sell in my opinion than covering ONE, but in any case I think outright not covering losses in Aave deployments will detract from Aave’s reputation for safety.
All that said, best case would be a scenario where all assets could be covered for depositors, minus obviously those who arbitraged the protocol, because they already got theirs.
As described in the OP post, borrowing on all assets is stopped since hours after the exploit of Harmony Horizon.
The update to lower the slopes of the interest rate strategy is being processed at the moment by the Guardian, to be executed in the following hours.
We have been in communications with the Harmony team about their strategy to cover the losses, with a compromise from their side to come back with a plan in the following days for the Aave community.
We support freezing the assets of the market, in order to avoid further deposits, and will guide the Guardian to execute the action if there is good feedback from the community. In parallel, a warning will be shown in the Aave interface not recommending deposits on the Harmony pool, as a short-term measure.
It is important to highlight that it is possible that, in an eventual “refilling” of funds by the Harmony team, un-freezing (mainly WONE and LINK) assets could be needed.
IMO, if users choose to transact on a less secure sidechain or L2, they implicitly accept the risk that the entire ecosystem will nuke to 0 if the bridge is hacked. I’d prefer this to be made explicit. The alternative is that Aave would be unable to deploy on any sidechains/domains with weak bridge security (risk would be greater than potential reward), which would just limit user choice and options without benefiting them.
Aave would continue to cover risks that are within their sphere of influence (eg if a large price movement in a supported collateral asset, oracle failure, or technical issue caused bad debt), so this would still provide users with a greater sense of security as compared with competing lending markets on these chains (many of which are low effort forks of Aave v2 or Compound with insufficient capitalization to cover even non-bridge risks).
One factor we have to consider for AAVE is that AAVE oracle price doesn’t match with the actual price relative to the major DEXes, thus causing this problem. If the price was correct, this situation won’t happen even when the bridge is hacked and the stablecoin was unpegged. Perhaps, Proof of reserve or change the way of tracking the “real” price will be the forward step of AAVE?
This is a good point. The problem with Harmony V3 market is that the market failed. Yes the bridge was hacked, but this should have only created limited opportunity not a massive theft. As such, AAVE failed its users, and AAVE holds some responsibility. The tokens depegging should have forced the liquidation of many users. Instead the deppeged toekns were sold for tokens that did not depeg. So users of non-depeged tokens were essentially robbed by the protocol. Again this is an AAVE issue. The depeged tokens was a harmony issue. Personally I know the risks of staking AAVE tokens. I would rather get slahsed than have the enitre AAVE name lose its users trust. That would cause far greater damage than a very minor slashing. Honestly think of this as a white hat event. It was a good lesson for the protocol, that could save a lot of money down the road.
The interest rate strategy for ONE has been replaced by the Aave Guardian, to minimize accrual of interest.
The community has also pre-approved the freezing of all reserves on Snapshot here, mainly with the goal of not allowing further deposits until the situation progresses. BGD will coordinate with the Aave Guardian to technically execute this.
We are aware that the Harmony team is working on a compensation plan, and we have provided them the technical details needed to understand the scenario on Aave.
Harmony’s reimbursement plan is completely insane, I hope the AAVE team will not seriously consider it and find an alternative way to release the funds. The harmony bridge was hacked and AAVE not blocked landing of funds, so why do we investors have to pay for the negligence of these protocols? Please take the responsibility you deserve.
The way this discussion has evolved is deeply worrying to me. Specifically, it looks to me like @bgdlabs and risk “experts” like @monet-supply are trying to deflect the responsibility of the insolvencies away from Aave. Presenting the issue as has been done in this post and in some of the comments is equivalent to burying our heads in the sand instead of really looking at the root cause of the issues.
Let me cut to the chase and be very clear: Aave bears significant responsibility for any insolvencies caused by the Harmony bridge exploit. The reason is simple: Aave governance failed in several instances where this kind of attack could have been prevented or mitigated. Specifically, these instances are:
Voting to deploy on Harmony: this one’s straightforward; had Aave governance decided not to deploy on Harmony this exploit would have never happened.
Voting to list the bridged assets: let’s break down this one because it has several pieces to it:
2.1. Had Aave governance avoided listing bridged assets, this exploit would have never happened. A perfectly fine stance would have been to only list native assets.
2.2. Failing to assess the riskiness of the bridge: At what point was the riskiness of the bridge assessed? How was it assessed? Why were the risks not identified? Independently of the answer, the assessment clearly failed.
Voting to use the wrong oracle for the bridged assets: this one surprises me a lot, particularly the explanation given at the introduction:
The issue here has nothing to do with Chainlink and everything to do with Aave governance. And the issue is quite simple: the price needed for bridged assets is not the price of the underlying asset but rather the price of the bridged asset (but the former was used). The rationale for this is that the price of the bridged asset may vary from the underlying for several reasons, including a bridge exploit. In other words, Aave considered the bridged asset to be equivalent to the underlying asset, which is plainly wrong. If Chainlink wasn’t able to provide a feed for the bridged asset (given no CEX listings, low liquidity, etc) then the asset shouldn’t have been listed or a different oracle should have been used. Note that a good oracle wouldn’t necessarily have completely prevented insolvencies but would have definitely mitigated them.
Failing to monitor and react to the risks associated with bridged assets: this isn’t the first time that a DeFi lending protocol suffers from bridge exploits. The following example shows how the exact same exploit happened to a different protocol months before it happened to Aave:
Now, my question is, were the Aave risk delegates aware of this? Was the overall community aware of this risk? Why didn’t they react to it? This amounts to another clear governance failure.
To conclude, let me just ask: Do we wanna move DeFi forward or do we wanna be DeFi apologists?
It was not the intention of BGD and not our role, to give subjective assessments on the opening post. The intention was to provide a technical point of view of the situation for the Aave community, as that is part of the Aave <> BGD engagement. The best example is that we touched on both potential protective measures (e.g. freezing assets) and pro-active measures (e.g. introducing on the Aave tech pipeline research and integration of Chainlink’s Proof-of-Reserve, on which we are already working).
It is clear that any expansion to another chain has risk, including but not only because bridges’ attack surfaces. In the case of Harmony, the Aave community decided to do a deployment of the liquidity pools there, and the risk materialized. That being said the role of BGD is trying to advise the Aave community on 1) how technically solve the current problem, with/without Harmony support, and 2) how to improve the system to be more protected in the future.
From a technical perspective, is highly probable that the plan outlined currently by Harmony will not solve 100% of the current issues on Aave V3 Harmony, only partially. So it doesn’t seem reasonable to interpret that the Aave community is evading any kind of conversation or responsibility, given the amount of discussion here, and the community resources being spent on the topic.
In general, it seems to me that you’re being very hand wavy as to Aave’s responsibility in this matter. This not only muddles the debate about how to respond with the Safety Module but also impedes taking a deeper look into where Aave failed and how it could become more robust going forward.
As an example, let’s take the oracle issue, which you describe as follows:
Here you’re framing it as if Chainlink in fact provided feeds for the bridged assets but they just happened to use the price of the underlying for strategic decisions. This is simply wrong. The fact is that Chainlink doesn’t offer feeds for those bridged assets and Aave governance decided to treat them as if they were the underlying. This is basic and is both a failure from a governance and technical perspective. And you should describe it as such.
Exactly, if this is part of the intention we should be as critical as possible and clearly expose where Aave failed. You haven’t done this, or at least not properly.
The fact that the Harmony plan won’t solve the issue has nothing to do with whether Aave is assuming its responsibility in the issue. Not at all. And by the way, I never said the Aave community, I said BGD and Monet. Fyi: I’m part of the Aave community (as a stkAAVE holder) and have no funds whatsoever on Harmony, so I’m not coming for funds, my intention with the post was to incite a deeper reflection into what went wrong from the Aave perspective, which seemed lacking.
Given current situation of Harmony, I believe the outcome of the proposal is clear - no reimbursement.
I think we should start to conclude AAVE’s position towards this incident. Specifically:
Is AAVE safety module applicable in this case?
If SM is applicable, does it apply to all assets or only for non-bridged assets?
We have to come to a conclusion, even hypothetically, as this case study would certainly set a precedent to AAVE’s position in the future. The decision is probably going to put investors’ confidence to test one way or another. Regardless, we have to take our stand here.
Aave V3 Harmony market is not covered by the Safety module,
Currently and according to governance votes, only Aave V2 Ethereum market is covered by the Safety module. votes are currently ongoing to expand support of the safety module to ARC, Polygon V2 & Avalance V2 markets.