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 4 August 2026. These are the stable addresses to integrate against; where a contract uses the proxy/target pattern, this is the proxy. 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. The legacy Ethereum Controller (0xf96d54e4…) still resolves the migration-era addresses via getContract if you need to identify one; migration-era and genesis-era contract code lives on the protocol repo’s streamflow branch.

​
Verify against the on-chain Controller

Most Arbitrum One protocol addresses are 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, not on this chain, or not proxied (for …Target lookups). 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, such as an online UI or cast keccak "BondingManagerTarget". Prefix the digest with 0x, since online tools omit it and Arbiscan rejects bare hex.
  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.