Skip to main content
Addresses on this page are automatically updated via a Github Action workflow.
Data is sourced from the and verified on-chain.
Last Verified:

Livepeer Contract Addresses
Canonical Code

Livepeer Contracts Arbiscan
On-chain Canonical

Solidity Protocol Contracts

Solidity LPT Bridge Contracts

Livepeer uses a system of Ethereum smart contracts to permissionlessly govern its decentralised network. The Livepeer Protocol is deployed on Arbitrum One and uses these contracts to govern:
  • Livepeer Token (LPT) ownership and delegation
  • Staking and selection of active orchestrators
  • Distribution of inflationary rewards and fees to participants
  • Time-based progression of the protocol through rounds
  • Payment processing through a probabilistic micropayment system

​
Livepeer Contracts

There are three categories of contracts in the Livepeer Protocol as well as migration contacts:
  1. Core Protocol Contracts – staking, payments, round progression, and service discovery
  2. Token and Utility Contracts – the LPT token and bridge infrastructure
  3. Governance Contracts – on-chain voting, proposal execution, and treasury management
  4. Migration Contracts – historical Confluence upgrade contracts, migration complete

​
Core Protocol Contracts

The core protocol contracts manage staking, delegation, reward distribution, round progression, payment processing, and service discovery. The Controller serves as the central registry – upgrading a contract means registering a new target implementation address via the Controller, while the proxy address remains stable.

​
Controller

Arbitrum One The Controller is the central registry for all protocol contracts. Every other contract resolves peer contract addresses by calling getContract(keccak256("<n>")) on the Controller. Upgrades are applied by registering a new implementation address under the same name hash – the proxy addresses never change.
Verified · Active · Deployed by Livepeer DeployerPurpose:
  • Central address registry for all protocol contracts
  • Enables contract upgrades while keeping proxy addresses stable
  • Provides pause()/unpause() for emergency system-wide halts
  • Owner is the Governor contract – all upgrades must go through governance
Key functions (from Controller.sol):Contract

​
BondingManager

Arbitrum One The BondingManager is the most critical economic contract in the protocol. It manages the active orchestrator pool as a sorted doubly-linked list, handles all LPT bonding and unbonding, and distributes inflationary rewards and fees each round. The feeShare in the protocol is defined as: the percentage of fees paid to delegators by the transcoder (orchestrator). It is not the gateway’s cut – it is the orchestrator’s share of fees that they pass on to their delegators. Source: BondingManager.sol includes this as struct comment: ”// % of fees paid to delegators by transcoder”.
Address (Arbitrum One): Verified · ActivePurpose:
  • Manages the active orchestrator pool (sorted by stake using SortedDoublyLL)
  • Handles bond(), unbond(), and withdrawStake() for all delegators
  • Distributes inflationary LPT rewards to orchestrators and their delegators each round
  • Manages the unbonding period – delegators must wait unbondingPeriod rounds before withdrawing
  • Tracks per-round earnings pools for each orchestrator
  • Calls checkpointBondingState() on BondingVotes on every state change for governance weight
  • Since Delta upgrade: sends treasuryRewardCutRate fraction of each reward to Treasury; contributions halt automatically when treasury balance exceeds treasuryBalanceCeiling
Slashing: slashTranscoder() exists in the contract but is currently inoperative: the Verifier role is set to the null address (0x000...). Slashing could be re-enabled via governance by configuring the Verifier role and making necessary compatibility updates. It is out of scope for current audits.
Key functions (from BondingManager.sol, delta branch):Contract

​
TicketBroker

Arbitrum One The TicketBroker implements Livepeer’s off-chain probabilistic micropayment (PM) system. Gateways pre-fund a deposit and reserve on-chain; they send lottery tickets to orchestrators off-chain with each transcoding job. Orchestrators redeem winning tickets on-chain to claim payment. This amortises per-segment payment costs across many tickets.
Address (Arbitrum One): Verified · ActivePurpose:
  • Holds gateway ETH deposits and reserves
  • Validates and settles winning probabilistic payment tickets
  • Manages the unlock period before gateways can withdraw funds
  • Tracks claimed reserves per orchestrator per round to prevent over-redemption
  • Emits WinningTicketRedeemed (ticket redemption attempt) and WinningTicketTransfer (ETH actually moved) events used for on-chain payment monitoring
