Livepeer Token Purpose

Purpose of LPT

LPT is the native asset of the Livepeer protocol and serves three distinct functions:

Security collateral – Orchestrators must bond LPT to participate in the active set. The stake acts as collateral against misbehaviour and determines how much work an orchestrator can perform. Delegators bond LPT to orchestrators and share in rewards. Although slashing is currently disabled, the existence of a bondable token allows the network to enforce economic penalties in the future.
Reward distribution – New LPT minted through inflation is distributed proportionally to bonded stake. This makes LPT a “work token”: the more stake an orchestrator has, the more inflationary rewards it receives. Delegators share in these rewards based on the orchestrator’s configured rewardCut. Fees paid in ETH are also split according to bonded stake, aligning incentives across both revenue streams.
Governance power – Voting weight in Livepeer Improvement Proposals (LIPs) is proportional to bonded LPT. Tokenholders can propose protocol changes, vote on treasury allocations and direct network upgrades. Delegators indirectly influence governance by choosing orchestrators who represent their preferences.

Importantly, LPT is not used to pay for work. Broadcasters and AI builders pay in ETH or the underlying gas token, while orchestrators earn ETH fees. This separation avoids conflating supply‑demand dynamics (driven by video/AI workloads) with the security incentive (driven by LPT). It also allows Livepeer to leverage Ethereum’s gas market for payments while maintaining an independent security model.

Supply and inflation

LPT launched with a fixed genesis supply of 25.8 million tokens and continues to expand via dynamic inflation. Unlike Bitcoin’s deterministic halving schedule, Livepeer’s issuance adapts to network conditions. At the start of every round, the BondingManager mints new LPT, adds it to the total supply and distributes it to active orchestrators proportional to stake. The algorithm exposes multiple tunable parameters:

Initial distribution and lockups – At genesis, LPT was allocated to early investors, founders, community members and a protocol treasury. Many allocations vested over multiple years to align long‑term interests. The majority of circulating supply is now held by the community.
Adaptive inflation – The inflation rate responds to staking participation: if less than ~50 % of LPT is bonded, the rate increases; if more than ~50 % is bonded, the rate decreases. This feedback loop keeps the network secure by incentivising additional bonding when needed while reducing dilution when security is sufficient. Early on, inflation exceeded 13 % per year; as participation grew, the community voted to reduce baseline issuance to around 6–8 % and to direct a portion to the community treasury. The precise formula is inflation := inflation ± inflationChangeRate depending on whether the bonded ratio is above or below the target bonding rate (initially 50 %). InflationChangeRate determines how quickly the rate adjusts each round. This design prevents abrupt shocks while steering the network toward the target stake level.
Staking multiplier and round length – The protocol’s security depends not only on the percentage of LPT bonded but also on the work capacity per stake unit. As demand for video/AI throughput grows, governance can increase the number of active orchestrators (via numActiveTranscoders) to enlarge supply. Conversely, if demand shrinks, inflation continues to distribute rewards but orchestrator earnings decline, signalling to operators to scale down capacity.
Future adjustments – Governance retains the ability to modify inflation parameters via LIPs. For example, the community could implement halving schedules, redirect a greater share to the treasury or introduce new reward mechanisms. By encoding inflation in governance, Livepeer can adapt to changing network conditions. Beyond parameter tweaks, future proposals may explore token‑burning mechanisms (e.g., burning a portion of slashing penalties), veLPT locking (voting escrow models to weigh long‑term holders more heavily) or L2‑specific inflation (differentiating issuance on Arbitrum vs mainnet). Each change would require a thorough economic analysis and a governance vote.

Community Treasury

The protocol routes a share of inflation to an on‑chain community treasury. In its first iteration, 10 % of newly minted LPT flowed into a multisig controlled by the Livepeer Foundation and community stewards. The purpose of the treasury is to fund public goods, research, marketing initiatives and tooling that benefit the entire ecosystem. Examples include grants for improving monitoring infrastructure, research into verifiable transcoding and support for builders. When the treasury balance reached a pre‑defined cap, contributions paused; future LIPs can adjust the rate or resume funding. Treasury funds do not accrue automatically to orchestrators or delegators. Spending proposals must be approved by governance, ensuring transparency and accountability. Special‑purpose entities (SPEs) can request allocations to execute scoped projects (e.g., building a verification framework, developing new codecs) and must report back on milestones. This structure turns inflation into a community‑directed investment in the protocol’s long‑term health instead of pure dilution. To ensure that treasury spending aligns with protocol objectives, the Livepeer community has experimented with frameworks for public‑goods funding. 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. These experiments reflect a wider movement in decentralised governance toward more inclusive and accountable resource allocation.

Rewards distribution

There are two revenue streams in Livepeer:

ETH fees – When broadcasters or AI builders redeem winning tickets, ETH is transferred from their deposit to the orchestrator. The orchestrator shares a configurable percentage of these fees with its delegators (feeShare). High feeShare attracts delegators but reduces the orchestrator’s margin.
LPT inflation – In each round, the BondingManager calls reward() for every active orchestrator. The contract mints new LPT proportional to the orchestrator’s total stake (bonded LPT + delegations) and transfers it to the orchestrator. The orchestrator then splits the reward with delegators according to its rewardCut (percentage it keeps). Delegators call claimEarnings() to collect accumulated LPT and ETH.

Bonding is non-custodial: delegators’ LPT remains within the BondingManager. To withdraw, a delegator initiates an unbond and waits for the protocol-defined thawing period before withdrawal becomes available. This unbonding period prevents rapid stake flipping and provides time for slashing (when enabled) to be enforced. The configurability of rewardCut and feeShare creates a pricing market. Orchestrators must decide how much of the reward to retain versus share to attract delegators. Delegators, in turn, evaluate orchestrators based on uptime, transcoding quality, feeShare, rewardCut, and governance alignment. The resulting competition drives better service quality and decentralises power. Reward compounding and inflation capture Because inflation is distributed continuously, delegators benefit from regularly compounding their earnings by calling claimEarnings() or by bonding additional LPT. Failure to claim for many rounds does not forfeit rewards, but it can delay compounding and reduce effective yield due to dilution. Reward leakage and “fee switch” Historically Livepeer distributed inflationary rewards to orchestrators and their delegators, while ETH fee sharing was governed by each orchestrator’s configured fee split. Proposals to introduce a broader protocol-level fee switch would require a LIP and fresh economic analysis. The discussion remains part of the protocol’s design space, but delegator docs should treat any such change as governance-dependent rather than assumed current behaviour.

Start Here

Concepts

Delegating LPT

Guides

Resources

Purpose of LPT

Supply and inflation

Community Treasury

Rewards distribution

Start Here

Concepts

Delegating LPT

Guides

Resources

​Purpose of LPT

​Supply and inflation

​Community Treasury

​Rewards distribution

​

Purpose of LPT

Supply and inflation

Community Treasury

Rewards distribution