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.