### **Bug Bounty**
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.
{% embed url="" %}
### **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 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](https://docs.aera.finance/contact-us "mention") to learn more.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.aera.finance/v2-archive/contracts/security.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
.png?alt=media&token=40e29148-73a8-4b91-8c77-6ccc2bb463cc)
.png?alt=media&token=dedee3f0-08be-4701-9fa3-91af8f23a9bc)