🤓Protocol Overview
Global Architecture
The Atlendis Protocol relies on a system of factories to manage different products and pool instances. This architecture consists in two layers:
the Factory Registry: it manages an allowed set of product factories, each identified by a product ID. It allows to deploy a product instance using one of the allowed product factories. Each product instance belonging to the protocol has an identifier. The registry is unique and managed by governance. Governance can deploy a new product factory, as well as create product instances. This way, the protocol stays modular and allows for new products to be added later on.
the Product Factories: It deploys and initialises instances of products. Each Product instance is a set of contracts, the address of the main contract being reported to the Factory Registry at deployment time. Deployment of a pool can only be triggered by the Factory Registry, which in turn is controller by governance.
the Product instances: A product instance is a set of smart contracts that are independent and have their own lifecycle. In particular, each product instance holds its own tokens and fees, has its own roles definition and its own individual accounting. This allows for a more granular approach in case of issue, only a single instance can be impacted. The main current components of a product instance will de described below. Deployment and initialization are handled by the Product Factory.
Below is a schema of how the different parts of this architecture interact with each other :
Product instance
At first, the Atlendis Protocol v2 will support only a single product, the Revolving Credit Line. However, in the future other products might be added, whether it is a new iteration of the RCLs, or new products with their own logic.
Each product in the Atlendis Protocol v2 has 4 main components, which are used as follows:
the Pool contract: It is the main contract of a product. It is the entry point for lenders and borrowers. It allows lenders to deposit their funds in exchange for a position NFT, which can then be managed or withdrawn. It allows the borrowers to borrow lenders funds and repay their loans. The Pool contract is mainly an abstract layer of accounting, and relies on the Pool Custodian to hold the funds. The Pool and Custodian share an immutable bond. The Pool relies on the Roles Manager to decide what user can do what action on the pool. It also relies on the Fees controller to compute and register the protocol fees taken on user actions. Governance is allowed to update some parameters of the pool, as well as manage its lifecycle. In particular, governance can change the Fees Controller and Roles Manager, in order to allow for different kinds of integrations with these components.
the Roles Manager contract: It handles permissions for all contracts of a single product instance. A Roles Manager is proper to a single pool, and does not handle permissions for other instances. It allows to check whether the calling address has the right role, as well as let these roles be managed by governance. The main roles are LENDER, LENDER_ALLOWER, BORROWER, ADMIN and OPERATOR. The LENDER roles allows users to interact with the pool as a lender, only if the pool is permissionned. This role will typically be given after KYC checks are completed if applicable. The LENDER_ALLOWER role allows users to manager LENDER roles. The BORROWER roles with a user the right to take and repay loans. The ADMIN roles gives the user governance rights. The OPERATOR role gives the role to handle positions transfers. Position transfers being disabled by default, this role will be given in case of absolutely necessity of position transfers, mainly for technical reasons.
The Pool Custodian contract: It handles the user funds. A Pool Custodian shares an immutable bond with the pool. It allows the pool to deposit and withdraw funds according to the pool custodian's accounting of what has been deposited and withdrawn. The Pool Custodian is able to adopt a yield strategy in order to generate rewards based on the deposited funds. The rewards are potentially used by a rewards program which is to be released in a following iteration of the protocol v2.
The Fees Controller contract: It handles fees taken by the protocol on user actions. Actions in the pool wil register fees in the Fees Controller, which handles their accounting. The fees are expressed in the token of the pool, are initially kept by the pool contract, and can be pulled by the Fees Controller to be withdrawn by governance.
Below is a schema of how the different parts of this architecture interact with each other :
Last updated