Key functions (from MixinTicketBrokerCore.sol):Contract

​
RoundsManager

Arbitrum One The RoundsManager defines the protocol’s time unit. A round is a fixed number of Arbitrum blocks. The current round must be initialised before orchestrators can call reward(). It stores per-round block hashes used as randomness for ticket validation.
Address (Arbitrum One): Verified · ActivePurpose:
  • Tracks the current round number and round length in blocks
  • Stores block hashes per round for ticket randomness (used by TicketBroker)
  • Enforces the round lock period – orchestrators cannot change parameters during the lock window at end of each round
  • initializeRound() must be called at the start of each new round before reward calls proceed
Key functions (from RoundsManager.sol):Contract

​
Minter

Arbitrum One The Minter controls LPT token inflation. Each round it calculates the mintable token supply based on the configured inflation rate. Since the Delta upgrade (LIP-91), a configurable fraction of each round’s reward is minted to the Treasury rather than solely to orchestrators and delegators.
Address (Arbitrum One): Verified · ActivePurpose:
  • Manages LPT token inflation schedule
  • Calculates mintable tokens per round based on current inflation rate and total LPT supply
  • Adjusts inflation up or down each round based on actual bonding rate vs targetBondingRate
  • Called by BondingManager during orchestrator reward() calls – not called directly
  • Holds ETH received from TicketBroker redemptions and disburses to orchestrators
Key functions (from Minter.sol):Contract

​
ServiceRegistry

Arbitrum One The ServiceRegistry stores each orchestrator’s publicly advertised HTTPS service URI on-chain. Gateway nodes query this registry during network initialisation to discover orchestrators. Each update emits a ServiceURIUpdate event that off-chain indexers track.
Address (Arbitrum One): Verified · ~600 transactions · Last active Jan 2026Purpose:
  • Allows orchestrators to register and update their service endpoint URIs
  • Enables gateway nodes to discover orchestrators when using -network arbitrum-one-mainnet
  • Not used when a gateway specifies -orchAddr directly
Key functions (from ServiceRegistry.sol):Contract

​
AIServiceRegistry

Arbitrum One A standalone ServiceRegistry for AI subnet orchestrators. Detached from the Controller – its address is hardcoded in go-livepeer (starter.go) rather than resolved dynamically. Deployed by a different deployer than the main protocol contracts.
Address (Arbitrum One): Verified · Deployed Apr 2024 · Active · Deployed by AI subnet deployer (different from main Livepeer Deployer)Purpose:
  • Stores service URI and capability metadata for AI-enabled orchestrators
  • Used when a node is started with -aiServiceRegistry flag
  • Same interface as ServiceRegistry (setServiceURI, getServiceURI)

​
Token and Utility Contracts

The LivepeerToken contract originates on Ethereum Mainnet and is bridged to Arbitrum One via paired gateway contracts, with a BridgeMinter handling L1 mint operations. All active protocol operations use the Arbitrum One representation. LPT must be bridged before it can be staked, delegated, or used for payments.
Livepeer moved from Ethereum Mainnet to Arbitrum One in 2022 (the Confluence upgrade) to increase throughput and reduce fees.On Ethereum Mainnet, only the LivepeerToken and BridgeMinter contracts remain operational. All other Ethereum Mainnet protocol contracts are paused.

​
LivepeerToken (LPT)

Ethereum Mainnet (origin) The LivepeerToken is the native protocol token. It is an ERC-20 with AccessControl-based MINTER_ROLE and BURNER_ROLE. The canonical token contract lives on Ethereum Mainnet; a bridged representation exists on Arbitrum One.
Address (Arbitrum One): Verified · 261,217 holders · ActiveAddress (Ethereum Mainnet): Verified · 1.88M holders · Origin tokenPurpose:
  • ERC-20 token used for bonding, staking, gateway payment reserves, and governance voting weight
  • approve() must be called before bonding or funding deposits
  • On Arbitrum One: minted by Minter (inflationary rewards) and by the bridge (inflows from L1)
Key functions (from LivepeerToken.sol, inherits OpenZeppelin ERC20 + ERC20Permit + ERC20Burnable + AccessControl):Contract

