Enzyme has upgradable vaults, structured to give both managers and investors the opportunity to opt-in (managers) or opt-out (investors) of major updates.
Essential state lives in a
VaultProxy, which is moved between releases by upgrading its
accessorvia a global
The essential state for a fund is:
The "essential state" described above lives in per-fund
VaultProxycontract instances, which are upgradable contracts following the EIP-1822 proxy pattern.
VaultLibas its target logic, and these logic contracts are deployed per release, and swapped out during a migration.
VaultLibBaseCorecontract defines the absolutely essential state and logic for every VaultProxy. This includes:
- a standard ERC20 implementation called
- the functions required of a
IProxiableVaultcalled by the
- core access control roles:
owneris the fund's owner.
migratoris an optional role to allow a non-owner to migrate the fund.
Dispatchercontract, which is allowed to update the
accessoris the primary account that can make state-changing calls to the
VaultProxy. In practice, this is the release-level contract that interacts with a vault's assets, updates shares balances, etc.
This extremely abstract interface - in which a
VaultProxyneeds no knowledge about a release other than which caller can write state - allows for nearly limitless possibilities for release-level architecture.
An overarching, non-upgradable
Dispatchercontract is charged with:
- deploying new instances of
- migrating a
VaultProxyfrom an old release to the current release
- maintaining global state such as the current release, the global owner (i.e., the Enzyme Council) and the default
symbolvalue for fund shares tokens
currentFundDeployer(a generic reference to the latest release's contract that is responsible for deploying and migrating funds), and only a
msg.senderwith that value is allowed to call functions to deploy or migrate a
FundDeployercan optionally implement migration hooks provided by
IMigrationHookHandler, which give the release an opportunity to run arbitrary logic as the
Dispatcherinvokes those hooks at every step of the migration process.
As was the case described above with the
VaultLibBaseCore, this abstracted notion of a
FundDeployer- in which the
Dispatcheronly cares about its identity for access and for optional callbacks - is totally unrestrictive to the shape of the release-level protocol.
Release-level contracts, then, are mostly arbitrary from the standpoint of these persistent contracts, offering maximum flexibility for future iterations and changes.
In addition to the core persistent architecture that endures across all releases, there are also persistent components whose lifetimes can span one or many releases.
Used in this release:
ProtocolFeeReserveProxyserves as a repository that stores collected fees, with upgradable logic for what can be done with the collected assets.
ExternalPositionProxyinstances, which are upgradable proxy contracts used to manage positions that live outside of the vault, e.g., CDPs.