Governance and Economics

How decisions are made and how value flows through Livepeer.

Two control loops sit on top of one shared token. The governance loop turns staked LPT into binding decisions about protocol upgrades and treasury spending. The economics loop turns ETH from gateways into operator revenue and LPT inflation into rewards for the people securing the network. Both run on Arbitrum One smart contracts that any participant can audit, fork, or exit at any time.

This page explains both loops at conceptual depth. The deep technical pages on Token, Treasury, and Governance live in the Protocol section.

How decisions are made

Governance decides two things: which contract code runs the protocol, and how the on-chain treasury spends its LPT. Both are controlled by the same stake-weighted voting mechanism, run on a custom Governor contract derived from OpenZeppelin’s Compound-style governor pattern, and recorded permanently on Arbitrum One.

The pipeline is hybrid by design. Off-chain discussion on the Livepeer Forum lets ideas gather feedback before they cost anything; on-chain proposals lock that feedback into binding code. A proposal becomes a Livepeer Improvement Proposal (LIP), modelled on Ethereum’s EIP process, with a numbered specification, an author, and a status. Any holder with at least 100 LPT can submit one to the Governor. That stake is returned if the proposal passes and acts as a spam filter rather than a barrier.

Voting power is stake-weighted, not headcount-weighted. An orchestrator’s vote carries the weight of its self-bond plus the LPT delegated to it. Delegators who disagree with their orchestrator can detach their vote and cast it independently in the same proposal, which makes voting power follow capital rather than custody. The 33 percent quorum and the 50 percent threshold together rule out minority capture: a determined faction holding a third of the stake can block a proposal, but only a majority of participating stake can pass one.

Three controls keep governance rational: a 100 LPT proposal stake (anti-spam), a 33 percent quorum (anti-minority-rule), and a delegator override (anti-custody-capture).

The governance contract enforces the outcome automatically. There is no multisig step, no foundation veto, and no off-chain ratification. If a proposal passes the Governor’s checks, the change happens on the next round; if it fails, the stake is returned and the protocol is unchanged. This is the property a serious analyst would test for first: the system’s rules can only be changed by the same mechanism that runs the system.

The same Governor pattern handles treasury spending, on a separate Governor contract instance with the same parameters. A proposal to allocate funds passes or fails by the same 33/50 rule and the same execution flow. The only operational difference is that a passed treasury proposal triggers an LPT transfer rather than a contract parameter update.

The Livepeer Foundation and the Special Purpose Entities (SPEs) that surround it sit outside the on-chain process by design. The Foundation coordinates roadmap discussion, runs governance operations (often through GovWorks-style functions), and helps SPEs scope grant proposals before they reach the Governor. SPEs are the operational arms that actually deploy treasury capital into specific projects: protocol R&D, AI tooling, ecosystem grants, audits. None of them have unilateral authority. Every funding decision still passes through the on-chain vote.

For voting workflows, delegation mechanics, and how to participate as a delegator, see the Delegators tab. For the deep mechanics of the Governor contracts, parameter values, and historical LIPs, see .

How value flows

Two value flows run in parallel. They share participants and a token, but they answer different questions.

Flow 1: ETH for work

Buyers (gateways and the platforms behind them) pre-fund a deposit and a reserve in the TicketBroker contract. For every unit of work an orchestrator processes, the gateway issues a signed off-chain ticket with a face value and a small win probability. Most tickets do not win and never touch the chain. The few that do are redeemable on-chain by the orchestrator, who pulls the face value from the gateway’s reserve. The expected value matches the contracted price; the cost of settlement is roughly one percent of per-job on-chain settlement.

This is the probabilistic micropayment design. It is the load-bearing economic primitive that makes streaming-rate compute economics work on a public chain. Without it, the gas cost per job would dwarf the price of the job itself.

When an orchestrator redeems winning tickets, the ETH lands in its earnings pool. The orchestrator keeps its configured fee cut (typically published as the percentage it retains) and the remainder accrues to its delegators in proportion to their bonded stake. Delegators do not receive ETH automatically; they call claimEarnings to crystallise the accrued fees and rewards into withdrawable balance. The mechanic is identical to a dividend with reinvestment optionality.

Flow 2: LPT inflation as security budget

Each round (roughly one day on Arbitrum), the Minter issues new LPT proportional to the total bonded stake and the current inflation rate. The protocol uses dynamic inflation: when participation is below the target rate, inflation rises to attract more stake; when participation is above target, inflation falls. This is the same insight as Ethereum’s PoS issuance curve, applied to a work-token rather than a validator-token.

The freshly minted LPT splits three ways before any operator touches it.