​
BridgeMinter

Ethereum Mainnet Holds MINTER_ROLE on the L1 LivepeerToken. Called by the bridge when LPT is transferred from Arbitrum back to Ethereum Mainnet, minting the corresponding L1 LPT.
BridgeMinter.sol is an Ethereum Mainnet contract predating the Delta upgrade. See on the streamflow branch of livepeer/protocol
Address (Ethereum Mainnet): Verified · Active · “Livepeer: Bridge Minter” on BlockscoutPurpose:
  • Holds MINTER_ROLE on the L1 LivepeerToken contract
  • Called exclusively by L1LPTGateway when LPT is bridged from Arbitrum back to Ethereum Mainnet
  • Also callable by L1Migrator for migration operations (withdrawETHToL1Migrator, withdrawLPTToL1Migrator)
  • Registered with the Ethereum Mainnet Controller (0xF96D54E490317c557A967ABfA5d6e33006BE69b3)
Key functions (from BridgeMinter.sol, streamflow branch):Contract

​
L1 LPTGateway / L2 LPTGateway

Ethereum Mainnet Arbitrum One Paired bridge gateway contracts on Ethereum Mainnet (L1) and Arbitrum One (L2). LPT bridged L1→L2 is locked in L1Escrow; LPT bridged L2→L1 is released from escrow or minted via BridgeMinter. Based on the Dai bridge architecture.
L2LPTGateway (Arbitrum One): Verified · ActiveL1LPTGateway (Ethereum Mainnet): Verified · ActiveL1Escrow (Ethereum Mainnet): Verified · Active · Holds bridged LPTContract

​
LivepeerTokenFaucet

Testnet Deployments
The LivepeerTokenFaucet is a non-production deploy-time convenience contract.
There is currently no active public testnet on Arbitrum or Ethereum.
You can run your own testnet using the full deploy script at deploy/deploy_contracts.ts
A deploy-time convenience contract that distributes test LPT in local and testnet environments. It deploys automatically via deploy_contracts.ts when targeting any non-production network, seeded with genesis.crowdSupply worth of test LPT.
It is never deployed on mainnet or arbitrumMainnet.
Purpose:
  • Distributes test LPT to developers running a local Livepeer stack
  • Enforces a per-address rate limit via requestWait (in hours) between requests
  • Whitelist addresses bypass the rate limit entirely
  • Seeded at deploy time with genesis.crowdSupply; never exists on mainnet or Arbitrum One mainnet
Key functions (from LivepeerTokenFaucet.sol):Contract

​
Governance Contracts

The Delta upgrade (LIP-89, LIP-91 - October 2023) introduced full on-chain governance alongside the Livepeer Treasury. The governance system consists of four contracts working together: BondingVotes checkpoints voting power, LivepeerGovernor manages proposal voting, Treasury holds protocol funds, and Governor executes approved upgrades.

​
BondingVotes

Arbitrum One BondingVotes implements the ERC-5805 votes interface, storing per-round stake checkpoints for every delegator and orchestrator. The LivepeerGovernor queries it to determine voting power at proposal creation time. Checkpoints are written automatically by BondingManager on every bond, unbond, reward, and earnings claim.
Address (Arbitrum One): Verified · ActivePurpose:
  • Stores per-round stake checkpoints for every participant
  • Implements ERC-5805 (getPastVotes, getPastTotalSupply) used by LivepeerGovernor
  • Checkpoints are written by BondingManager – not called directly by users
  • Supports delegator vote overrides: a delegator can override their orchestrator’s vote
Key functions (from BondingVotes.sol, delta branch):Contract

​
Governor

Arbitrum One The original upgrade execution contract. Holds the owner role on the Controller. Executes protocol upgrades (contract address updates, parameter changes) via a staged update queue with a configurable block delay.
Address (Arbitrum One): Verified · Active · Deployed by Livepeer DeployerPurpose:
  • Owns the Controller contract – only address that can call setContractInfo()
  • Executes protocol upgrade transactions after governance approval
  • Enforces a staged execution queue with a mandatory block-number delay
Key functions (from Governor.sol):The Update struct contains: address[] target, uint256[] value, bytes[] data, uint256 nonce.owner is a public state variable (not a function) returning the current owner address.Contract

