Governance & the treasury

Staking LPT does more than earn rewards — it gives you a vote. Livepeer is governed on-chain by its bonded stakeholders: the same orchestrators and delegators who secure the network also decide how it changes. This page explains how that works and how the community treasury is funded and spent.

​

Who votes, and how

Governance authority derives entirely from bonded stake, so both supply-side roles participate:

• Orchestrators vote with their self-bonded stake and publicly signal their stance.
• Delegators vote directly with their own bonded stake. If you don’t cast a vote, the orchestrator you’re bonded to effectively votes on your behalf — which is why an operator’s governance positions are part of choosing one.

​

What governance can — and can’t — change

Governance operates at the protocol layer (on-chain). It sets the rules; it doesn’t run the network. Everything in the right column is the network layer — it happens off-chain, inside the rules the left column defines.

​

How a change happens: two proposal tracks

Governance has two proposal tracks — but they’re more alike than they first appear. Both run through the same on-chain lifecycle and the same vote; what actually differs is the preparation and the effect. Conflating the two is the most common mistake new proposers make. The shared lifecycle, conceptually:

1. Prepare — an idea is raised on the forum, then worked into either a drafted LIP or a budgeted RFP.
2. Submit on-chain — anyone with 100 LPT submits it; the stake is returned if it passes.
3. Vote — a stake-weighted, on-chain voting window opens, with bonded LPT as the weight.
4. Decide — it passes only with ≥33% quorum and >50% approval.
5. Execute — on success, the Governor contract applies the change automatically.

Doing either is a task, not a concept — see Submit a protocol LIP or Submit a treasury proposal.

​

The on-chain rules

A binding vote must clear two thresholds, both enforced by the contracts:

• Quorum — 33% of all bonded LPT must participate, or the vote is invalid. This stops a small group from pushing changes through on low turnout.
• Approval — >50% of participating votes must be in favor.

Clear both and the proposal enters a timelock before execution — a delay that gives stakeholders time to react to an approved change. The exact numbers behind this — proposal threshold, quorum, voting delay and period, and the timelock — are governance-controlled and can change. See Protocol parameters for the live values and the contracts that hold them.

​

The community treasury

The protocol can route a share of every round’s LPT inflation to an on-chain community treasury — LIP-92 set a 10% treasury reward cut, taken before orchestrators and delegators split the rest, with a balance ceiling that pauses contributions once the treasury is full. That ceiling has been reached: as of July 2026 the live cut rate reads 0% (paused), and governance can resume it — see Protocol parameters for the live value. Either way, the treasury itself remains funded and active: a protocol-owned pool for the public goods a pure market underprovides. What it funds: How it’s spent: a treasury proposal runs the same on-chain path as any other proposal — submit with 100 LPT, clear 33% quorum and >50% approval, execute automatically. What’s specific to the treasury is the preparation and the effect: instead of a technical spec, it’s a budget and a deliverable workshopped as a forum RFP; instead of a rule change, a passing vote releases treasury LPT to the recipient — no protocol-code change. The recipient is usually a Special-Purpose Entity: a community-chartered, funded working group that delivers a defined scope over time, draws its allocation against milestones, and reports back publicly. This is how one-time governance approval becomes ongoing execution — core protocol maintenance, research, real-time AI development, tooling. Track proposals and balances at explorer.livepeer.org/treasury.

​

Next