Passer au contenu principal
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

Gouvernance

Livepeer s’engage à une gouvernance open-source, transparente et communautaire. Il utilise un modèle hybride de gouvernance on‑chain/off‑chain qui combine discussion communautaire ouverte avec des votes on‑chain contraignants. Ce modèle garantit que la communauté (détenants de jetons) contrôle collectivement les mises à jour et les dépenses, le protocole appliquant le résultat.
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.

Fonctions de gouvernance

La gouvernance dans Livepeer sert deux fonctions principales :
  • Mises à jour du protocole: Propositions pour mettre à jour le protocole.
  • Dépenses du trésor: Propositions pour dépenser du trésor.

Processus de gouvernance

La gouvernance s’applique à la fois au protocole et au trésor. Les mises à jour du protocole et les changements de paramètres sont formalisés sous forme de LIPs. Après vérification communautaire, un vote on‑chain est organisé. Le vote pondéré par la participation garantit que les délégations plus importantes ont une voix proportionnelle.

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 Propositions d’amélioration (LIPs)

Livepeer Propositions d’amélioration (LIPs) sont des documents de conception formels (hébergé sur GitHub) qui décrivent les mises à niveau du protocole, similaires à celles d’EthereumEIPs. Les LIPs les plus impactants incluent :
  • Création du Trésor: LIP-89 et LIP-92 qui a établi le Trésor et définir l’allocation des revenus on-chain (en envoyant 10% des nouvelles émissions de LPT dans le trésor).
  • Confluence - Migration Arbitrum: LIP-73 qui a complété la migration du protocole d’Ethereum vers Arbitrum afin de réduire les coûts de transaction et d’augmenter le débit.
  • Politique monétaire: LIP-34, LIP-35, LIP-40, LIP-83, et LIP-100 qui ont façonné la politique monétaire du protocole, y compris les calculs d’inflation, les ajustements et les limites.
  • Cadre de gouvernance: LIP-15, LIP-16, LIP-19, LIP-25, LIP-69, LIP-19 et LIP-25 qui a établi le cadre de gouvernance décentralisé actuel.
LIPs clés par catégorie :
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

Contrats On-Chain

Le protocole Livepeer utilise un contrat Governor personnalisé qui hérite de celui d’OpenZeppelin Governor et GovernorSettings contrats. Les règles clés appliquées sont :
  • Période de vote: 30 tours (~3,75 jours)
  • Quorum: 33 % de tous les LPT mis en jeu
  • Seuil: Majorité (>50 %) des votes exprimés
  • Délai de vote: 1 tour

Rôles clés & parties prenantes

Trésorerie en chaîne: Une partie (10 %) des émissions de jetons est versée dans une trésorerie communautaire (créée elle‑même par les LIPs). Cette trésorerie existe pour financer des projets à l’échelle de l’écosystème (biens publics) au bénéfice de l’ensemble du réseau. Le consensus social de Livepeer est que les fonds de la trésorerie doivent principalement être alloués à SPEs, qui les déploient ensuite vers des initiatives spécifiques. Livepeer Fondation: La Fondation favorise la stratégie à long terme et la coordination de l’écosystème. Elle établit des conseils consultatifs, publie des feuilles de route et coordonne le travail de Entités à usage spécial (SPEs) pour exécuter le développement de base, la recherche, les propositions en chaîne et la vision à long terme. La Fondation peut également gérer les décaissements de trésorerie, soutenir les programmes de subventions et maintenir les biens publics du réseau. Cependant, alors que la Fondation facilite la participation communautaire, l’autorité ultime repose sur la communauté via les votes en chaîne des détenteurs de LPT.

Visualiser le processus de gouvernance

Ce diagramme montre le processus de gouvernance : le brainstorming communautaire conduit à une soumission de LIP, qui déclenche un vote sur la chaîne. Un vote réussi exécute le changement, tandis qu’un vote rejeté renvoie la proposition pour révision.

Ressources connexes

Last modified on March 1, 2026