# Aera Protocol in One Page Aera is a noncustodial trustless treasury management protocol. It helps capital allocators achieve various stated objectives by using special actors called *guardians* which have access to off chain intelligence. Aera allows these designated guardians to interact with a whitelisted set of DeFi protocols as chosen by the owner of each vault. Guardians operate in a principled way and are restricted with several constraints enforced onchain. While Aera supports reasonable defaults for deployments, it's a flexible system that can be customized to integrate with any DeFi protocol, used to take treasury management actions such as paying contributors and so on.
#### Aera Vaults Every Aera vault has an `owner` and one or more `guardians` among other roles. The `owner` or specific roles it has assigned can: * Call `setGuardianRoot` to change a given `guardian` and its Merkle tree root * Call `removeGuardian` to remove a `guardian` from the vault * Call `setSubmitHooks` to configure triggers before and after `guardian` transactions * Call `pause` to pause all guardians * Call `unpause` to resume vault operations The guardian can: * Call `submit` to take vault actions * Call `pause` to interrupt all guardian operations (in the event of a possible security incident or another need to visibly terminate guardianship) When using the `FeeVault` contract, in addition the vault owner can designate a fee recipient and a fee calculator contract. The fee recipient (which could be one of the guardians) can: * Call `claimFees` to call accrued fees #### Single Depositor Vaults The simplest way to use Aera is by deploying a dedicated noncustodial vault to manage a set of assets (e.g., a treasury). These vaults give the owner additional permissions. The `owner` or specific roles it has assigned can: * Call `execute` to take arbitrary actions on the vault * Call `deposit` to add assets to the vault * Call `withdraw` to withdraw liquid assets from the vault #### **Multi Depositor Vaults** Aera also supports tokenized multiple depositor vaults that allow multiple depositors to select the same strategy. Multi depositor vaults can be used to share strategies across multiple single depositor Aera vaults or to create externally-facing tokenized strategies. An Aera Multi Depositor Vault allows multiple users to supply capital into a single vault and receive tokenized ERC20 vault units as a digital ledger representation of their supplied assets. Users interact with a separate `Provisioner` contract and can: * Call `deposit` or `mint` to directly deposit into the vault * Call `requestDeposit` or `requestRedeem` to put in an order to deposit or redeem their units (fulfilled by a solver) * When a users requests a Deposit or Redeem, they will asynchronously receive their tokens directly to their wallet from the Provisioner address after their request gets solved. #### How Aera Integrates DeFi Safely The assets in each Aera vault are guarded by two constraints that are imposed on guardian actions: * Guardians cannot leave outgoing nonzero approvals for ERC20 tokens * Each guardian action has to comply with the Merkle tree The Merkle tree is used to check: * If the operation and target contract is whitelisted * If the calldata provided for the call is valid (this is checked by calling a specific operation hook which may extract additional variables from the calldata that are compared against the Merkle tree leaf for that operation). **These are called operation pre-hooks** * If any required cleanup step is successful. **These are called operation post-hooks** #### Contract Overview Here are the most important contracts and their functions in Aera: | Contract | Scope | Function | | ----------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `BaseVault` | All Vaults | The base vault that encapsulates the functionality of having guardians. All vaults inherit from this contract. | | `FeeVault` | All Vaults that inherit from `FeeVault` | The fee vault adds the ability for a fee recipient to claim reported fees. Intended to be used as a incentive for guardians and/or other vault operators. | | `SingleDepositorVault` | Single Depositor | This contract allows a treasury to use Aera. Each single depositor vault empowers the owner with the ability to deposit, withdraw and execute. | | `DelayedFeeCalculator` | Single Depositor | The default fee calculator contract used in single depositor vaults. Allows an accountant to submit vault value over time and calculates fees. Fee accrual is delayed, allowing a vault owner behind a timelock to retire an accountant that is submitting fees incorrectly. | | `MultiDepositorVault` | Multi Depositor | This contract allows multiple depositors to deposit into an Aera vault and receive receipt tokens that represent their units held. | | `PriceAndFeeCalculator` | Multi Depositor | The default fee calculator contract used in multi depositor vaults. Allows an accountant to submit the value of a single unit over time and calculates fees. Accountant snapshots are carefully managed to prevent sudden gains/losses in reported value from impacting depositors. | | `Provisioner` | Multi Depositor | The default contract that depositors in a multi-depositor vault interact with to receive or burn their vault units. | | `OracleRegistry` | All Vaults | A ERC7726 compatible registry of oracles that Aera uses for each base/quote token pair. | **Note**: oracles in this registry are not enforced by default but are used: 1. In common hooks that support trading. For example, trustless swapping on Uniswap requires slippage bounds to be enforced onchain so the Uniswap slippage hook consults the oracle registry for asset prices. 2. To determine exchange rates for deposit assets in multi-depositor vaults. When multi-depositor vaults allow users to deposit in different assets, only one asset is used to price units and the rest are converted via oracle registry oracles. #### Modifying Aera There are several ways to modify Aera to suit different use cases. We will discuss them starting with the simplest options. **Modifying hooks** The default hooks for each protocol are added to cater for the vast majority of use cases. However, it's possible that your use case requires modifications to these hooks or even new hooks to support new types of protocol integrations. Modifying or adding new hooks is one of the easiest way of supporting more complex strategies in your Aera vault. **Using a custom oracle registry** Many of the common rebalancing pre-hooks (such as the Uniswap hooks) rely on the oracle registry to consult asset prices. Some vault owners may want direct control over what oracles they use for pricing, in that case they would need to deploy a custom oracle registry for the vault and use that in all the relevant hooks. **Extending the single depositor vault** Another option that teams have to update Aera contract functionality is to inherit directly from the single depositor vault. This could, for example, be used to make Aera compatible with future standards (e.g., account abstraction standards), to add new treasury-specific functionality (e.g., allow some access to treasury funds by a new role type), etc. The same is true for multi depositor vaults. **Extending the base vault** The single depositor vault inherits from `BaseVault` which provides most of the core Aera functionality. However, in itself it is not opinionated about questions such as how assets move in and out of the vault. More complex use cases like bridge funds or rollup contracts could extend from the Aera base vault and just leverage Aera to facilitate various strategies while maintaining fine-grained control over how assets move in and out of the Aera vault.