Operating your Vault
Emergency operations
Every vault can minimally be seen as a wallet. Specifically, the execute
function can be used by the owner to directly execute a transaction. We do not recommend doing this outside of emergencies, however, as it can interfere with the restrictions that guardians have on the vault. We also recommend pausing the vault ahead of doing this to minimize follow-up or interfering transactions from the guardian.
For example, a vault owner could use execute
to leave an open allowance which a malicious guardian could then exploit by transfering the funds.
Depositing funds
One of Aera's distinctive features is the ability to receive deposits in any combination of the supported assets. This means that clients can generally deposit whatever assets their treasury can most conveniently access and the Aera vault will be rebalanced by the guardian to ensure that the correct portfolio distribution of assets is achieved. Deposits support both ERC20 and ERC4626 assets.
Note: assets not currently registered in the asset module need to be registered before deposit.
Withdrawing funds
In similar fashion to deposits, assets can be withdrawn from the Aera vault. However, there is a small caveat: if enabled, some amount of vault fees could be owed to the fee recipient and need to be claimed.
Retrieving accidentally sent funds
Both depositing and withdrawing funds happen through the appropriate functions in the Aera vault. If a user accidentally sends ERC20 tokens directly to the vault, they can still be retrieved using the execute
function which gives the owner full control over vault actions.
Adding an asset
Adding a new asset means registering it with the asset registry only. After the asset has been registered, it can be safely deposited into the vault.
Removing an asset
Removing an asset can be done simply by updating the asset module. However, the vault must have a 0 balance of this asset so a withdrawal is necessary first. It's important that an asset removal is communicated to the guardian.
Emergency actions
Pausing execution. The vault can be paused using pause
, which will prevent further actions by the guardian.
Changing the vault guardian. The vault guardian (and the corresponding fee recipient) can be changed in circumstances where the original guardian is not trusted or the guardian needs to change their wallet address.
Updating the Hooks contract
The vault owner can safely update the hooks contract, which will trigger the existing hooks contract to be decommissioned. This will be a rare operation.
Finalizing the vault
In order to formally terminate an Aera vault or facilitate the urgent withdrawal of all assets, an Aera vault can be finalized. Finalization will:
Stop any guardian actions
Send all assets to the owner
May trigger additional actions if embedded in
beforeFinalize
/afterFinalize
hooks
Retrieving stuck assets
ERC20 tokens not part of the asset universe can be withdrawn using execute
. Note that ERC4626 tokens double as ERC20 tokens and can also be withdrawn.
Upgrading the vault
There is no official upgrade path to Aera vaults for 2 reasons:
Upgradability is a security risk
Aera is a rapidly evolving product in a novel domain and we are focused on making substantial improvements first.
However, every client should be able to move to new versions of Aera vaults as they become available or make new deployments that use different modules (e.g., different asset registry) over time.
Soft upgrade
In this initial period, the objective function is still decided off-chain. It influences code that the guardians use off-chain to submit parameters to Aera vaults.
A client may coordinate an explicit change in the objective function which may not require any updates to smart contracts provided that:
The new objective function is agreed by both client and guardian(s)
The existing modules are compatible with meeting the objectives of this objective function (e.g., the execution approach is appropriate).
Changing the objective function is called a “soft upgrade”.
Hard upgrade
A hard upgrade requires a re-deployment of a new Aera vault. This could occur when:
The client wishes to switch any of the core modules (vault, asset registry, hooks)
The client wishes to upgrade to a new version of the Aera protocol
The three-step procedure to do this is as follows:
Agree on closure protocol/timeline and upgrade target
Finalize existing vault
Follow on-boarding process for new vault.
Last updated