Skip to content
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

Open
sajanrajdev opened this issue Jan 10, 2024 · 1 comment
Open

Deploy and wire-up eBTC Automation Infrastructure #14

sajanrajdev opened this issue Jan 10, 2024 · 1 comment
Assignees

Comments

@sajanrajdev
Copy link
Collaborator

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.

@sajanrajdev sajanrajdev moved this to 💤 Backlog in eBTC Multisig Ops Jan 10, 2024
@sajanrajdev sajanrajdev self-assigned this Jan 23, 2024
@petrovska-petro petrovska-petro self-assigned this Jan 23, 2024
@sajanrajdev
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 💤 Backlog
Development

No branches or pull requests

2 participants