How Aera V2 Works

Architecture

There are three core smart contracts involved in a given Aera deployment:

• A vault contract implementation conforming to the IVault interface,

• An asset registry contract implementation conforming to the IAssetRegistry interface,

• A hooks contract implementation conforming to the IHooks interface

Our default recommended deployment configuration is the following:

• Use our default vault contract implementation AeraVaultV2

• Use our default asset registry contract implementation AeraVaultAssetRegistry (which supports ERC20 and ERC4626 assets)

• Use our default hooks contract implementation AeraVaultHooks (which supports vault value/outgoing allowance checks and an allowlist for permitted target contract and function signature tuples)

Aera Client (DAO) – Governance/Multisig

The Aera client (treasury) control their Aera deployment through a single account which could either be a multisig or governance contract. This account is the owner account in the corresponding Aera vault, the asset registry and the hooks contract.

Vault Guardian

The vault guardian submits operations to the Aera vault through a single account. This account is the guardian account in the corresponding Aera vault.

NOTE: In future iterations of Aera, the guardian address will become a contract aggregating between multiple guardians.

AeraVaultV2 – IVault

The vault contract is the primary resting place for treasury assets which includes both ERC20 tokens and ERC4626 assets (yield-bearing tokens) that could either be wrappers over simple yield opportunities or custom purchasing flows (such as for options). This contract is referred to as “the Aera vault”.

Treasuries interact with the vault to deposit/withdraw treasury assets and manage other aspects of their deployment. The vault guardian also interacts directly with the vault contract to submit operations. The fee recipient (which may or may not be the same as some of the other roles already mentioned) interacts with the contract to claim any earned fees (if a positive fee is set).

A wide variety of operations can be executed by the vault as long as they are permitted (whitelisted) by the hooks module.

Default implementation: the default implementation of this vault stores assets directly in a security-minimized smart contract. Implementations using a custody solution like Gnosis Safe or other more complex mechanisms would also be viable.

AeraVaultAssetRegistry – IAssetRegistry

The asset registry module controls what assets are currently whitelisted to be used in the Aera vault. The main pieces of information currently specified in the asset registry are the following:

• The numeraire asset (vault value and oracle prices are measured in terms of this asset)

• The fee token (used to pay out fees)

• ERC20 assets and their preferred price oracles

• ERC4626 assets.

AeraVaultHooks – IHooks

The hooks module controls what happens before and after sensitive vault functions. The following 4 actions currently support before and after hooks:

• deposit

• withdraw

• submit

• finalize.

Key users and roles

The vault has an owner, guardian and fee recipient role.

The asset registry has an owner role (the vault role is used upon construction to check for errors in role assignment).

The hooks module has an owner role and a vault role (to authorize vault actions).

The owner of the vault, asset registry and hooks module will always be the client (governance contract or multisig) to provide easy access to funds and for security purposes.

They may elect other entities to manage the asset registry and/or hooks but it's important that there is no possible collusion with the guardian/fee recipient.

The hooks module's vault role will always point to the vault as the authorized smart contract that can execute the hooks.

How the guardian rebalances the vault

The role of vault guardians is to submit portfolio operations that will change the portfolio allocation in accordance with the constraints present in the hooks module to achieve the objective set by the Owner. The default hooks module constrains vault operations with the following invariants:

• it places upper bounds on how vault value can change

• it disallows any outgoing allowances for vault assets to remain after a submission

• it only allows transactions to whitelisted external contracts and function signatures pairs

Assets

The two types of supported assets in Aera vaults are ERC20 tokens and ERC4626 tokens (yield-bearing assets). ERC4626 tokens are implemented to support a variety of yield-strategies or more complex asset purchasing flows (such as purchasing options). The unified interface allows more assets to be supported without adding complexity or size to the primary Aera contracts.

Future directions

The architecture is flexible enough to support several potential future developments:

• Using other custody solutions in place of the Aera vault. For example, a Gnosis safe could be used as the custody layer by combining it with an adapter that conforms to the Aera vault interface IVault. Then Gnosis safe would interact directly with the corresponding asset and execution modules,

• Decentralizing the guardian

• Building more sophisticated hooks

• Adding new asset types.

Limitations

• Upgradability. For security purposes, we have not provided a built-in upgrade path. Nevertheless, V2 aims to make withdrawing all funds simple. The only exception is the hooks contract which can be upgraded live and individual assets in the asset registry.

• Fixed numeraire and fee asset. Aera currently does not support changing the numeraire and fee assets. We don't foresee this being an issue in practice as the best numeraire asset for each vault will usually be established upfront. We will evaluate depeg risk for candidate numeraire assets.