Cellar Deployment

The Sommelier Cellars protocol, as described in "Protocol (V2) Contract Architecture", can support many cellars within the Cellars infrastructure. In order to ensure consistency across deployments, Cellars are deployed using a Factory contract.
The CellarFactory contract supports multiple Cellar implementations: they are stored in the getImplementation mapping and keyed by major and minor version number. New implementations can be added by governance using addImplementation: however, existing versions cannot be overridden, ensuring that each Cellar deployed with a given version will have the same base contract logic (before adaptors).
Governance also maintains a list of approved deployer accounts and can call adjustIsDeployer to edit the list. Any caller of the deploy function must be an approved deployer.
Sommellier Cellars use OpenZeppelin Clones for new deployments, ensuring that the incremental gas cost of creating new cellars is low. When deploying, deployers can specify the following parameters:
  • version: the major version to use for the implementation lookup
  • subVersion: the minor version to use for the implementation lookup
  • initializeData: A bytes-encoded calldata struct containing arguments that match the cellar's constructor parameters. This struct specifies initial configuration data around permissions and allowed positions.
  • asset: the asset to use for the initial cellar deposit. Note that this must match the Cellar's configured asset from initializeData or the initial deposit (and thus deployment) will revert.
  • initialDeposit: the amount to initially deposit into the cellar during deployment. Can pass 0 for no initial deposit. Note: making an initial deposit is recommended, as some Cellars can experience accounting issues with 0 deposits.
  • salt: The salt to be used for create2 deployment. The CellarFactory uses Clones.cloneDeterministic, so deployers can control the deployed address of the new Cellar.
When the deploy function is called, initializeData will be used for the Cellar's own initialization flow, which performs the following steps:
  1. 1.
    Configures contract state variables, roles, and sets default values.
  2. 2.
    Initializes the re-entrancy guard.
  3. 3.
    Initializes the holding position, using _holdingPosition and _holdingPositionConfig from initializeData.
These steps imply the following requirements for Cellar deployment:
  • The specified asset must be supported by the PriceRouter.
  • The specified holdingPosition must be trusted by the registry.
  • The holdingPosition can not be a debt position.
If all of the above requirements are satisfied, a new Sommelier Cellar will be deployed on-chain with a single, holding position. After deployment, developers should take additional steps to add the necessary adaptors to the Cellar to enable the desired strategy (see "Using Adaptors"). After the Cellar has been deployed and the strategy's required adaptors have been added, the Cellar is ready for user deposits.