Persistent

Core

Philosophy

Enzyme has upgradable vaults, structured to require fund owners to opt-in (migrate) to subsequent major versions.

[Note: previously, the core contracts also gave investors a period during which to opt-out by redeeming shares before an upgrade is final. As vault owners are now considered trusted in core, this period has been eliminated, thus any opportunity to opt-out must be created peripherally.]

Approach

Essential state lives in a VaultProxy , which is moved between releases by upgrading its VaultLib and permissioned accessor via a global Dispatcher contract.

The essential state for a fund is:

• holdings

• shares

• roles

VaultProxy

The "essential state" described above lives in per-fund VaultProxy contract instances, which are upgradable contracts following the EIP-1822 proxy pattern.

The VaultProxy specifies a VaultLib as its target logic, and these logic contracts are deployed per release, and swapped out during a migration.

A VaultLibBaseCore contract defines the absolutely essential state and logic for every VaultProxy. This includes:

• a standard ERC20 implementation called SharesTokenBase

• the functions required of a IProxiableVault called by the Dispatcher

• core access control roles: owner, accessor, creator, and migrator

The owner is the fund's owner.

The migrator is an optional role to allow a non-owner to migrate the fund.

The creator is the Dispatcher contract, which is allowed to update the accessor and vaultLib values.

The accessor is 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 VaultProxy needs no knowledge about a release other than which caller can write state - allows for nearly limitless possibilities for release-level architecture.

Dispatcher

An overarching, non-upgradable Dispatcher contract is charged with:

• deploying new instances of VaultProxy

• migrating a VaultProxy from 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 symbol value for fund shares tokens

The Dispatcher stores the currentFundDeployer (a generic reference to the latest release's contract that is responsible for deploying and migrating funds), and only a msg.sender with that value is allowed to call functions to deploy or migrate a VaultProxy .

This release-level FundDeployer can optionally implement migration hooks provided by IMigrationHookHandler, which give the release an opportunity to run arbitrary logic as the Dispatcher invokes 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 Dispatcher only 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.

Other

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:

Protocol Fee Reserve

The ProtocolFeeReserveProxy serves as a repository that stores collected fees, with upgradable logic for what can be done with the collected assets.

External Position Factory

Deploys new ExternalPositionProxy instances, which are upgradable proxy contracts used to manage positions that live outside of the vault, e.g., CDPs.