Skip to main content
Page is under construction.

Check the github issues for ways to contribute! Or provide your feedback in this quick form
/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg
/snippets/assets/logos/Livepeer-Logo-Symbol-Theme.svg

Mechanism Objectives

Livepeer’s core mechanisms are designed to:
  • Incentivise honest behavior among participants (Orchestrators, Delegators, Gateways/Broadcasters)
  • Scale supply capacity by rewarding infrastructure providers proportionally
  • Secure verification of off-chain video and AI workloads through bonded stake
  • Disincentivise dishonest actors via penalties (slashing)

Protocol Features

Core features of the Livepeer Protocol include:

Blockchain Base

All protocol state (bonds, delegations, votes, job payments, etc.) lives on Arbitrum. The LPT token is ERC-20-based and bridged between L1 and L2.The Arbitrum rollup finalizes via Ethereum; thus the underlying security is Ethereum’s.After Confluence (LIP-73), Ethereum mainnet now mainly serves as a historical source – new stake/votes are on Arbitrum only.

Consensus & Finality

Livepeer does not use its own consensus; it relies on Arbitrum’s optimistic rollup. Blocks (called rounds) occur roughly every 24 hrs, and after a ~7-day challenge window the state is finalized on Ethereum.This means trust assumptions are similar to other Ethereum Layer-2s: Arbitrum’s rollup validators and Ethereum miners secure the chain; fraud proofs protect against invalid blocks.

Security Model

Livepeer’s core contracts are on an Ethereum Layer-2 (Arbitrum One), which inherits Ethereum-level security via optimistic rollup.LPT stakers (orchestrators and delegators) provide economic collateral against misbehavior. Protocol rules penalize malfeasance by slashing stake (e.g. losing part or all delegated tokens).Off-chain video verification and optional arbitration ensure correct transcoding.

Node-Level Trust

Gateways/Broadcasters (clients) and orchestrators exchange signed data (video segments, “tickets,” job outcomes).These off-chain interactions can be audited (via perceptual hashes or full verification), so a bad actor’s forged data can be proven on-chain by a dispute mechanism.Orchestrators commit to jobs by staking, and any detected mis-transcoding can trigger an on-chain slashing penalty.

Protocol Actors

The Livepeer Protocol defines several key actors that participate in the network and perform specific functions.
OrchestratorsOrchestrators are the main participants in the Livepeer Protocol. They are responsible for processing video and AI jobs, earning fees and rewards, and maintaining the network’s security and decentralization.
GatewaysGateways are the entry point for applications into the Livepeer network. They are the coordination layer that connects real-time AI and video workloads to the orchestrators who perform the GPU compute.
DelegatorsDelegators are LPT holders who delegate their tokens to an orchestrator of their choice. They share in the rewards and fees earned by the orchestrator, and also share in any slashing penalties.

Protocol Mechanisms

Livepeer relies on Gateways (prev. Broadcasters), Orchestrators and Delegators to process compute loads on the network. The Livepeer Protocol defines several key operational rules for the network and network actors. AI vs Video Mechanisms AI services do not participate in the same reward distribution or round-based active set election as video Orchestrators
The video transcoding system and AI system are architecturally separate and operate independently.
This separation allows AI services to operate without requiring LPT staking, making them more accessible while preserving the security model of video transcoding through economic bonding. Incentive Structure Comparison
ComponentVideo OrchestratorsAI Services

Mechanism Details

Note that Staking, Rewards and Payments operate differently for AI pipelines

Rounds and Timing

The Livepeer protocol uses a round-based system, where each round represents a fixed-length epoch in blocks, to coordinate reward distribution and staking activities.Mechanism
  1. Rounds have a fixed length in blocks (configured in RoundsManager)
  2. New rounds must be initialized by calling initializeRound()
  3. Various protocol operations are only valid during specific times in a round
  4. Parameter updates are restricted during “locked” periods of a round
  5. Rewards can only be claimed once per round by a transcoder
FunctionsThe round system coordinates the protocol operations for:
  • Staking/Unbonding: Changes take effect in the next round
  • Reward Distribution: Calculated per round based on active stake
  • Parameter Updates: Restricted during lock periods
  • Earnings Claiming: Can only claim for rounds that have been initialised
Implementation MechanicsThis mechanism is implemented in the RoundsManager contract, which manages round lifecycle, including length configuration, initialisation tracking and locking periods that gate protocol operations.
  • roundLength state variable stores the number of blocks per round.
  • default configuration is 5760 blocks for mainnet deployments (~24 hours at 15-second block times)
  • development environment default is 50 blocks for faster testing
  • updated via setRoundLength() (governed by Controller owner)
  • roundLength state variable stores the number of blocks per round.
  • default configuration is 5760 blocks for mainnet deployments and 50 blocks for development environments
  • updated via setRoundLength() (governed by Controller owner)
Round Initialisation
function: initializeRound()
  • public function that can be called externally by any EOA to mark the start of a new round. Typically triggered by Orchestrators
  • advances the protocol epoch by updating current round number and round initialisation status
  • performs critical setup: stores block hash, sets active stake, snapshots stake for reward calculations and unlocks mintable rewards.
  • can only be called once per round and reverts if system is paused or round is not complete
Last modified on February 18, 2026