The Aera Approach

Aera features a number of core design ideas that will be referenced throughout the documentation.

A custom strategy for each use case

Each Aera vault uses a custom strategy. Many existing solutions only pursue asset returns (or APY) through yield strategies. Aera is more flexible: multi-depositor vaults can support yield strategies but treasury management clients are in control of what strategies they want to use and how they want to combine them. This includes making contributor payments, managing the volatility of the treasury, providing liquidity in a governance token, diversifying and more.

Note: each strategy is currently not represented onchain in V3. All key metrics are transparently tracked in the Aera UI, but not explicitly required as part of the protocol.

Vault guardian and operations

Each Aera vault elects one or more guardians to submit operations. In the current iteration, the guardian (off-chain) has two responsibilities: allocation and execution. The allocation step decides on a target portfolio allocation based on the given strategy. 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 the vault to make sure all operations are compliant with the whitelist.

Non-custodial ownership

Aera V3 gives the vault owner full ownership and the ability to execute any action from the vault. Guardians can be appointed to allocate assets but they can also perform operational duties with treasury funds such as designing and implementing payment stream contracts for protocol contributors. Unlike other platforms Aera is not trying to move ownership of the funds to a third-party, instead Aera vaults allow treasuries to maintain ownership of their funds while also allowing guardians to take specific limited actions.

Adaptability

At its core, Aera is a layer that helps guardians act on a vault in a controlled way. The exact ways guardian actions are controlled by the Merkle tree and can vary based on each deployment. Vault owners are able and encouraged to pick the protocol integrations and constraints that can help them achieve their specific objectives. More advanced owners can adapt Aera to their needs through a variety of changes ranging from using a different oracle registry, inheriting from the vault contract to add additional functionality and more.