Livepeer Governance in a Nutshell

Currently, only Livepeer’s core team is essentially involved with changes to the Livepeer protocol. That’s about to change. Here’s a look at how decentralized governance will work.

At a Glance

Livepeer’s proposed governance process is simple and useful.

? Someone will propose a change
✍️ Then they’ll foster a discussion that leads to a formal proposal
?️ Finally they’ll launch a poll for token-holders to vote on the proposal

If this proposal passes in the poll, the core team will execute the proposed change. In my next article I’ll show exactly how this works using concrete examples.

Based upon recent developments, decentralized governance is set to begin with three things:

  1. Livepeer Improvement Proposals (LIPs)
    Used to propose changes, collect feedback, and document design decisions (similar to EIPs)
  2. An LIP polling application
    Used by token-holders to vote on LIPs
  3. Education
    Support for understanding governance, polls, and the LIP process

Related:

Livepeer Governance Roadmap Proposal (Mar 9, 2020)
LIP #15: LIP process polling related updates (Mar 23, 2020 – Github)
LIP #16: Polling system for LIPs (Mar 24, 2020 – Github)
Governing the World’s Open Video Infrastructure: Livepeer Case Study (Mar 24, 2020)

Coming soon: From an idea to an upgrade – The Lifecycle of an LIP


Three Governance Milestones

The Livepeer team is accelerating governance decentralization with three proposed milestones (and a glimpse at a fourth):

Milestone 1 – governance tools, processes and norms (ie. a process) for stakeholders to participate in upgrades performed manually by the Livepeer team

Milestone 2 – a governance contract to automate and restrict on-chain upgrades initiated by the Livepeer team

Milestone 3 – a binding voting system that takes control of the governance contract from the Livepeer team

Future (Milestone 4) – a policy for using the binding voting system to change itself

Milestone 1

In order to expand upgrade coordination beyond the Livepeer team in Milestone 1, stakeholders must be able to evaluate proposed changes to the Livepeer protocol. Yondon provided a deeper explanation here.

The plan is to initiate a more decentralized process for the Livepeer network’s changes with an increasing accountability to educated stakeholders who understand, express preference, and influence outcomes.

And that plan has already begun with two new proposals that will likely:

  1. introduce a new polling system and
  2. update the existing LIP process to include the new polling system.

Livepeer Improvement Proposals (LIPs)

The LIP process is used to propose new features, collect community input on an issue, and to document design decisions for the Livepeer protocol. This is a clear process for creating, discussing, and evaluating technical and economic proposals. Essentially any change to Livepeer should begin as an LIP. What’s an LIP?

A Livepeer Improvement Proposal is a design document that either:

  1. describes a new feature and/or the processes and environment used for developing it, or
  2. provides information to the Livepeer community.

An LIP should provide concise technical specifications and rationale for the proposed feature. Its author is responsible for 1) building consensus within the community and 2) documenting dissenting opinions. My next article will focus on an LIP from start to finish.

If you are considering a proposal for changes to Livepeer’s protocol, familiarize yourself with the pending changes to the LIP types, statuses, and the workflow process, as well as changes to the LIP template. We’re available in Discord and the forum to discuss. The primary reason for these changes is to formally legitimize a proposed polling application.

LIP Polling Application – Token-holder signalling for proposals

The polling application will be a way for token-holders to voice preference for LIPs as an initial step towards community participation in Livepeer’s protocol governance. A token-weighted, on-chain vote will help inform the Livepeer team’s decision to accept or reject the adoption of an LIP.

Though the poll will initially be considered non-binding, the core team should be socially accountable to the results of a poll that passes, with the exception of bugs or abuse of process. There may also be technical limitations that prevent the team from implementing/executing on poll results.

The specifications for the polling application are currently being discussed here. These are the design principles:

  • Simplicity – The top priority is to make participation easy to understand and accessible.
  • Auditable – A third party should be able to audit the results of a tally
  • Censorship resistance – A central entity should not be able to censor votes or results
  • Permissionless – Anyone should be able to create a poll with the same requirements

LPT token-holders would use this application to create polls and to vote on-chain. Subject to change, a successful poll will:

  • cost 100 LPT to create
  • have more than 33% of the LPT supply participate (ie. >33% quorum)
  • have more than 50% of participants vote ‘yes’ (ie. 50% threshold)

If these criteria are met within 10 rounds (~10 days), then the LIP will be considered by the poll to have passed.

However, these parameters and specifications are still being refined–join us on Github to discuss, or take the conversation to the forum and/or Discord. You can read more detailed rationale for the polling application here.

Education

The broader Livepeer community should be capable of evaluating and voting on the proposed technical and economic changes described by LIPs. According to Yondon, Livepeer’s core team is the centre of protocol knowledge creation, and that knowledge is not well dispersed across the community of stakeholders. In our on-going efforts to change this, the first milestone for decentralized governance will include a public education initiative:

  • An accessible education series explaining how the protocol governance process works in this first milestone
  • More idea-sharing & review-activity on the forum and Github research repository
  • A technical blog post series on how certain protocol features work
  • Core developer office hours to discuss protocol topics

This article is part of the Livepeer governance education initiative. We want an engaged and competent Livepeer community that participates in an increasingly decentralized governance process–all part of a healthy network that will support the Livepeer Project’s mission to Build The World’s Open Video Infrastructure.


Hopefully you found this useful. Questions? Comments? Feedback is always welcome! I’m on Twitter.