Skip to main content
Page is under construction.

Check the github issues for ways to contribute! Or provide your feedback in this quick form

​
Livepeer Blockchain Contracts

Livepeer uses a comprehensive system of Ethereum smart contracts to permissionlessly govern its decentralized network. The Livepeer Protocol is currently deployed on Arbitrum One and uses a collection of Ethereum smart contracts to govern:
  • LivepeerToken (LPT) ownership and delegation
  • Staking and selection of active transcoder operators (orchestrators)
  • Distribution of inflationary rewards and fees to participants
  • Time-based progression of the protocol through rounds
  • Payment processing through a probabilistic micropayment system
There are 3 core functions of contracts in the Livepeer Protocol:
  1. Core Protocol Contracts
  2. Token System
  3. Governance
That consist of 10 smart contracts that work together to manage staking, payments, governance, and service discovery:

​
Contract Interaction Architecture

Here’s how these contracts interact with each other:
FIX THIS DIAGRAM - unreadable

​
Core Protocol Contracts

The core protocol contracts are the backbone of the Livepeer Protocol. They manage the staking, delegation, and reward distribution for orchestrators. They also manage the time-based progression of the protocol through rounds and the payment processing through a probabilistic micropayment system. The Controller serves as the central registry, enabling upgrades by updating implementation addresses
Maybe put in tab view for better layout

​
Controller: Contract Registry

The Controller is the central registry for all protocol contracts. All protocol contracts check with the Controller for the addresses of other contracts they need to interact with.
The Controller acts as the central registry for all other contract addresses in the protocol.It maintains a mapping of contract IDs to their addresses, enabling protocol upgrades by updating the registered implementation addresses. It uses Keccak256 hashes of contract names as keys to store their addresses, enabling upgradeable architecture without changing the Controller address itself.Address:See on Arbiscan
0xD8E8328501E9645d16Cf49539efC04f734606ee4
Purpose:
  • Central address registry for all protocol contracts
  • Enables contract upgrades while maintaining a stable entry point
  • Provides pause functionality for emergency situations
Key Operations:
  • getContract() - Get address of a contract by name
  • setContract() - Set address of a contract by name
  • pause()/unpause() - Emergency pause for critical situations
Controller

​
BondingManager: Staking & Delegation

The BondingManager is the most critical contract managing the staking economy, orchestrator registration, and reward distribution.
Address:See on Arbiscan
0x0000000000000000000000000000000000000000
Purpose:
  • Manages the transcoder (orchestrator) pool as a sorted linked list
  • Handles bonding (staking) and delegation to orchestrators
  • Distributes inflationary rewards and fees
  • Manages unbonding periods and withdrawals
  • Tracks earnings and claims
Key Operations:
  • Bond() - Delegate stake to an orchestrator
  • Transcoder() - Register as an orchestrator with reward/fee parameters
  • Unbond() - Start withdrawal process (with lock period)
  • Reward() - Called by orchestrators to mint inflationary rewards
  • ClaimEarnings() - Claim accumulated rewards and fees

​
TicketBroker: Probabilistic Micropayments

The TicketBroker manages the off-chain payment system using probabilistic micropayments for broadcaster-to-orchestrator payments.
Purpose:
  • Holds broadcaster deposits and reserves for micropayments
  • Validates and settles winning payment tickets
  • Manages unlock/withdrawal periods for broadcasters
  • Tracks claimed reserves per orchestrator
Key Operations:
  • FundDepositAndReserve() - Broadcaster deposits funds for payments
  • RedeemWinningTicket() - Orchestrator redeems a winning ticket
  • Unlock() - Start withdrawal process
  • Withdraw() - Complete withdrawal after unlock period

​
RoundsManager: Protocol Time Management

The RoundsManager manages the protocol’s time-based round system where each round has a fixed block length.
Purpose:
  • Defines protocol rounds (epochs) of fixed block length
  • Tracks round initialization and locking
  • Provides block hashes for ticket validation
  • Coordinates time-based protocol operations
