Operating SingleDepositorVault

What is the Single Depositor Vault?

The SingleDepositorVault is a vault structure that is designed to operate on funds owned by a single logical owner. It enables basic Aera functionality (guardianship, pausing, etc.) and also enables the vault owner to take actions on behalf of the vault such as depositing, withdrawing and arbitrary execution.

The SingleDepositorVault adds the following features over FeeVault:

1. Direct deposits / withdrawals. The vault owner can deposit / withdraw any ERC20 tokens.

2. Execution. The vault owner can use the vault as a wallet, retaining direct custody and the ability to execute with the vault's funds at all times.

We also provide a default fee calculator implementation DelayedFeeCalculator which should be used in conjunction with the SingleDepositorVault.

Why it Matters

The SingleDepositorVault is can be used to support the following scenarios:

• Treasury management. A treasury could be managed with a SingleDepositorVault. In this sense the SingleDepositorVault is a direct upgrade over the Aera V2 vault allowing the same functionality but with a much more advanced guardian interface.

• Complex integrations. For example, creating a Yearn vault from an Aera vault could be done by using a wrapper over the single depositor vault and encoding owner actions. The recommended approach, however, would be to create a new type of vault that directly inherits from BaseVault.

How to Use the SingleDepositorVault

deposit

Deposit requires you to specify an array of TokenAmount[] where each entry has a token (the deposit token) and amount (the amount to deposit). Each ERC20 token will be directly deposited and doesn't need to exist on a whitelist.

withdraw works analogously but for redemptions.

execute

This function allows the vault owner to execute arbitrary actions by passing an array of OperationPayable[] (with the conventional target, data and value arguments). Note that execute can also be used to transfer tokens out of the vault (among many other things).

No whitelist of actions or hooks are enabled on execute operations (unlike submit constraints for guardians).

Caveats

Note that no tokens are withheld even if unclaimed fees exist in the vault during a withdraw or execute operation. The implicit trust model is that fees have to be claimed regularly by the fee recipient.