sajanrajdev
commented
4 months ago Analysis on Automation Prioritization
For the time being, the only foreseeable automations could be:
- A module for LP and CDP management
- A module for the fee recipient coll shares claiming
CDP and LP Management
For the first of the automations, as per discussions with BlockAnalitica, it doesn't seem to make much sense to pursue an automation at the early stages for the following reasons:
- The Treasury owned CDP will be created with a very high ICR (~200%) so it is highly unlikely for it to require automations for preventing liquidations on the get go. Price movements shouldn't be steep enough to bring the CDP into the liquidation threshold before it can be manually protected -> War room scripts should be prepared instead to allow for rapid intervention: Buy collateral if not in possession and deposit more, for instance.
- In the same way, the UniV3 LP ranges and capital distribution will be designed in such a way that they do not require much automation for their management.
- Protocol dynamics and parameter changes, trends on price vs ICR, enablement of redemptions and the introduction of larger players, will play a major role on defining any potential automation. Implementing an automation around CDP management and/or LP management during or before the bootstrapping phase may be counterproductive and not very efficient as it may require modifications soon after.
With this being said, close attention should be paid to the CDP and LP dynamics during the bootstrapping phase with the intention of automating these processes once these mature and enough learnings are collected from practice.
There will be a quick opportunity to replicate the existing UniV3 fee collector to the eBTC/wBTC positions. This is already developed and shouldn't require new development work.
Fee Collector
This is a low hanging and relatively easy to implement automation due to its simplicity and low risk (fee collection uses a hardcoded path). It will, nevertheless, take a while before it is justifiable from the economic stand point. It will take sometime before enough fees are collected in short periods of times such as that it is more cost effective to develop an automation than to gather 3 signers to claim the fees.
For this reason, this should be kept in the backlog and tackles as time permits.
In order to introduce better accounting separation and future operational independence, there's a case to be made for having parallel automation infrastructure in place for eBTC. In other words, a "UpKeepManager" should be deployed using eBTC' TechOps as owner in order to manage and maintain all automations related to eBTC. This infrastructure can (and should) be a fork of the already security reviewed and lindy Badger's UpKeepManager.