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.
Moving forward this risk could be (should be) covered by using proof of reserves as well;
Chainlink Proof of Reserve provides smart contracts with the data needed to calculate the true collateralization of any on-chain asset backed by off-chain or cross-chain reserves.
I agree that if Aave were to go with the hands-off approach in terms of security risks on less secure chains they should be explicit about that as well.
However, Proof of Reserves should have been in place here and users would be able to withdraw their assets if it had been.
I agree that there are risks to using these other chains but we can’t deny that risk mitigation exists as well which definitely could have been in place.
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.
Your frustration is understandable, AAVE indeed didn’t take immediate action to prevent further lending after the exploit. There was a ARC that takes time to vote, thus the delay in the action.
In regards to your statement:
The withdrawal is not locked, there’s 0 liquidity for you to withdraw as it’s 100% borrowed.
It was sad to see that Aave was accepting deposits for a month after the hack and listing a 1000% APY lol.
Lending was stopped but supply side was left wide open
We believe that the SM shall not compensate for the loss of the Aave V3 Harmony market. As stated by @MarcZeller, only Aave V2 on the Ethereum Network is covered by the SM. This criterion is voted on and approved by the governance. Therefore, it should not change, at the moment, unless a new governance proposal is discussed and approved. Not because Aave is irresponsible for the loss fund, but because this is what the current governance had agreed on.
When did the vote that decided the Safety Modules would only cover Aave v2 Ethereum market happen? Was it before or after the Harmony deployment?
Were users of Harmony aware that they wouldn’t be covered by the Safety Module? Was this highlighted anywhere?
More importantly, should we do what is right or what was agreed a long time ago (probably in a completely different environment and context)? Isn’t DeFi supposed to be a more humane, fair financial system? Are we just gonna use the same fine print bullshit techniques used by TradFi for centuries just to avoid assuming responsibility for this issue?
long long before. The SM policy was set at the launch of the initial V2 ETH market. The first updates to it (covering the other V2 markets) are being voted on now in Snapshot.
It is the responsibility of those using a system to understand it. That is part of what comes with permissionless DeFi.
Anyone is able to propose a governance action for the DAO to vote on. If you feel there is action the DAO should take, write a proposal, bring to vote, and author/deploy the payload. This openness is why DeFi is different.