Documentation Index
Fetch the complete documentation index at: https://docs.livepeer.org/llms.txt
Use this file to discover all available pages before exploring further.
Why on-chain governance
A protocol that secures money needs a way to change its own rules without breaking that security. Livepeer chose on-chain governance for three reasons. First, the participants who bear the risk of a change should have authority over the change. Bonded LPT is at stake against the protocol’s behaviour. The same stake is the unit of voting weight. Influence and exposure are the same number. Second, an on-chain vote produces a single canonical outcome. There is no separate execution layer, no foundation that signs the upgrade, and no off-chain consensus that participants might disagree about. The Governor contract executes whatever passes. Third, governance becomes legible. Every vote is on Arbitrum. Every proposal is in the LIPs repository. Every parameter change is traceable to a specific LIP and a specific block. There is no closed-door process to audit.What governance can change
The protocol scopes governance to two domains: the protocol itself, and the treasury. The protocol does not give governance authority over private operator behaviour, off-chain network coordination, or the day-to-day operation of orchestrators and gateways. Governance acts on the on-chain rules and on the treasury balance. Everything else is the network’s job.The Livepeer Improvement Proposal lifecycle
Every protocol or treasury change passes through the same staged process. Skipping a stage is not an option - the on-chain rules require it.How voting power is calculated
Voting power equals bonded LPT - including stake delegated to your orchestrator. If an orchestrator self-bonds 1,000 LPT and has 9,000 LPT delegated to it, the orchestrator’s vote carries 10,000 LPT of weight by default. The orchestrator votes on behalf of all 10,000 unless individual delegators override. This default has two consequences. First, orchestrators function as elected representatives of their delegators on every proposal. Choosing an orchestrator is partly a choice of governance proxy. Second, delegators retain final authority over their own stake. On any specific proposal, a delegator can override their orchestrator’s vote and have their delegated LPT counted separately. The override is per-proposal, not permanent. A delegator who overrides on one proposal returns to the default on the next.How to vote on a proposal
The flow is the same whether you are voting on a protocol LIP or a treasury proposal.Where to go next
Canonical reference: governance functions, key LIPs, on-chain contracts.
How treasury proposals differ, what gets funded, and how to submit one.
Active proposals, on-chain votes, and historical governance outcomes.
Every LIP, draft and final, with full specifications and discussion history.