Harmony Horizon bridge exploit. Consequences to Aave V3 Harmony


The Ethereum <> Harmony bridge has been exploited and as consequence, Aave V3 Harmony is potentially affected. We open this thread for the community to discuss and decide about different aspects, and for us (BGD) to help with all different technical details being/to-be considered.


Around ~48h ago, an exploit was executed on the Harmony Horizon ERC20 bridge, allowing users on the Ethereum mainnet to bridge their assets to Harmony One.

~36h ago, the Harmony team publicly notified the existence of such an attack on the following tweet https://twitter.com/harmonyprotocol/status/1540110924400324608, certifying a loss on the bridge of approximately $100’000’000.

ERC20s exploited

Given that some of the assets exploited are listed on Aave V3 Harmony (specifically DAI, USDC, USDT, and AAVE), some dynamics of the protocol have been disrupted.

Aave on Harmony, same as on other networks, uses Chainlink as the main source of oracle prices. In order to consider the market-wide price (not only on/in-chain) of well-adopted assets, Chainlink reports/reported similar prices on the Harmony assets as on other networks: 1 USDC as ~1 USD, 1 ETH as ~ 1’155 USD, etc. This is expected behavior from Chainlink.

Going back to the Harmony bridge exploit, what this type of attack means in practice is that for X amount of an asset locked on a contract on Ethereum L1 there is not exactly X supply of the bridged asset on the connected Harmony One chain, but X - Y locked, with Y being the exploited amount. Consequently, the X supply of the asset of Harmony One is backed only by X-Y assets, so it is trivial to understand that each unit of bridge asset has less value than it should and consequently lower price.

Some accounts on Aave V3 Harmony have taken advantage of this arbitrage opportunity, trusting that the assets on mainnet will not be restored back, making the potentially temporary price divergence, completely permanent. To execute this arbitrage on Aave some accounts (probably the attacker of the bridge, but not necessarily) did the following hours ago:

  • They deposited one of the assets with currently less value (1USDC) enabled as collateral on Aave V3 Harmony.
  • They borrowed assets not exploited: at the moment we can fully confirm ONE, but highly probable LINK too.

The key to this arbitrage is the price divergence on the “real” value of the bridged-exploited asset, compared with the value reported by the oracle, not aware of the exploit itself.

Current situation

At the moment, even if for the protocol the positions with USDC-collateral/ ONE-borrowed are perfectly healthy, in reality, if the assets backing the 1Tokens are not restored by any party on mainnet, they should be under liquidation. This creates an obvious problem for the Aave V3 Harmony pool, same as with any other instance, as one of the main requirements is that all positions under 1 HF should not be opened, and in this case, they factually are.

The specific nature of this problem leads to different aspects to be analysed before taking any decision, in parallel with other measures that can (have) be taken to protect as much as possible without creating potential harm.

What we are taking into account in the analysis is:

  • The priority is to find solutions for all users (apart from people doing the aforementioned arbitrage) that could be affected, and keep protocol-wide health, meaning no bad debt.
  • The market is currently under control of the community Guardian, elected by AAVE holders via Snapshot and strictly following the mandates from this forum and Snapshot. In our opinion, the red line to not cross for the Aave community decisions should be doing “forced” modifications of an account position on Aave. Users are in full control of their funds.
  • There are 1…N entities that maliciously did an arbitrage on Aave V3 Harmony. The system worked as intended and the community should not assume that the entities are the same as the bridge attacker. That being said, we think is legitimate to not try to protect the positions of these users, if they are indirectly affected by pool-wide protections.
  • If funds of the bridge are not backed by return-of-funds or the Harmony Network itself, the Aave community should start an analysis and a discussion if the Safety Module was supposed to cover Aave V3 Harmony or not yet.

Potential actions in consideration

