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

Extensible Governance Contract: Initial Parameters #30

Closed
kyriediculous opened this issue Jun 9, 2020 · 5 comments
Closed

Extensible Governance Contract: Initial Parameters #30

kyriediculous opened this issue Jun 9, 2020 · 5 comments

Comments

@kyriediculous
Copy link
Contributor

kyriediculous commented Jun 9, 2020

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

  • The initial owner
  • The DELAY for the first actor, if applicable

It'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 a 1.5 * unbondingLockPeriod delay

  • Livepeer Inc will be able to execute parameter updates on a 1.5 * unbondingLockPeriod delay

Motivation

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.

@dob
Copy link
Member

dob commented Jun 9, 2020

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.

@kyriediculous
Copy link
Contributor Author

I think owner would be most accurate 👍 . I updated the OP.

@yondonfu
Copy link
Member

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.

@dob
Copy link
Member

dob commented Jun 11, 2020

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?

@kyriediculous
Copy link
Contributor Author

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 1.5x unbondingPeriod but can now be considered in scope for the LIP-25 discussion.

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.

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

No branches or pull requests

3 participants