Security

Audits

All relevant issues identified by auditors were addressed prior to the launch of V3.

Competition

We completed a Cantina competition for Aera V3: https://cantina.xyz/competitions/ffe90f03-ffd0-449b-a15f-6e7702323d16.

Our Security Framework

We have designed a security framework to mitigate the probability and severity of human error. We actively look for opportunities to add relevant process steps and tooling to our security arsenal.

Highlighted Risks

While these are by no means exhaustive, we think the following risks are helpful to understanding broader vault operation.

Front running risk

On chains and assets where Aera relies on onchain execution through AMMs, there is a risk for price manipulation and loss of value in the vault. While operation hooks currently limit slippage, we recommend only deploying Aera with a trusted guardian as a malicious guardian could atomically sandwich a transaction they initiated and leak value up to the slippage bound.

Limits to real-time response

While guardian code is automated, it's impossible to foresee every possible risk (depeg, hack, etc.) and sometimes urgent actions will be required that the contracts may not support (due to oracle issues in conjunction with these market movements). For treasury management, the vault is never reliant on the guardian to take actions as the owner has direct access to the execute function.

Guardian submissions

The guardian submission process relies on an off-chain algorithm. While we have worked hard to mitigate the power of the guardian role in the contracts, errors in the off-chain code (for example due to errors in data received from an ETL provider) could lead to incorrect operations being submitted to the vault or a missed submission. The vault owner has the power to stop vault operations at any point and to remove the guardian role.

Collusion

If roles are not assigned carefully, value could be extracted from the vault. The current solution mitigates this by only enlisting highly trusted entities as guardians.

Oracle quality

Aera's safeguards rely on onchain oracles to protect guardian actions. While we aim to identify the highest quality oracle for each asset, less liquid assets on less popular chains may carry more oracle risks. When lower quality oracles have to be used, guardian power should be mitigated through the operation whitelist in the Merkle tree.

Dependencies

Aera cannot protect against hacks in the DeFi protocols we interact with. However, we take a conservative approach to proposing new integrations and strategies. The Merkle tree only allows the guardian to interact with pre-approved contracts.

Pricing Risk

Aera V3 vaults are priced by an accountant and could be subject to errors if the accountant service submits an incorrect price due to failures in underlying APIs. The protocol mitigates this for single-depositor vaults by introducing a substantial review delay until new vault values are accepted and in multi-depositor vaults through the use of an independent solver and bounds around price changes.

Solving Risk

Since Aera withdrawals are served by solvers, it's possible that asset withdrawals are delayed past the intended filling frequency. In rare cases (e.g., bridge delays for cross-chain assets) guardians may be delayed in their ability to free up the necessary capital to support a withdrawal. Solving may also be delayed if a vault is paused due to large price fluctuation or accountant service error.

Please Contact Us to learn more.