(In no particular order or priority)

  1. Modification of oracles pool-wide. This would be executed by forcing a “real” price of unbacked assets on the price feeds, via Chainlink or not. At the moment, the real price of the assets, as there is barely backing, is close to 0. Given that is not really possible to understand if the situation is permanent or not, this is a really extreme measure that actually will not help the pool: almost all positions would get instantaneously liquidated, but liquidators will probably not act, as collateral would not be liquid. Given the potential complexity of this, probably not advisable.
  2. Minimize interest rates range, especially the ones on assets fully borrowed on the arbitrage. Currently, ONE and LINK reserves are fully borrowed out, but this is because of the aforementioned arbitrage. What this means is that dynamics of interest rates to incentivize/de-incentivize assets’ entries/exits are not really applicable. In addition, the biggest borrowers of ONE are the arbitrators using un-backed assets as collateral, so if we assume the debt of those positions will not be repaid, this is only creating more potential protocol bad debt. We suggest reducing interest rates ranges to the minimum until the situation normalizes, as it can’t do any harm, but can save some minimal accruing of bad debt (we calculated in the order of approx. 30’000 USD per day).
  3. Fully freeze the market, allowing only withdrawals and liquidations. This is something to consider, but probably not a good idea at the moment. The rationale is that once borrowing of everything has been stopped, new deposits can’t be arbitraged by borrowing, but keeping the “door” open for the refilling of collateral or any protocol-wide intervention via deposit/injection of liquidity can be important.
  4. Understand the probability of the Harmony network covering the unbacked assets, via recovering the funds or by covering the loss. This is straightforward: if the attacker would return the funds to the bridge or the Harmony network itself would cover those assets, the Aave V3 Harmony pool would be completely fine.
  5. Integration of Chainlink’s Proof-of-Reserve for bridged assets. BGD had already introduced on its roadmap a proposal to integrate the Proof-of-Reserve into the Aave pools, but an event like that shows the need of it.

Actions executed

  • Stop of borrowing on all assets of the pool. Arbitrage by borrowing non-affected assets was the main vector on Aave V3 Harmony, we have recommended stopping borrowing of all assets, making the situation more controllable without doing any harm in the process.
  • Coordination with Chainlink about historic oracle price last 24h. As expected after our validations, Chainlink has confirmed that their oracle has been working as expected.
  • Data analysis of everything surrounding Aave V3 Harmony and the exploit.

Miscellaneous data/links

Next steps

  • From BGD we will keep monitoring the situation and adding information in this thread whenever there are updates, especially related to any remediation taken by the Harmony network.

Great start to a discussion, thank you for your analysis.

For this specific reason I would like to advocate for an on-chain source of truth as to which markets are, or are not, covered by the safety module.


+1 on this. It seems like something we can move forward in the really short term

1 Like

Linking to the last discussion about he Safety Module, and expanding its protection.

1 Like

I’m curious as to what this means. How would a proof of reserve be integrated into AAVE to mitigate risk?

I think this action is all we should need to take until we figure out how Harmony is going to deal with this. IMO, the SM should cover in the event that Harmony is not capable of covering, as it is simply unacceptable for depositors to lose funds in AAVE. Even if there is not a formal directive for the SM to cover the Harmony market, I think maintaining general user’s trust in the AAVE protocol is very much worth the cost. But Harmony should be held responsible if possible, simply because their ecosystem is the responsible party for the damages.

I definitely agree with this line of action. Interest rates rise to incentivize repayment, but this is not a relevant motivation when depositors borrow with no intent of returning funds. Increases of debt should be kept to a minimum to give sufficient time to figure out a solution before too much bad debt accumulates.


The hacker started to launder their funds via Tornado Cash. It is highly likely the hacker will not return the fund. So potential action 4 won’t happen unless Harmony’s treasury has enough fund to cover it.

Potential Action 2 and 3 are ok. But we need to select the perfect timing to bail out and restart the system.

For potential Action 1, why couldn’t the real price of assets be reflected among the whole Harmony ecosystem such DEXs but just relied on Chainlink oracle?

How will Proof of Reserve help the situation?

Helpful, thanks for linking. It does not seem Harmony is covered in this expansion .