The reward cut and fee cut parameters are the single most important configuration any orchestrator publishes. They are the orchestrator’s price for its services as a stake aggregator: a 5 percent reward cut keeps 5 percent of the inflation rewards flowing to the orchestrator’s address and sends 95 percent to delegators. Delegators read these numbers, compare them to performance history, and route their LPT accordingly. Capital follows the spread between commission and reliability, which is the price-discovery mechanism for the active set.

Why the dual-asset model

The choice to settle work in ETH and incentivise security in LPT is the most consequential design decision in the protocol’s economics, and it is worth naming explicitly.

This is the structural difference between Livepeer and a single-token DePIN where the same asset pays for work and secures the network. In a single-token system, the price of the service rises with the token and the security budget is contingent on speculation. In a dual-asset system, the cost of work is dollar-denominated through ETH, and the security budget compounds independently through LPT staking returns.

The token (LPT)

LPT is a work token. It does not entitle the holder to a share of fees by holding alone; it entitles the holder to perform or back work that earns fees. Three functions distinguish it from a generic governance token.

The supply curve is dynamic, not fixed. Inflation responds to the participation rate: more bonded supply means lower inflation, less bonded supply means higher inflation, with bounds set by LIP-100. The holder who does not stake is paying a continuous dilution cost to subsidise those who do, which is the protocol’s structural answer to free-riding. The economic effect is identical to a productive bond: yield exists and accrues to the participants who actually do the work of securing the network.

The LPT contract itself lives on Ethereum mainnet for historical and bridge reasons, while staking and protocol activity live on Arbitrum One since the Confluence migration (LIP-73). Operators bridge LPT to L2 to participate; the bridge architecture is documented in .

For full mechanics including bonding maths, claim flows, and slashing conditions, see .

The treasury

The Livepeer Treasury is an on-chain LPT pool, controlled by the same governance vote mechanism as the protocol, deployed at 0x363cdB9BaE210Ef182c60b5a496139E980330127 on Arbitrum One. It exists to fund public goods: work that benefits the entire network and that no individual operator has the incentive to fund alone.

Funding is automatic and continuous. LIP-92 routes 10 percent of each round’s newly minted LPT into the treasury before operator distribution, until the treasury balance reaches a ceiling of 750,000 LPT. The ceiling is itself governable: when reached, contributions pause and the community must vote to resume them, which forces a periodic re-evaluation of public goods funding rather than indefinite passive accumulation. Two secondary inflows feed the treasury continuously: 50 percent of any slashed LPT, and any remainder when gateway fee deposits expire unused.

Spending requires a passed LIP. The treasury cannot be drawn against by the Foundation, by orchestrators acting individually, or by any party other than the on-chain Governor, which only acts when a proposal clears the same 33 percent quorum and 50 percent majority that gates protocol changes. Disbursements typically fund SPEs that scope, deliver, and report on specific initiatives: protocol engineering, audits, AI infrastructure, documentation, ecosystem grants. Every transfer is visible on the treasury explorer and on Arbiscan as a TreasuryWithdrawal event.

The treasury is an on-chain endowment, not a foundation budget. The Foundation may shape proposals and oversee delivery, but only stakers can authorise spending.

For the Foundation’s role, the SPE structure, treasury governance details, and historical disbursement patterns, see .

What the design guarantees

A serious analyst evaluating Livepeer’s governance and economics ought to test five claims. The protocol answers each of them in code rather than in policy.

The design choices that make these answers stand up are well-trodden in protocol design literature, but the combination is specific. A Compound-style Governor with delegate override is from the DeFi governance lineage. A work-token paid in a separate medium of exchange is from the Stake Capital and Multicoin Capital “work token” thesis. A capped treasury that requires periodic re-authorisation is from public-finance theory rather than from prior protocols. Stack them, and the result is a system that runs on continuous community consent rather than on founder authority or foundation discretion.

The market test is whether participants behave as if these guarantees hold. Two signals are visible on-chain: the active set turnover (operators leaving and joining at the margin without governance disruption) and the treasury approval rate (proposals passing or failing through normal voting rather than through political capture). Both are monitorable on the Livepeer Explorer. The system is self-documenting in the sense that an external observer can verify its claims without trusting any participant.

Where to go deeper

Token and Economics

Bonding maths, reward and fee accounting, slashing conditions, and the full LPT contract architecture.

Governance and Treasury

Governor contract specification, LIP catalogue, treasury contract details, and the Foundation and SPE structure.

Protocol Mechanisms

Probabilistic micropayments, rounds, the active set, and the cryptoeconomic primitives behind the economics described here.

Delegators

How to delegate LPT, how to vote, how to evaluate orchestrators, and how to participate in governance as a token holder.

Livepeer Improvement Proposals

The full canonical record of every protocol change, including LIP-89 (treasury), LIP-92 (treasury funding), and LIP-73 (Arbitrum migration).

Live governance and treasury

Active proposals, vote results, treasury balance, and disbursement history on the Livepeer Explorer.