.jpg%3Falt%3Dmedia%26token%3D6f102cef-a7bb-4b84-b0fa-6e502b082829)
.jpg%3Falt%3Dmedia%26token%3D6f102cef-a7bb-4b84-b0fa-6e502b082829)
Integration
How a borrower can interact with their pool(s).
Atlendis separates the pool creation process from the actual action to borrow and repay on a pool. For that matter, after a pool is created, borrowers will have to propose addresses that will have the right to interact with their pool(s).
As implemented in the Atlendis protocol, any address can technically be allowed on the protocol. However, we expect only 2 types of accounts to be authorized:
- Multi signature wallets: borrowers can use a preexisting multisignature wallet contract, or create one dedicated to the pool. The Atlendis protocol does not favor a specific kind of smart contract wallet, as any authorized address, whatever the code it is using, can technically send a borrow or repay transaction. However, we plan on supporting Gnosis Safe natively on the frontend application, to allow for a positive user experience when interacting with the Atlendis protocol.
- Custom smart contract: the Atlendis protocol is very flexible, in that it allows loans to be taken automatically via smart contracts without any human intervention. As such, any smart contract can interact with the Atlendis protocol, if it suits the borrower's use case. With this feature, we expect to unlock new use cases that need instant liquidity without the need for collateral, for durations over a block.
We don't expect to authorize externally owned accounts (not smart contracts) to interact with the Atlendis protocol, for obvious security reasons.
Borrowers will need to send a proposal to authorize an address on their pool. The proposal will typically contain:
- The address to be authorized as well as the target pool.
- The nature of the address - a multisignature smart contract wallet or custom smart contract.
- The code of the custom smart contract if applicable.
- A presentation of the internal address management process - how the address will be used, who will have access, how security is handled internally, etc.
Note that since multiple addresses can be authorized on a certain pool, and actions can be seamlessly taken by different addresses, one request can contain multiple address authorizations.
Also note that if the request concerns a custom smart contract, a thorough review of the smart contract code will have to be held, as well as a testing phase on testnet.
Only after the request has been reviewed and discussed with the borrower, and the testing phase is done, governance will allow the address on the pool.
Last modified 1yr ago