Extensible Governance Contract: Initial Parameters

kyriediculous commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

yondonfu commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Considering the reduction in complexity for LIP-25 as described in this comment https://github.com/livepeer/LIPs/issues/25#issuecomment-647831655 , 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.

livepeer / LIPs