​
LivepeerGovernor

Arbitrum One Implements OpenZeppelin’s upgradeable Governor framework adapted for Livepeer’s stake-weighted voting. Voting power equals bonded LPT as recorded by BondingVotes at proposal creation time. Supports GovernorCountingOverridable – delegators can override their orchestrator’s vote on any proposal.
Address (Arbitrum One): Verified · ActivePurpose:
  • On-chain voting for protocol proposals, weighted by bonded LPT stake
  • Delegators can override their orchestrator’s vote (GovernorCountingOverridable)
  • Passed proposals execute through the Treasury timelock, then through the Governor to the Controller
  • bumpGovernorVotesTokenAddress() must be called if BondingVotes address ever changes
Key functions (from LivepeerGovernor.sol, delta branch):Contract

​
Treasury

Arbitrum One An OpenZeppelin TimelockControllerUpgradeable that holds the protocol’s on-chain treasury. A configurable percentage of each round’s inflationary LPT rewards is directed here by the Minter. All disbursements require a passed LivepeerGovernor proposal. Automatic contributions halt when the treasury balance exceeds treasuryBalanceCeiling (configured in BondingManager).
Address (Arbitrum One): Verified · ActivePurpose:
  • Receives a fraction of each round’s inflationary LPT rewards (rate set by treasuryRewardCutRate in BondingManager)
  • Governed entirely by LivepeerGovernor – all disbursements require a passed proposal
  • Implements TimelockController – all operations have a mandatory delay between queue and execution
  • Contributions automatically halt when LPT balance exceeds treasuryBalanceCeiling
  • Funds Special Purpose Entities (SPEs) and ecosystem grants via governance proposals
Key functions (OpenZeppelin) TimelockControllerUpgradeable):Contract

​
Migration Contracts

The Confluence upgrade (2022) migrated the Livepeer protocol from Ethereum Mainnet to Arbitrum One. These contracts facilitated that migration.
The migration is complete - no new migrations are possible - but both contracts remain registered in the Controller.
L2Migrator continues to process pending claimStake calls from participants who have not yet claimed their migrated stake as of March 2026.

​
L2Migrator

Arbitrum One Facilitated the migration of bonded stake and delegations from Ethereum Mainnet to Arbitrum One during the Confluence upgrade. Participants who migrated on L1 claim their Arbitrum-side stake by calling claimStake() here. The contract still holds residual ETH and continues to receive claimStake calls from participants who have not yet claimed.
Address (Arbitrum One): Verified · Registered in Controller · Last active Feb 2026Purpose:
  • Receives cross-chain migration messages from the L1Migrator via the Arbitrum bridge
  • Allows participants to claim their migrated bonded stake on Arbitrum One via claimStake()
  • Allows delegators to claim migrated delegations via claimDelegatorStake()
  • Holds residual ETH from migration fee payments; no new migrations are possible
Key functions:

​
MerkleSnapshot

Arbitrum One Stores Merkle roots used to verify stake snapshots taken at the time of the Confluence migration. Used internally by L2Migrator to validate migration claims. No activity since deployment — its role was fulfilled during the migration window.
Address (Arbitrum One): Verified · Registered in Controller · No activity since deploymentPurpose:
  • Stores Merkle root snapshots (keyed by snapshot ID) set at migration time
  • Provides verify() for L2Migrator to validate that a claimed stake amount was included in the original snapshot
  • Read-only in practice; setSnapshot() is callable only by the Controller owner and has not been called since the migration
Key functions (from MerkleSnapshot.sol):Contract

​
Full Address Reference

For the complete list of all current and historical contract addresses across Arbitrum One and Ethereum Mainnet, including all historical target and implementation versions, see the Contract Addresses reference page. Last Verified

Contract Address Reference Page · Livepeer Docs
Automatically Updated

Livepeer Contract Addresses
Canonical Code

Livepeer Contracts Arbiscan
On-chain Canonical

LPT token mechanics, supply, minting, and the role of the token in the protocol.

On-chain treasury, funding proposals, SPEs, and the treasury balance ceiling.

On-chain voting, proposal lifecycle, and delegator vote overrides.

Inflation model, bonding rate targets, reward distribution, and fee economics.
Last modified on March 30, 2026