-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deploy and wire-up eBTC Automation Infrastructure #14
Comments
Analysis on Automation PrioritizationFor the time being, the only foreseeable automations could be:
CDP and LP ManagementFor 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:
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 CollectorThis 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.
The text was updated successfully, but these errors were encountered: