Deployment procedures

The Atlendis protocol software implementation follows a simple development lifecycle, a public Git repository is used to track releases.

Three types of releases are considered in the Atlendis protocol:

• a new product type has been created,

• an existing product type has been updated,

• a new instance of an existing product type has been created.

Each release is initiated and approved by a governance multi-signature (threshold of 3-of-5) using Gnosis Safe.

The pool smart contracts are deployed using governance transactions to previously deployed factories' smart contracts. A custom command line interface and process have been set in place in order to handle deployed pools' artefacts.

Initial setup

An initial setup phase is needed in order to enable the future releases.

In this phase, the unique FactoryRegistry smart contract is deployed. This smart contract is controlled by the governance safe and allows the registration of product factory smart contracts by product identifier.

Additionally, helper common smart contracts are also deployed. They include two smart contract adapters describing possible yield strategies for the funds deposited and not borrowed in a pool:

• NeutralAdapter: default choice, funds are not sent anywhere, no yield strategy,

• AaveV2V3Adapter: funds are sent to Aave V2 or V3.

Addition of a new product type

When a new product is considered, the associated factory smart contract must be implemented according to a IProductFactory interface.

Once the factory smart contract has been implemented, the governance can register the deployed factory in the FactoryRegistry smart contract with a bytes32 product identifier.

In the case of the Revolving Credit Line for V2, the associated factory smart contract is the RCLFactory and is registered with the identifier 'RCL' (converted in bytes32).

Update of an existing product type

Factory smart contracts are non-upgradeable. As a consequence, an update must be handled in the same way as a new product type: implementing the updated factory, deploying it and registering it using an identifier reflecting the update, e.g. 'RCL-1.1'.

Creation of a new instance of a product

Once the proper factory is registered in the factory registry, the governance is able to deploy new instances of the setup product type through a transaction on the FactoryRegistry. Each instance is identified by a unique identifier encoded as a string, e.g. poolName-USDC-90days.