The Aera Approach

While a full explanation of the Aera philosophy is available in the whitepaper, we will repeat some of the core design ideas of Aera as they will be referenced several times.

A custom objective function for each client and each use case

Each Aera use case and client relationship is defined by a custom objective function. This objective function defines what “good asset management” looks like in a given context. Many existing asset management solutions presume that the objective function is some direct derivative function of asset returns (or APY). Aera is more flexible, with each client in control of their objective function. As one example, the Aera Volatility Targeted portfolio is able to track towards a target level of volatility.

Note: the objective function is currently not represented on-chain in V2. The objective function will still be transparently tracked in the Aera UI, but not explicitly embedded as part of the protocol. In future iterations of the protocol, we expect objective functions for various use cases to be directly embedded in Aera as a performance feedback mechanism.

Vault guardians and operations.

Each Aera vault elects a set of guardians to submit operations (currently 1 guardian per vault is supported). In the current iteration, the guardian (off-chain) can be decomposed into two parts: allocation and execution. The allocation step decides on a target portfolio allocation. The execution steps decides how to use available routing options to get to the target portfolio distribution. The guardian submits these recommended operations and they are checked by a hooks module which protects the vault against instantaneous loss of value.

In the future, the execution part will be further decentralized, allowing multiple guardians to submit desired portfolios, which will be aggregated and translated into a final set of vault operations.

A growing asset universe

The aim is for Aera to encompass a wide universe of vetted assets for treasury management. While we always recommend starting with a more narrow set of assets, the system is built from the ground up to support tremendous flexibility in both underlying assets and custom purchasing flows. An asset in Aera refers to an ERC20 compatible asset together with a pricing mechanism. V2 supports both pure ERC20 tokens (priced with a contract that implements the Chainlink oracle interface) and ERC4626 type tokens (priced using the built-in conversion rate). This covers a wide range of fungible assets.

Epochs

The Aera vault operates on a pre-defined time duration called the epoch. The primary need for an epoch is to allow enough time for asynchronous execution. For example, ERC20 asset rebalancing is much more cost efficient when executed as a TWAP action rather than a direct trade on an AMM, for instance. The epoch frequency also provides a predictable clock for receiving and aggregating operations when Aera Vault will be generalized to multiple vault guardians.

Note: Epochs are not represented in the protocol level in V2.

Numeraire

The numeraire asset is used for vault internal accounting. For instance, every ERC20 price oracle is used in reference to the numeraire asset.

Fee token

The fee token is a designated asset in which fees can be paid. This may be different from the numeraire asset.

Fees

The protocol can designated a fee recipient to receive fees if the fee rate is configured higher than 0. The fee recipient would accrue a given proportion of the overall vault over time paid out in a designated fee token. In the future, as objective functions become directly embedded on-chain, fees may be modified to include performance-linked components.

Modularity

The Aera system is designed to be fully modular. Modules have multiple valid implementations. We expect vault owners to have more choices over time on how to compose their treasury management solution.