Key Operations:
  • InitializeRound() - Initialize new round
  • CurrentRound() - Get current round number
  • BlockHashForRound() - Get L1 block hash for ticket validation

​
Minter: Token Inflation

The Minter controls the token supply inflation that rewards active orchestrators.
Purpose:
  • Manages LPT token inflation schedule
  • Calculates mintable tokens per round
  • Adjusts inflation based on target bonding rate
  • Called by BondingManager during reward distribution
Key Operations:
  • CurrentMintableTokens() - Calculate tokens to mint for rewards
  • Inflation(), InflationChange() - Query inflation parameters

​
ServiceRegistry: Orchestrator Discovery

The ServiceRegistry maps Ethereum addresses to service URIs for orchestrator discovery.
Purpose:
  • Allows orchestrators to advertise their network endpoints
  • Enables broadcasters to discover and connect to orchestrators
  • Stores URI strings on-chain
Key Operations:
  • SetServiceURI() - Orchestrator registers their endpoint
  • GetServiceURI() - Query orchestrator’s service URL

​
MerkleSnapshot

MerkleSnapshot creates a snapshot of the staking pool at a given round and generates a merkle root for verifiable delegation.
Purpose:
  • Creates a snapshot of the staking pool at a given round
  • Generates a merkle root for verifiable delegation
  • Used for delegator rewards and governance
Key Operations:
  • CreateSnapshot() - Create snapshot at current round
  • MerkleRoot() - Get merkle root for a round

​
Token & Utility Contracts

Livepeer moved from the Ethereum mainnet to the Arbitrum One network in 2022 to increase transaction throughput and reduce fees.
On Ethereum mainnet, only the LivepeerToken and BridgeMinter contracts remain operational; all other contracts have migrated to Arbitrum One.This ensures the token has the higher security of the Ethereum mainnet while the network enjoys the higher throughput and lower fees of Arbitrum.

​
LivepeerToken (LPT): ERC20 Token

Ethereum Mainnet Only The LivepeerToken is the native protocol token used for staking, payments, and governance based on the ERC-20 standard.
Purpose:
  • ERC20 token for all economic activity in the network
  • Used for bonding/staking to orchestrators
  • Required for broadcaster deposits and payments
  • Governance voting weight
Key Operations:
  • Transfer(), BalanceOf(), TotalSupply() - Standard ERC20 operations
  • Approve() - Required before bonding or funding deposits

​
BridgeMinter: Token Bridge

Ethereum Mainnet Only The BridgeMinter is a minting contract that mints LPT tokens on the Arbitrum One network when it receives a valid deposit from the Ethereum mainnet.
Purpose:
  • Mints LPT tokens on Arbitrum One when it receives a valid deposit from the Ethereum mainnet

​
LivepeerTokenFaucet: Test Token Distribution

Testnets Only The LivepeerTokenFaucet is used on testnets for distributing test LPT tokens.
Purpose:
  • Provides test tokens on testnets
  • Rate-limited token requests
  • Development and testing support

​
Governance Contracts

​
Governor: Contract Upgrades

Governor handles protocol upgrades through a multi-step transaction proposal and execution process.
Purpose:
  • Handles protocol upgrades through a multi-step transaction proposal and execution process
Key Operations:
  • Propose() - Submit a new proposal
  • Queue() - Queue a proposal for execution
  • Execute() - Execute a queued proposal

​
LivepeerGovernor: Protocol Governance

The LivepeerGovernor implements on-chain governance for protocol upgrades and parameter changes.
Purpose:
  • On-chain voting on protocol proposals
  • Weighted by bonded stake
  • Implements governance mechanisms
Key Operations:
  • CastVote() - Vote on governance proposals
  • CastVoteWithReason() - Vote with explanation

​
Treasury: On-chain Treasury Management

Treasury manages the on-chain treasury for funding and accounting.
Purpose:
  • Manages protocol treasury for funding
  • Tracks allocations and expenditures
  • Funds Special Purpose Entities (SPEs)
Key Operations:
  • Deposit() - Add funds to the treasury
  • Withdraw() - Allocate funds to recipients
Last modified on February 18, 2026