How the Livepeer Protocol Functions

A walk-through of how the Livepeer Protocol functions and the design decisions behind each mechanism - delegated proof-of-stake, probabilistic micropayments, on-chain governance, and the protocol-network boundary.

What the protocol is responsible for

The protocol does four things, and only four things. Understanding the boundary is the first step in understanding the design.

The protocol does not transcode video. It does not run AI inference. It does not select which orchestrator handles a given job. Those are the Network’s responsibilities. The protocol’s role is to make those activities legible, payable, and accountable.

Five foundational design decisions

Each mechanism in the protocol resolves a specific tension. The decisions below are the ones that shape every downstream behaviour.

1. Delegated proof-of-stake, not proof-of-work

The protocol needed a way to admit a permissionless pool of GPU operators while still putting economic security behind their behaviour. Proof-of-work would have priced out small operators and added energy overhead with no security benefit for media work. A non-delegated stake model would have concentrated participation among capital holders who do not run hardware.

Delegated proof-of-stake separates the two roles. Orchestrators bring hardware and operational expertise. Delegators bring stake. Both share in rewards, both share in slashing risk, and both have a vote. The active set is sorted by total bonded stake, which couples capital weight to selection probability without requiring delegators to operate nodes.

2. Off-chain execution with on-chain anchoring

A fully on-chain protocol would have to settle every video segment and every inference call as a transaction. At production volume that is impossible. A fully off-chain protocol would lose the ability to enforce honesty without a trusted intermediary.

Livepeer’s protocol resolves this by encoding only the rules and the settlement points on-chain. Orchestrator selection, capability discovery, and per-segment delivery happen off-chain across the Network. The chain holds the active set, the bonded stake, the round timer, and the payment infrastructure. Off-chain participants compete on a stable, agreed-upon view of who is eligible to do work and who has been paid for it.

3. Probabilistic micropayments over per-job billing

Per-job on-chain billing would consume more gas than the work itself for sub-cent video segments. Off-chain accumulation with periodic settlement would create credit risk between gateways and orchestrators.

The TicketBroker contract implements probabilistic micropayments: gateways issue off-chain tickets to orchestrators with each job, only a small fraction of which are winning tickets that settle on-chain. Expected value matches the work performed. Gas cost amortises across thousands of jobs. The settlement guarantee remains as strong as a direct on-chain transfer because every ticket is cryptographically committed and either redeemable or losing - never disputed.

4. On-chain governance, not foundation control

A foundation-led model would have moved faster but concentrated control. A purely off-chain governance model would have let participants disagree about which version of the rules was canonical.

Livepeer encoded governance directly into the protocol. Any LPT holder with at least 100 LPT can submit a Livepeer Improvement Proposal (LIP) on-chain. Voting is stake-weighted across all bonded LPT, with delegators voting through their orchestrator by default and able to override on any specific proposal. A proposal passes only if at least 33% of bonded stake participates and a majority of cast votes are in favour. Approved proposals execute through the Governor contract without a separate execution layer.

5. Arbitrum One, not Ethereum mainnet

The protocol originally deployed on Ethereum mainnet. As gas costs rose, the per-round work of inflation accounting, ticket redemption, and round progression became a structural drag on participation - particularly for smaller orchestrators and for high-volume gateway settlement.

The Confluence upgrade (LIP-73) migrated the active protocol to Arbitrum One while keeping the LPT token contract on Ethereum, with paired LPTGateway contracts handling the bridge. Arbitrum gives the protocol low fees and Ethereum-anchored security in a single move, and removes gas-cost as a barrier to running an orchestrator or operating a gateway.

Where each decision lives in the contracts

The five decisions above map to specific contracts. Reading the code alongside the design notes is the most direct route to understanding the protocol.

What the protocol intentionally does not do

A surprising amount of design discipline is in what the protocol leaves out.

• It does not pick orchestrators for a job. Gateways do, off-chain, using the active set as a starting point and applying their own price, latency, and reliability criteria.
• It does not verify transcoding output. The slashing function exists in the BondingManager, but the Verifier role is currently set to the null address, leaving slashing inoperative until governance reactivates it. Verification is presently economic: stake at risk, plus reputation-driven gateway selection.
• It does not coordinate AI inference work. AI workloads use the same actor roles and economic primitives, but their job dispatch and capability advertisement happen entirely off-chain.
• It does not store media. All video and inference data flows directly between gateway and orchestrator. The chain holds only the right to be paid and the obligation to behave honestly.

Each omission is deliberate. The protocol is the smallest set of rules that makes the marketplace possible. The Network does the work.

Where to go next

The canonical reference: protocol purpose, design, and implementation.

Rounds, staking, rewards, payments, upgrades - each protocol primitive in detail.

Where the protocol’s rules end and the off-chain marketplace begins.

Every contract, every function. BondingManager, TicketBroker, Minter, and the rest.