Livepeer Treasury

​

Genesis

• Creation & Governance:
  • LIP‑89 established the Treasury
  • It deployed a custom OpenZeppelin Governor (with a 100 LPT proposal threshold and stake-weighted voting)

• Funding:
  • LIP‑92 set the on-chain revenue allocation: sending 10% of new LPT emissions into the treasury.
• Usage:
  • LIP‑90 established that the treasury should fund public goods.
  • Approved proposals can allocate treasury assets to projects that benefit the Livepeer ecosystem.

​

Objectives

• Sustain ecosystem growth by funding core development, tools, integrations, and R&D
• Improve protocol security by supporting audits, incentive design, and bug bounties
• Decentralise governance via on-chain voting on funding proposals (LIPs)
• Enable long-term coordination beyond the scope of any single actor or company

​

Funding Sources

1. Protocol Inflation: 25% of newly minted LPT (inflationary rewards LPT) goes directly to the on-chain community treasury each round. (into a multisig controlled by the Livepeer Foundation and community stewards.)
2. Slashing Penalties: when orchestrators are slashed, 50% of the slashed LPT is burned and 50% is transferred to the treasury.
3. Fee Pool Remainders: if gateways/broadcasters deposit more ETH than is ultimately paid via winning tickets, the remainder is swept to the treasury.
4. Direct LIP Transfers: community or multisig entities can deposit LPT manually via LIP proposals.

​

Fund Usage

See LIP-73 and LIP-77 for examples

​

Governance

• Proposals: Stake 100 LPT to propose.
• Voting: Any staked tokens (orchestrators + delegators) can vote on the grant. Delegators normally let their operator vote on their behalf, but may detach to vote separately.
• Quorum/Threshold: Same as protocol: 33% of stake must participate, with a majority in favor.
• Execution: If passed, the Governor releases funds immediately. If failed, the stake is returned, and funds remain untouched.

​

Reporting & Transparency

• Livepeer Explorer: Track the treasury on-chain via the Livepeer Explorer – Treasury Page.
• Governance History on Arbiscan: All proposals, votes, and payments are public
• Disbursement Events in ABI
  Example Query (using ethers.js)

  Copy

  Ask AI

  const event = TreasuryContract.filters.TreasuryWithdrawal()
  provider.on(event, (log) => console.log(log.args))
  
• For historical examples, see the Forum threads on funding proposals or the explorer’s voting records.
• Follow milestone updates and reports on the Livepeer Forum.

​

Livepeer Foundation Role

• Governance Orchestration: Ensures treasury proposals move efficiently from idea to on-chain execution through structured processes and coordination.
• Accountability & Milestone Oversight: Maintains transparency and tracks deliverables so approved funds translate into measurable outcomes.
• Strategic Capital Framing: Helps define funding priorities and long-term allocation strategy aligned with network health.
• Execution Enablement: Aligns contributors and removes blockers so treasury-funded initiatives actually ship.
• Long-Term Network Health: Stewards treasury deployment to strengthen protocol security, decentralization, and ecosystem growth.

​

Contract Architecture

• Contract Name: Treasury
• Deployment: Arbitrum One

• Holds LPT funds
• Accepts authorized distribute() calls from governance
• Emits TreasuryWithdrawal events on approved spend

​

Improvement Discussions

• One example is the transparent milestone‑based grant model: proposers submit budgets and deliverables, funds are released in tranches upon completion and progress is publicly reported on the forum.
• Another is quadratic funding, which could match community donations from the treasury to signal strong grassroots support. Discussions have also explored regen network‑style retroactive funding, where contributions are rewarded after impact is demonstrated.

​

Further Resources