Using the Factory

Pre-requisites

Before deploying Aera, it's important to decide and agree on:

• Which network Aera will be deployed on

• Which entities and contracts will be responsible for the owner roles of the vault, the guardian role, the fee recipient (if relevant) and the owner (maintenance) roles for vault module and the hooks module

• Agree on specific versions of the vault / asset and hooks modules to deploy

• [If applicable] Agree who will operate any required additional services

• The objective function used and the targeted epoch period (off-chain)

• The initial asset universe

• The starting configuration parameters of the vault, asset and hooks modules such as the price oracles that will be used for each asset

• Agree on what interfaces will be used to access and monitor Aera (e.g., the Aera front-end).

What if my treasury holdings are different from the assets I want in my Aera vault?

No rebalancing is cost-free and there are some situations where we would recommend exercising care. A common issue is if a protocol treasury consists entirely of their native token. In this case, while the native token could temporarily be supported in the Aera vault and used to rebalance into desired portfolio assets, the price impact of rebalancing a large amount of an illiquid native token could be large.

The Aera team is happy to advise on potential courses of action in these scenarios and we aim to support treasuries as broadly as possible.

Deployment

Aera deployment happens via a designated factory contract AeraV2Factory atomically in the following sequence:

• The asset registry is deployed

• The hooks contract is deployed

• The vault is deployed

We recommend that the deployment of the Aera vault is handled by the Aera team and we have prepared deployment scripts to do so and hand ownership over to the client.