Skip to main content
Livepeer protocol contracts are deployed on Arbitrum One (active) and Ethereum Mainnet (legacy bridge and governance). Most use a proxy/target pattern: the proxy address is stable across governance upgrades, while the target changes when a new implementation is deployed.
Always verify an address on-chain before using it. Confirm you are on the official docs.livepeer.org site, and cross-check against the on-chain Controller (below) and a block explorer. An address with no label, unverified bytecode, or zero transactions is not a Livepeer contract.

​
Deployed addresses (Arbitrum One)

Resolved from the on-chain Controller (getContract(keccak256(name))) — last verified 30 July 2026. These are the stable proxy addresses. These Arbitrum One contracts are not registered in the Controller. Addresses come from Livepeer’s own deployment artifacts (livepeer/protocol, livepeer/arbitrum-lpt-bridge), cross-checked against on-chain state:

​
Deployed addresses (Ethereum Mainnet)

The genesis LPT token and the L1 side of the canonical bridge. Verified on-chain (token name()/symbol(), gateway l1Lpt()/l2Lpt() cross-references, and source-verified contract names) — last verified 30 July 2026:
Historical: before the 2022 Confluence migration the protocol ran on Ethereum mainnet; those contracts remain deployed but are permanently paused — if you find an old mainnet BondingManager or staking link, it is not the live protocol. All protocol activity is on Arbitrum One. Migration-era and genesis-era contracts are cataloged in the protocol repo.

​
Verify against the on-chain Controller

Every Arbitrum One protocol address is registered in the Controller at 0xD8E8328501E9645d16Cf49539efC04f734606ee4 (chain 42161). Query it directly — no trust in docs required:
A registered contract returns a non-zero address. 0x000…000 means the name is misspelled or not on this chain. Then cross-check the returned address on Arbiscan or Blockscout: it should carry a Livepeer: label and verified source.

​
Checking a proxy’s current Target implementation

The proxy addresses above are stable and are what you should interact with. Behind each proxy, the Target (implementation) address changes when governance deploys an upgrade. If you need to see the current implementation, the Controller registers it under the contract name with a Target suffix, e.g. BondingManagerTarget:
  1. Compute keccak256("BondingManagerTarget") with any keccak-256 tool — an online UI or cast keccak "BondingManagerTarget".
  2. Call getContract with that hash on the Controller’s Read Contract tab on Arbiscan (or via cast, as above).
The returned address is the live implementation behind that proxy.

​
Canonical sources

Protocol source

The deployed contract code (commit-pinned).

Livepeer on Arbiscan

On-chain verified contract labels.

Protocol parameters

Governance values read from these contracts.

How the network works

What each contract does in the job and reward flow.