The Livepeer protocol secures a decentralised marketplace for video and AI compute through a tightly coupled set of smart contracts on Arbitrum One. These contracts encode five mechanisms that together turn LPT into work, ETH into operator revenue, and stake into a security guarantee. This page explains each mechanism, names the contract that implements it, and surfaces the one architectural choice that catches most readers off guard: video and AI pipelines have the same network footprint but a different relationship with the protocol.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 mechanisms do
Each mechanism exists to solve a specific coordination problem. Naming the problem first makes the design legible. The four economic mechanisms (rounds, staking, rewards, payments) coordinate how operators are selected, paid, and held accountable. The fifth (upgradeability) makes the first four governable. For the contracts behind each mechanism, see .Video and AI take different paths
The single most important architectural fact about the protocol is that video transcoding and AI inference share the same network and the same payment rail, but they do not share the same incentive layer. Reading the rest of this page without that distinction leads to wrong conclusions. Video Orchestrators stake LPT, compete for the active set, callreward() to mint inflationary LPT, and distribute earnings to delegators. AI services are a directory of capability endpoints. They use the same Gateway-to-Orchestrator routing and the same TicketBroker payment flow, but they do not participate in the staking pool, the active set, or the inflation rewards. This is by design: the AI subnet was launched without imposing the staking gate, so that AI capacity could grow on the network’s economic merit before being absorbed into the full economic security model.
The settlement asset (ETH via probabilistic tickets) and the orchestrator software are common to both pipelines. The staking, active set election, and inflation rewards are video-only.
The asymmetry is intentional. Forcing AI orchestrators to acquire and stake LPT before serving inference would have throttled the supply side of a market that did not yet have demand-side product-market fit. Once AI demand stabilises, the question of whether and how to bring AI services under the same staking model is itself a governance question and would be settled by a future LIP.
Mechanism details
Each mechanism is described in three layers: what it coordinates, the contract functions that implement it, and the parameters operators or developers most commonly interact with.How the mechanisms compose
The five mechanisms are not independent. A change to any one of them ripples through the others, which is why governance proposals tend to specify second-order effects explicitly. The composition is the point. A unified set of parameters running in lockstep across rounds is what allows operators across jurisdictions, infrastructure stacks, and capital sizes to participate in the same market on the same terms.Related pages
Protocol Design
Why the protocol exists, the actors it coordinates, and the design choices behind the mechanisms on this page.
Blockchain Contracts
Every contract referenced here, with addresses, function signatures, and source.
Governance and Treasury
LIP lifecycle, Governor specification, and the treasury that the reward mechanism funds.
Token and Economics
LPT supply, bonding maths, and the dual-asset economics that connect the mechanisms above to value flow.
Network Architecture
How orchestrator and gateway nodes implement these mechanisms off-chain.
LIPs Repository
Every parameter on this page is set by a passed LIP. The repository is the canonical record.