Skip to main content
Livepeer is a community-driven protocol, where token holders have the ability to vote on proposals to upgrade protocol mechanisms or to spend from the treasury. Voting is conducted on-chain via the Livepeer Governor contract, with the protocol contracts enforcing the outcome.
/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg
/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg

​
Governance

Livepeer is committed to open-source, transparent, community governance. It uses a hybrid on‑chain/off‑chain governance model that combines open community discussion with binding on‑chain votes. This model ensures that the community (token holders) collectively controls upgrades and spending, with the protocol enforcing the outcome.
Imagine a community garden run by people who own shares (tokens).
  • Proposing a Change: If someone has 100 share tokens, they can suggest a new rule (like “we should plant carrots”). They put 100 tokens in a safe place while the idea is considered.
  • Voting: Over the next month (30 days), everyone with tokens decides yes or no. If at least 33 out of every 100 token shares vote, and more than half vote “yes,” the idea becomes official. The 100 tokens go back to the proposer.
  • Delegating Votes: If you’ve given your shares to a friend to manage (delegation), you still get to vote because your votes travel with your shares.
Rules are set by token holders: stake some tokens to propose, everyone votes, and a rule only passes if enough people say yes.

​
Governance Functions

Governance in Livepeer serves two primary functions:
  • Protocol Upgrades: Proposals to upgrade the protocol.
  • Treasury Spending: Proposals to spend from the treasury.

​
Governance Process

Governance applies to both the protocol and the treasury. Protocol upgrades and parameter changes are formalized as LIPs. After community vetting, an on-chain vote is held. Stake-weighted voting ensures larger delegations have proportional say.

Idea Phase: Community Discussion

Proposals typically start with community discussion to gather feedback on the Livepeer Forum.

Draft Phase: Request For Feedback (RFP)

Community members post pre-proposals (requests for feedback) on the forum.

Proposal: Livepeer Improvement Proposal (LIP)

Once an idea is refined, an official proposal is drafted in the form of a
Livepeer Improvement Proposal (LIP)

Proposal Submission: On-Chain

Once a LIP is finalized, anyone with ≥100 LPT can submit it on-chain to the Governor contract for a vote. This stake is large by design to ensure only serious proposals advance and is returned if the proposal passes.

Proposal Voting: On-Chain

After submission, a voting period of 30 rounds (≈3.75 days) opens where eligible voters (Orchestrators and their delegated LPT) cast votes. Anyone with 1+ LPT staked can vote.
The on-chain proposals and votes can be found on Livepeer Explorer.

Proposal Voting: Details

Voting power is driven by LPT stake-weighted voting. If an orchestrator has X LPT staked (including delegated stake), that weight applies to its vote.
Note: Delegators can withdraw their delegation temporarily to vote separately if they disagree with their operator.

Proposal Voting: Quorum & Approval

A proposal passes only if at least 33% of total staked LPT participates (quorum) and >50% of the votes cast are “For”. These thresholds prevent minority-rule.

Proposal Execution: On-Chain

If a proposal passes, the Governor automatically executes the proposal’s instructions (changing a contract parameter or sending treasury funds).

​
Livepeer Improvement Proposals (LIPs)

Livepeer Improvement Proposals (LIPs) are formal design documents (hosted on GitHub) that describe protocol upgrades, similar to Ethereum’s EIPs. Impactful LIPs include:
  • Treasury Creation: LIP-89 and LIP-92 which established the Treasury and set the on-chain revenue allocation (sending 10% of new LPT emissions into the treasury).
  • Confluence - Arbitrum Migration: LIP-73 which completed the migration of the protocol from Ethereum to Arbitrum to reduce transaction costs and increase throughput.
  • Monetary Policy: LIP-34, LIP-35, LIP-40, LIP-83, and LIP-100 which have shaped the monetary policy of the protocol including inflation calculations, adjustment and bounds.
  • Governance Framework: LIP-15, LIP-16, LIP-19, LIP-25, LIP-69, LIP-19 and LIP-25 which established the current decentralised governance framework.
Key LIPs by Category:
Governance & Process:
  • LIP-1 established the initial on‑chain governance process (Process, Purpose and Guidelines)
  • LIP-15 established the polling system for LIP adoption.
  • LIP-69 established the stake-based polling system & implemented stake-weighted voting.
  • LIP-19 established the core governance mechanism (poll-based) for the Livepeer protocol.
  • LIP-25 established the technical foundation for protocol upgrades.
  • LIP-73: Confluence - Arbitrum One Migration (Final) - Complete L1→L2 migration LIP-73.md:1-256
  • LIP-74: L1 Minting and L2 Staking (Abandoned) - Alternative migration approach
  • LIP-89: Livepeer Treasury (Final) - Onchain treasury for public goods LIP-89.md:1-139
  • LIP-90: Funding Entity Conversations (Final)
  • LIP-91: Livepeer Treasury Bundle (Final)
  • LIP-92: Treasury Contribution Percentage (Final) - 10% of inflation to treasury LIP-92.md:1-150
Economic Parameters & Monetary Policy
  • LIP-34: InflationChange Parameter Update (Final) - Slowed inflation adjustment rate
  • LIP-35: inflationChange Calculation and Parameter Update (Final) - Bundle with LIP-40
  • LIP-40: Minter Math Precision (Final) - Enhanced precision for percentage calculations
  • LIP-83: roundLength Parameter Update (Final) - Adjusted for Ethereum Merge
  • LIP-100: Introduction of Inflation Bounds (Draft) - Added ceiling/floor to inflation
  • LIP-3: Ability To Update Registered Solver in LivepeerVerifier (Final)
  • LIP-8: Enable Partial Unbonding (Final)
  • LIP-9: Service Registry (Final) - Service endpoint discovery
  • LIP-11: Bond Event Details (Final)
  • LIP-36: Cumulative Earnings Claiming (Final) - O(1) gas cost for earnings claims
  • LIP-52: Snapshot For Claiming Earnings (Final) - Merkle tree for historical claims

​
On-Chain Contracts

The Livepeer protocol uses a custom Governor contract that inherits from OpenZeppelin’s Governor and GovernorSettings contracts. The key rules enforced are:
  • Voting period: 30 rounds (~3.75 days)
  • Quorum: 33% of all staked LPT
  • Threshold: Majority (>50%) of votes cast
  • Voting delay: 1 round

​
Key Roles & Stakeholders

On-Chain Treasury: A portion (10%) of token emissions flows to a community treasury (itself created by LIPs). This treasury exists to fund ecosystem-wide projects (public goods) for the benefit of the entire network. Livepeer’s social consensus is that treasury funds should primarily go to SPEs, which then deploy them to specific initiatives. Livepeer Foundation: The Foundation fosters long-term strategy and ecosystem coordination. It establishes advisory boards, publishes roadmaps, and coordinates the work of Special Purpose Entities (SPEs) to execute core development, research, on-chain proposals and long‑term vision. The foundation may also manage treasury disbursements, support grant programmes and maintain the network’s public goods. However, while the Foundation facilitates community participation, ultimate authority rests with the community via on-chain votes by LPT holders.

​
Visualising the Governance Process

This flowchart shows the governance process: community brainstorming leads to a LIP submission, which triggers an on-chain vote. A successful vote executes the change, while a rejected vote sends the proposal back for revision.

Governance Model

Read more about the technical details of the governance model.

Delegate LPT

Find out more about Delegating LPT.
Last modified on February 18, 2026