While these are by no means exhaustive, we think the following risks are helpful to understanding broader vault operation.
Front running risk
Where Aera relies on onchain execution through AMMs, there is a risk for price manipulation and loss of value in the vault.
Constrained 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 broken oracles 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.
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.
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.