During the first two stages of Livepeer’s Decentralized Governance Roadmap the community has a clear process to participate in to consider governance topics, present proposals, come to consensus, and vote to enact such proposals. However, until milestone three is reached, the Livepeer core developers will still be relied upon to carry out and execute the proposals that pass. Like much of Livepeer’s development, the governance process is iterative, and the core team executing the consensus of the community is another iterative step towards full decentralization. As this reliance on a group to execute the will of the community can be seen as risky centralization, this statement addresses the social contract that the core team intends to adhere to, the cases where the core team will not execute passing proposals, and the path forward to remove this failsafe.
The default behavior, and the social contract that the core team is committing to with the passage of LIP-19 (the vote that ratifies the initial governance process), is to execute passing proposals by default. This is the norm and the expectation. If the core team does not adhere to this, except in the case of the following exceptions, the community should hold them accountable as having broken the social contract. The exceptions in which the core team will not execute passed proposals include:
- Proposal passed due to clear abuse or misadherence to the ratified governance process itself.
- No technical implementation, or incomplete technical implementation.
- Executing the proposal would result in clear loss or theft of user funds.
The LIP process + polling application + social norms are just recently designed and soon-to-be ratified. If someone finds an exploit to show a passed proposal that clearly wasn’t visible to the community through the process, due to a bug in the tools or malicious loophole, this would be considered a non-executable proposal.
Looking to the future, binding, on chain voting would both require an implementation to be already deployed, so that a passed poll could automatically upgrade, hence we can set out with the same expectation for any protocol or parameter update proposal at this stage. If no implementation is complete, possible, or well tested, then a passing proposal doesn’t place responsibility on the core dev team to round out the implementation before execution. Instead, it is suggested that a non-binding opinion poll be run to get consensus on an idea before implementation. Only protocol updates with working and tested implementation will be executed.
As for the possible theft of user funds, this sort of thing would be extremely detrimental to the entire ecosystem in the case of a binding on chain voting system. Prior to the binding voting milestone, the ability to prevent these catastrophes from occurring while the community learns and iterates on the governance protocol, is an obvious benefit.
Finally, it is worth addressing when the core team will continue to use the protocol update ability in absence of the governance process. The core team will continue to do so for urgent bug fixes which put user value at risk or the liveness of the protocol at risk. Over the first two years of the protocol being live on mainnet, the team has successfully used this ability on three separate occasions to protect user value. Each time the protocol has resumed with a patch and within the current round to avoid any downtime. The community can use the ratified governance process to remove this ability from the core team, or alternatively, to elect a committee of keyholders which will have the ability to bug fix and safeguard user value.
Excepting the above noted exceptions, when proposals pass, with provided and tested implementations, the core team will move to carry them out with expedience.