Deployer/Admin Controls

Contract Names and Functionality

Deployment Manager

The Deployment Manager acts as the admin interface for the creation of all new vaults. The Deployment Manager is ownable, designed to be owned by a multi-sig. The Deployment Manager is the Owner for each downstream contract, limiting access to these critical functionalities.

The Deployment Manager handles three main functionalities in the deployment process, these are;

function addImplementation(bytes32 id_, ImplementationData calldata implementation_) external;
function removeImplementation(bytes32 id_) external;
function deployNewVault(bytes32 id_, bytes calldata data_) external;

The ID parameter that facilitates storage is a bytes32 hash derived from encoding the name and version of the implementation. Example below:

keccak256(abi.encode("Test", 1))

The Implementation struct consists of the following:

struct ImplementationData {
    address implementationAddress;
    bool initDataRequired;
}

In the above example, if you were attempting to deploy a new vault that required an initialization with values passed to it, you would encode and send as bytes as follows:

 bytes memory initData = abi.encodeCall(
            ConcreteMultiStrategyVault.initialize,
            (
                IERC20(address(asset)),
                "Mock Vault",
                "MV",
                strats,
                feeRecipient,
                VaultFees({depositFee: 0, withdrawalFee: 0, protocolFee: 0, performanceFee: 0}),
                type(uint256).max,
                admin
            )
        );


deploymentManager.deployNewVault(keccak256(abi.encode("Test2", 1)), initData);

Vault Factory

The Vault Factory is responsible for creating clones of a given implementation contract. The Vault Factory utilizes the OZ Clones contract, and specifically the cloneDeterministic method, which utilizes Create2 under the hood. The salt is created inside the Vault Factory, and consists of a bytes32 hash derived from the address of the factory and the implementation address.

If the implementation requires an initialization, the factory contract will use a low level call, utilizing the data passed in from the deployer (see above).

Implementation Registry

The Implementation Registry is responsible for maintaining a registry of valid implementations within the protocol. The implementations are stored via their id (see above for ID derivation). The Implementation Registry has three main functions that are callable:```solidity

function addImplementation(bytes32 id_, ImplementationData calldata implementation_) external;
function getImplementation(bytes32 id_) external view returns (ImplementationData memory);
function removeImplementation(bytes32 id_) external;

Vault Registry

The Vault Registry is responsible for maintaining a registry of all deployed vaults. The Vault Registry works in much the same way as the Implementation Registry.

Vault Admin

The Vault admin is responsible for updating already deployed vaults MORE TO FOLLOW