MVP Design and Assumptions
02/03/2022 — Technical Update - 1
In this technical update we will outline MVP (Minimal Viable Product) for ADADAO protocol and declare the assumptions for the MVP.
Definitions:
Debt Ceiling : The maximum loan which can be taken from the protocol by a single player.
Stability Fee: A fixed fee for using the protocol. It is not time dependent. Fee is levied only after 2 hours of use of the protocol to ensure arbitrage is encouraged.
Liquidation Ratio: This is the minimum CTL that a vault can have before it is liquidated. Any vault that has its CTL drop below the LR will be liquidated. A low Liquidation Ratio means Maker Governance expects low price volatility of the collateral; a high Liquidation Ratio means high volatility is expected.
Liquidation Penalty: The Liquidation Penalty is a fee added to a Vault’s total outstanding generated AUSD when a Liquidation occurs. The Liquidation Penalty is used to encourage Vault owners to keep appropriate collateral levels. If LP is 10%, then in case of liquidation, the outstanding loan value + 10% of this amount will be taken and the remaining assets will be returned to the vault owner.
Stability Pool: This is a pool of AUSD contributed by the community. Liquidations happening will get their liquidity from this pool. Contributors will earn through the liquidation penalty and they will also be earning ADAO rewards.
Collateral-to-loan Ratio (CTL): This is the ratio of the value of collaterals offered to the amount of AUSD loan taken.
Liquidation: When CTL falls below Liquidation ratio, the asset is liquidated. The protocol sells the collateral using the stability pool and burns the amount of outstanding AUSD loan, levies a penalty of 10% on the loan amount and distributes it to the stability pool and then returns the remaining assets to vault owner.
Undercollateralized vaults: Vaults which has CTL lower than LR.
Components of the MVP:
Borrowing Contract: It provides the ability for Borrowers to Open, Activate, Update, and Close Vaults.
Liquidation Contract: The Seizing contract provides an interface for seizing collateral from under-collateralized Vaults in the protocol.
Stability Pool Provider Contract: The Stability Providing contract provides an interface for Stability Providers to make deposits to the Stability Pool, receive receipts from the Stability Receipt component, and redeem those receipts for compounded stake and reward allocations.
Protocol Design: 1. User supplies ADA as collateral system generates AUSD as loan. AUSD loan taken from the protocol will always be in accordance with the liquidation ratio. The maximum loan taken from the protocol can be 66.66% of the value of collateral. (Minimum CTL of 135% will be allowed for creation of vault. Liquidation ratio will be 110%).
2. Maintain the collateral: The collateral value should be always higher than the liquidation ratio (CTL > LR). Liquidation ratio will be adjustable. If CTL falls below Liquidation Ratio, liquidation can be initiated.
3. Repay the loan: User will return the AUSD loan to the protocol, pay the stability fees and gets the collateral assets back.
Description of Stability Pool: This is a pool similar to a liquidity pool. It is a single currency pool. Anybody can add AUSD Stablecoin to the pool and be a part of it.
Use of this pool:
It ensures that the collaterals can always be liquidated without any external player involvement.
It absorbs the undercollateralized assets and makes sure that all AUSD in circulation is always collateralized.
MVP Assumptions:
- ➔ No Action Queues in MVP
- ➔ No global protocol modes in MVP (Active/Recovery/Emergency Shutdown)
- ➔ No oracle module (Exchange rate will be mocked)
- ➔ No rebalancing
- ➔ No governing Vaults
- ➔ Wallet for liquidation and other fees without rewards distribution
- ➔ MVP works only in simulation mode without testnet (with simulated wallets and simulated Tx signs)
- ➔ Current MVP implementation lets us work with contracts directly, i.e., we can call Borrower and Stability Pool contracts via terminal (curl, Postman) or Simulation
- ➔ Our Recalculation approach doesn't use epochs, we use receipt status instead. This approach looks inefficient and expensive (as it uses a lot of input UTXOs), but it lets us make sure that we do all the calculations the correct way (and it takes much less time for implementation), we assume that it's convenient for MVP and we can improve it as the next step after MVP.