Security
Last updated
Last updated
All relevant issues identified by auditors were addressed prior to the launch of V2.
| Auditor | Scope | Report |
|---|---|---|
Spearbit | V2 | |
OpenZeppelin | V2 LlamaPay Integration |
We also have an active bug bounty with Immunefi and we appreciate all responsible disclosures. Our program size is regularly reviewed and calibrated as our TVL grows.
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.
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 the hooks module currently limits 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). However, the vault is never reliant on the guardian to take actions as the owner has direct access to the execute function.
Guardian submissions
At this stage 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 parameters 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 (e.g., guardian coincides with the asset registry or hooks owner), value could be extracted from the vault. The current solution mitigates this by both requiring those roles to be taken up directly by the client AND 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 hooks module.
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 and only do so with approval from the client. The operation whitelist only allows the guardian to interact with pre-approved contracts.
Please Contact Us to learn more.
