Executive Summary
A treasury proposal is a governance proposal whose executable payload authorizes an on-chain treasury action (typically a transfer, grant, or contract call). In Livepeer, treasury proposals are enforced at the protocol layer (on-chain): once quorum and thresholds are met and the timelock expires, the encoded actions execute deterministically. This page defines the structure of treasury proposal payloads, their execution semantics, and the primary failure modes.How to Submit a Proposal
Start with a Discussion
Post your idea on the Livepeer Forum in the Governance category. Gather community feedback before going on-chain.
Draft a LIP
Formalise as a Livepeer Improvement Proposal (LIP) in the livepeer/LIPs repository. Include motivation, technical specification, and economic impact.
Submit On-Chain
Use the Livepeer Explorer to submit the proposal on-chain. The encoded calldata determines what executes if the proposal passes.
Voting Period
Token holders vote during the designated window. Quorum: 33% of bonded LPT must participate. Threshold: >50% for votes must be in favour.
Timelock and Execution
Approved proposals enter a timelock period before automatic execution. Monitor status at explorer.livepeer.org/treasury.
1. Formal Definition
A treasury proposal is a tuple of executable actions: Each action is defined as: Where:- Target is the contract or address called
- Value is the native token amount attached (if any)
- Data is ABI-encoded calldata specifying the function selector and arguments
2. Governance Authorization
Let bonded stake variables:- = bonded stake of voter
- = total bonded stake
3. Timelock Queue Semantics
Once approved, the proposal is queued in a timelock for a delay . Timelock provides:- Predictable execution window
- Reaction time for stakeholders
- Mitigation against sudden or malicious changes
4. Execution Semantics
After timelock expiry, execution attempts to apply each action atomically within the execution transaction. Two important properties:- Determinism: execution is strictly defined by calldata
- Atomicity: if any action reverts, the transaction reverts unless the execution model explicitly tolerates partial failure
5. Treasury Transfer as Canonical Case
A common action is a treasury transfer. If treasury balance is and allocation amount is : Recipient balance increases by under the asset’s transfer semantics.6. Failure Modes
Treasury proposal execution can fail for multiple reasons.6.1 Calldata Error
Incorrect function selector or malformed ABI encoding causes revert.6.2 Insufficient Treasury Balance
Transfer amount exceeds treasury holdings.6.3 Target Contract Revert
The called contract rejects the call due to access controls, paused state, or parameter validation.6.4 Asset Transfer Semantics
Some token contracts may:- Return false instead of reverting
- Apply transfer fees
- Enforce allowlists
6.5 Timelock Configuration
If timelock delay or execution window conditions are misconfigured, proposals may become unexecutable.7. Risk Mitigation Checklist
Before submitting a treasury proposal:- Verify target addresses and contracts via registry
- Confirm ABI encoding is correct
- Confirm treasury balance is sufficient
- Simulate execution where possible
- Ensure calldata is auditable and minimally scoped
8. Proposal Execution Flow
9. Protocol vs Network Separation
Protocol (On-Chain):- Proposal payload definition
- Vote tally and authorization
- Timelock queue
- Deterministic execution
- Treasury transfers
- Drafting and review
- Grant delivery and operational execution by recipients