Skip to main content

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.

What the treasury is

The treasury is a single contract on Arbitrum One that holds LPT received from the Minter each round. It was created by LIP-89, bundled into the production parameter set by LIP-91, and given its 10%-of-inflation allocation by LIP-92. The treasury exists to solve a structural problem in protocol economies: the network needs ongoing development, research, and operational work, but the protocol cannot pay for these directly. Inflation is the only sustainable source of network-funded labour. Routing a fixed share into a community-controlled pool turns inflation into a public-goods budget that LPT holders allocate by vote.

How treasury funds reach builders

Most treasury funding does not flow directly to individual contributors. It flows through Special Purpose Entities (SPEs) that take responsibility for a defined area of work and report back to the community. An SPE is a community-approved organisation - typically with a multi-person team - chartered to deliver a specific scope of work over a defined period. The SPE proposes a budget on-chain through a treasury LIP. If the proposal passes, treasury LPT is released to the SPE address. The SPE delivers the scope, publishes updates, and either renews its mandate or hands off when the work is complete. This structure exists because most ecosystem work needs continuity - core protocol maintenance, research, real-time AI development, observability tooling - and the on-chain proposal process is too slow for grant-by-grant approval. SPEs translate one-time governance approval into ongoing execution.

How treasury proposals differ from protocol LIPs

The treasury and the core protocol use different governance contracts and slightly different rules. Mixing them up is the most common mistake new proposers make. The voting mechanics are identical. The execution path and the documentation expectations differ. A protocol LIP needs a contract spec and an implementation plan. A treasury proposal needs a budget, a deliverable, and a public commitment to report back.

How to submit a treasury proposal

The treasury proposal lifecycle mirrors the protocol LIP lifecycle for the on-chain stages, but the off-chain preparation is different.

What treasury credibility looks like

The treasury process favours proposals that are operationally serious. The pattern is consistent across passed proposals.
  • Defensible budget. Line items, not lump sums. Comparable benchmarks where possible.
  • Track record. A team or contributor with prior public delivery in the Livepeer ecosystem or in adjacent protocols.
  • Concrete deliverables. Working software, public research, measurable outputs - not “we will explore.”
  • Ongoing reporting. Forum threads, public dashboards, regular updates. Treasury funding is a relationship, not a transaction.
  • Network alignment. Work that strengthens the protocol or the network - not work that benefits a single operator or vendor.
Proposals that miss any one of these tend to fail to clear quorum even when individual votes are favourable. The treasury rewards rigour.

Where to go next

Canonical reference: full LIP catalogue, contract roles, and historical decisions.

How LIPs work end-to-end and how to use the vote that comes with bonded LPT.

Where every treasury proposal is workshopped before it reaches the chain.

Treasury LIPs (LIP-89, LIP-91, LIP-92, LIP-101) and the full proposal corpus.
Last modified on May 19, 2026