Skip to main content
This guide is for requesting funding from the community treasury — the protocol-owned pool funded by a cut of LPT inflation (LIP-92; contributions pause at a balance ceiling). It’s a specialized task: most stakeholders only ever vote, while proposals typically come from Special-Purpose Entities or teams taking on a defined scope of work. For the concepts behind all of this, see Governance & the treasury.
A treasury proposal is not a protocol LIP. It uses a different contract and different preparation — a budget and deliverable rather than a technical spec. Only the vote is shared with protocol governance. Mixing the two up is the most common mistake new proposers make.

Before you start

  • A concrete scope of work and an itemized budget.
  • A recipient address (usually an SPE or team multisig) to receive the LPT.
  • 100 LPT available to submit — it’s returned if the proposal passes.
  • A little ETH on Arbitrum One for gas.

Submit a proposal

1

Define the scope and budget

Write exactly what you’ll do, over what timeline, with what deliverable. Itemize the budget by category (engineering, research, infrastructure, communications). Proposals without a defensible, line-item budget rarely pass.
2

Post a Request for Feedback on the forum

Publish the proposal as an RFP in the LIPs category on the forum. This is where orchestrators and delegators ask questions, raise concerns, and negotiate scope. A proposal that hasn’t been workshopped here is unlikely to clear quorum.
3

Refine and finalize

Iterate on the feedback, then lock the scope, the recipient address, and the requested LPT amount. Post the final version with a clear “ready for on-chain submission” marker.
4

Submit on-chain to LivepeerGovernor

Anyone with 100 LPT can submit the proposal to the LivepeerGovernor contract. The text, recipient, and amount are committed on-chain at this step. Your 100 LPT is returned if the proposal passes.
5

Voting period

An on-chain voting window opens — 10 rounds (~9 days) as verified on-chain (see Protocol parameters for the current length). Stake-weighted voting decides the outcome under the standard 33% quorum and majority-of-votes-cast rules — bonded LPT, with delegator override. This is the same vote covered in Vote on a proposal.
6

Execution and reporting

On a successful vote, LivepeerGovernor releases the requested LPT to the recipient address — no protocol-code change. You’re then expected to deliver the scope and report progress publicly. Treasury funding is a relationship, not a one-time grant.

What makes a proposal pass

Clearing quorum takes more than favorable votes — passed proposals consistently show:
SignalWhat it looks like
Defensible budgetLine items, not lump sums; benchmarks where possible
Track recordPrior public delivery in Livepeer or an adjacent protocol
Concrete deliverablesWorking software, public research, measurable outputs — not “we’ll explore”
Ongoing reportingForum threads, dashboards, regular updates
Network alignmentStrengthens the protocol or network — not a single operator or vendor
Miss any one and a proposal tends to fail quorum even when the votes it does get are favorable.

Track it

Follow live proposals and treasury balances at explorer.livepeer.org/treasury.

Governance & the treasury

Why the treasury exists, what it funds, and how the two proposal tracks differ.

Submit a protocol LIP

The other track: changing protocol rules instead of requesting funds.

Vote on a proposal

The vote step — identical for treasury and protocol proposals.

Contract addresses

LivepeerGovernor and Treasury on Arbitrum One.

Protocol parameters

Live quorum, proposal threshold, and voting-window values.