-
Notifications
You must be signed in to change notification settings - Fork 16
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
Extensible Governance Contract: Initial Parameters #30
Comments
Let's use a term other than master for the primary actor. Either owner or primary would be candidates. Open to another suggestion as well. |
I think |
Note: The following is an editorial comment A draft LIP has been created containing updates to the original post. The contents of the draft LIP should be used as the basis for further discussion. |
What's the logic behind the 1.5x unbondingLockPeriod? Anyone has approximately 3.5 days to observe a pending change, initiate their exit, and then exit the system before the change goes into effect? |
Considering the reduction in complexity for LIP-25 as described in this comment #25 (comment) , I'm closing down this issue. The proposal remains the same for the value The value itself doesn't seem to be a contentious topic as long as stakeholders have sufficient time to exit, therefore I feel like any subsequent changes to this value can happen through the governance process itself. |
Abstract
LIP #25 lays out the design specification for an extensible governance system through which different 'actors' can govern the Livepeer protocol.
As [this section] in LIP #25 describes, there's two initial values that need to be set
DELAY
for the first actor, if applicableIt's established already that the first actor of this governance system will be the Livepeer Inc Multisig. Additional actors can be added over time through the Livepeer Governance process.
The
DELAY
is a bit different however. LIP25 describes a modular/role access control based system. The implementation details are still TBD, but this is not a blocker for the initial values discussion.Proposal
Livepeer Inc Multisig will retain the ability to pause/unpause the protocol on no delay.
Livepeer Inc Multisig will retain the ability to perform code upgrades on no delay.
Livepeer Inc will be able to execute access control or
DELAY
updates on a1.5 * unbondingLockPeriod
delayLivepeer Inc will be able to execute parameter updates on a
1.5 * unbondingLockPeriod
delayMotivation
First off, the reason for separating the discussions about design and initial values allows us to make progress on these issues in parallel.
Second, having Livepeer Inc retain the ability to fix bugs or perform upgrades until the protocol matures to allow for time sensitive fixes and/or protocol upgrades.
The text was updated successfully, but these errors were encountered: