Factories

Importance of the Factories

The purpose of our factories is to enable users to easily deploy workflows on their own. We use a combination of two factories to deploy workflows:

  • Module Factory: Enables the creation of the Inverter Modules. Users can choose from a list of deployable modules the so-called module library.

  • Orchestrator Factory: Enables the creation of an orchestrator and uses the Module factory to attach and create the predefined workflow modules.

Workflow deployment

Our factory setup enables us to provide permissionless deployments of custom workflows. The user should be able to have complete control of how their workflow should look and how to configure it.

As described within the Upgradeability page and Intervention Mechanism sections, we use a beacon proxy structure to deploy our workflows. This enables us to efficiently update all contracts at once as well as to pause functionality in case of emergency.

For some users or use cases this might not be the ideal solution so we provide a non-beacon proxy deployment variant. In that case, the users can decide for themselves if they want to upgrade to the newest version, but they don't profit from the maintenance and emergency solutions of the beacon proxy pattern.

Module Library

As described above the Module Library is a register of all available modules that the module factory can deploy. As it currently stands the listing of new modules can only be done through the Governor contract see Governance page. This is to hold up our quality and security level in the early stages of the inverter protocol. At a later point in time, we are planning to open up the registration of new modules to the community.

Last updated