In the past we reflected on the multi-layered security strategy of the HydraDX Protocol which resembles an onion and which is designed to keep your liquidity safe. At its core lies our careful approach - to research, to software engineering, but also to deploying POL to the Omnipool. The second layer encompasses economic and security audits conducted by independent third parties which should catch any errors that have slipped through our rigorous review and test process.
Foreseeing that even with these measures something could escape our attention, we have set up a generous bug bounty program as the third layer, offering whitehats up to $1M for reporting critical vulnerabilities, capped at 10% of the direct economic damage. The final layer of our security strategy is reactive - once we have detected a security vulnerability or some abnormal behavior, a variety of mechanisms kick in to mitigate the threat. Until now these mechanisms have been manual (e.g. targeted function pausing by the Technical Committee) but we also have novel automated measures in the pipeline such as circuit breakers and rate limiters.
In this first security update, we would like to share with you that we received and confirmed a bug report by a whitehat which - if it would have been exploited - could have led to loss of Omnipool funds. The good news is that our security strategy described above proved to be effective - the vulnerability was caught before anyone could exploit it, and we adopted timely mitigation measures to make sure that no user or protocol funds can be affected.
If you are interested in the TLDR, the current state of affairs is that we have temporarily mitigated the threat by pausing adding liquidity to the Omnipool. As a long-term solution, we have prepared a combination of measures (oracles, circuit breakers and per-block limits) which will remove the established attack surface by rendering the attack economically unfeasible. We are currently running extensive modeling and tests to make sure that these measures work as we would expect them to. With that peace of mind, we will be resuming adding liquidity to the Omnipool, meaning that HydraDX will soon be fully operational again.
If you are curious to find out in greater detail what happened and how we responded, please continue reading below.
What Happened
We received a report by a top 10 whitehat on Immunefi which brought to our attention the possibility that funds provided to the Omnipool could be extracted in a large-scale, capital-intensive attack. The potential existence of a vulnerability triggered an emergency response in accordance with our established security policy. Team members of research and runtime departments started simulating various attack scenarios, the goal of which was to either confirm or to refute the bug report.
The conclusion of the investigation was that an Omnipool price manipulation attack was indeed possible, if the attacker were to conduct it using a very large amount of capital. Roughly speaking, the attack would look as follows. In step one, the attacker would buy a very large amount of asset X from the Omnipool. In step two, the attacker would provide a lot of liquidity for asset X. Finally, the attacker would close the arb they created in step 1 by selling the whole amount of asset X, thereby profiting by the artificially lower slippage which they created for themselves (at the expense of other LPs), and withdraw their position. These steps could have happened together - in one block, and also they could have been reiterated to extract a greater amount of value.
Our Security Response
Immediately after confirming the existence of the threat, the Technical Committee of the HydraDX Protocol convened and took the decision to pause adding liquidity to the Omnipool, thereby sealing off the largest (by far) attack surface. In accordance with our security policy, we decided to not publicly disclose the vulnerability to the community just yet - we first wanted to make sure that removing liquidity on existing LP positions could not result in any value extraction.
At this point, our team was already in emergency mode and about half of our staff was working around the clock to get a crystal-clear picture of the exact scope of the issue and of the measures that would mitigate it in the long term. We quickly came to the conclusion that a remove-liquidity attack with the existing LP positions would require immense capital to extract a relatively small value. The potential downside of such an attack did not outweigh the disadvantages and potential losses brought by the other possible measure - temporarily halting trading in the Omnipool. Nonetheless, we decided to postpone disclosing this as long as even a remote possibility of value extraction via removing liquidity was possible, and to continue to closely monitor the situation.
Along with the scope of the threat, we identified a variety of measures which - in combination - would remove the attack surface by rendering such action economically unfeasible. First and foremost, implementing on-chain oracles would allow us to automatically trigger a circuit breaker which disables adding or removing liquidity if the Omnipool price for the asset deviates from the market price above a certain threshold. This measure would be complemented by a per-block limit on the amount of liquidity that an LP can provide or withdraw, as a percentage of the overall Omnipool TVL for that given asset. Finally, some reasonable (i.e. not too low) limit on the size of trades would act as a complementary measure to prevent attacks with excessive amounts of capital.
The good news is that on-chain oracles, circuit breakers and per-block limits are features that we have long had on our list, and implementation was well underway. This meant that we could focus all existing capacity of research and runtime on bringing these features to completion. In a matter of just a few days, we finished the development and review process, deployed to Rococo and ran tests to confirm the effectiveness of the fixes. Subsequently, we performed a fast-tracked runtime upgrade of the HydraDX parachain.
With these measures deployed to our mainnet, we firmly believe that no value can be extracted by removing liquidity from existing LP positions. This unblocked the disclosure of this security update which is being shared with you at the first possible and safe moment (the runtime upgrade has just been completed).
Regarding adding liquidity to the Omnipool - our current understanding is that the implemented measures should largely provide remedy also for this attack surface. However, we want to reach conclusive results after running extensive models and simulating different attack scenarios before we resume adding liquidity to the Omnipool. This should happen in the course of the upcoming few days.
We will update you once we are ready to resume adding liquidity.
Oh, baby, baby, it's a wild world
It's hard to get by just upon an audit
Oh, baby, baby, it's a wild world
Sometimes you need them whitehats
– The HydraDX team