Lots of intriguing perspectives in this thread - I would love to call out a few of the notable ones.

I agree with this sentiment - it builds long-term trust in Aave. However, we must have an estimate of the total loss of funds before committing.

Crypto is risky, you acknowledge this risk every time you interact with a smart contract - but Aave is the best place to minimize this risk.

+1 on @BiologistCrypto’s perspective. Recovering funds via Harmony seems very unlikely.

We may be able to help with this via Flipside’s data. Will report back shortly after looking at the implementation via GitHub.


Yes. @fig Crypto is risky. Thus, we never put all eggs into 1 basket. However, in the event of bankruptcy, the lenders should recover more fund than the borrowers. Otherwise, there will be no incentive and trust for the lenders to supply to AAVE again. Anyway, it look like the stolen crypto will not be recovered as you agreed. What are the option we, the lender, have to withdraw our crypto esp. ONE?

In future, could we set the borrowing interest rate to infinity if this event happen again to discourage people from exploiting AAVE again by depositing unpegged cheap stablecoins or other cryptos?

Simplifying, Proof-of-Reserve is a system that amongst other things, 1) monitors if the underlying assets in an origin (this case would be the deposit contract of the bridge on Ethereum) are equal in balance to the total supply on the destination chain and 2) can trigger actions on the recipient chain if 1) would not be fullfilled. Those actions in the case of Aave would be of protective nature, like stopping all borrowing.

Concerning this, from our perspective, it is worth it to still wait for some time until Harmony defines a recovery plan, as any action from the Aave side in this regard would be dependent on that.

It is important to also highlight and clarify some aspects of the situation:
The underlying assets deposited into Aave V3 Harmony are the main part affected by the exploit, and on that, the Aave protocol has no role and/or solution, as the impermanent/permanent loss would be on the depositors holding the bridged underlying and depositing it on Aave.

The assets involved in the borrowing arbitrage is a different aspect, as it is debatable if the protocol should have allowed the borrowing. But it is important to understand that the situation boils down almost completely to the lack of security on the Horizon Harmony bridge, as this arbitrage is caused exclusively because of the asymmetry of ONE/LINK not getting affected by the exploit vs other assets yes.


Agreed that depegged bridged assets should not be covered. I guess to be specific, I believe that any assets that cannot be withdrawn due to bad debt should be covered in the case that the debt is never returned. The bridged assets themselves being devalued I agree should be considered out of scope for any compensation plan.

Thanks @bgdlabs for gathering the information.

From my point of view, keeping the protocol solvent and protecting liquidity providers should be top priority. In that front, would be great to determine if the assets that cannot be withdrawn since the exploit and the assets that could leave insolvency in the market if real prices are back to Harmony network are the same or not.

Apart from that, I think it is a good idea to wait for updates from the Harmony team. In the meantime, a discussion about the SM coverage should take place (it is also a golden opportunity to pave the way for future potential exploits).

Disabling borrowing would be the best action, and PoR would have helped to mitigate this exploit. The protocol could give permission to a specific contract to disable the borrowing of assets in the case where the bridged assets are not fully backed.

1 Like

How much WONE was allocated for the rewards of using AAVE now? Could we use these WONE to compensate part of the lost ONE while disabling the reward?

1 Like

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.

1 Like

WONE rewards emissions are controlled by the Harmony team, and given the situation, we have recommended them to put those rewards on hold, as currently, they give a sense of false incentivization.

1 Like

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.

Let me know where we differ :slightly_smiling_face:


IMO at least minimizing the interest rates is a good first step to stop the bleeding.

Currently people are still depositing into the app seeing the high interest rate and not understanding the full situation / not being able to likely withdraw their assets afterwards.

If not disabling deposits, it would be good to have a large warning on the frontend as well to at least help avoid people unknowingly trapping their assets without understanding the situation.


Putting forward a first step. Believe that freezing the reserves should happen immediately, followed by (if not bundled) with an interest rate adjustment.

1 Like

An update for the community:

  • 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.