# What a delegator is
Source: https://docs.livepeer.org/network/explanation/delegators
Bonding LPT is stake attribution, not custody transfer. What delegation means, what you earn, and what you actually risk.
A **delegator** is an LPT holder who **bonds** their tokens to an orchestrator. This puts your
capital to work securing the network and earning a share of that orchestrator's rewards — without
running any hardware yourself.
The single most important idea:
**Delegation is stake attribution, not custody transfer.** When you bond, your LPT sits in the
protocol's `BondingManager` contract on Arbitrum One. The orchestrator **cannot move or spend
your tokens.** Your wallet is always the only party that can unbond, withdraw, or redelegate.
What changes when you bond is *attribution*: your balance now counts toward one specific
orchestrator's total stake, which is what determines its rank and reward share.
## Why "doing nothing" costs you
Livepeer mints new LPT every round and distributes it to **bonded** stake. If you hold LPT but leave
it unbonded, you receive none of that issuance while bonded holders do. Your share of total supply
shrinks over time. Staying unbonded is not a neutral position — it is a slow dilution.
## What you earn
A bonded delegator can earn two things, both filtered through the orchestrator you pick:
* **LPT inflation rewards** — a share of each round's newly minted LPT, after the orchestrator keeps its `rewardCut`.
* **ETH fees** — a share of the ETH the orchestrator earns for compute work, according to its `feeShare`.
Neither is guaranteed by bonding alone. They depend on the orchestrator staying **active** and
reliably calling `reward()` each round. See [Economics](/network/explanation/economics) for the formulas and
a worked example.
## One wallet, one orchestrator
| Commitment | What it means |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| One orchestrator per wallet | A bonded position points to a single orchestrator at a time. To split, use separate wallets. |
| Arbitrum One only | Delegation happens on Arbitrum One, not Ethereum mainnet. |
| Exit delay | Full withdrawal requires unbonding and waiting out the [unbonding period](/network/reference/protocol-parameters). |
| Ongoing attention | Commission terms and reliability can change; check periodically. |
## Switching vs exiting
There are two different ways to change your position — pick by **what your problem is**:
* **Redelegate** — move your stake to a different orchestrator *without* the unbonding wait. Use this when the issue is the **operator** (missed rewards, worse terms, dropped out of the active set).
* **Unbond and withdraw** — stop participating and wait out the unbonding period before tokens return to your wallet. Use this when you want **liquid tokens** back.
## What you're actually risking
Slashing is **not currently active** on Livepeer mainnet, and your tokens are in the protocol
contract — not the operator's wallet. So the real risks are operational, not custodial:
* choosing an orchestrator that **misses reward calls** (the pool simply forgoes that round's inflation — there is no catch-up)
* an operator that later changes commission terms unfavorably
* needing liquidity before the unbonding period has passed
* contributing to stake concentration by always picking already-dominant operators
This is why **reward-call reliability matters more than a slightly better headline commission.**
## Next
How rewardCut, feeShare, and inflation turn into real returns.
The checklist for picking a good operator.
The end-to-end wallet walkthrough.
The live unbonding period and other governance values.
# Economics
Source: https://docs.livepeer.org/network/explanation/economics
Two revenue streams, two commission settings, and how every reward is split between an orchestrator and its delegators.
The orchestrator and delegator roles are two sides of one economic engine. An orchestrator earns
from two independent streams, and **shares a configurable portion of each with its delegators.**
Understanding this split is what lets either side make good decisions.
## Two revenue streams
| Stream | Currency | Source | Frequency | Depends on |
| --------------------- | -------- | --------------------------- | ----------------------- | ----------------------------------- |
| **Service fees** | ETH | Gateways paying for compute | Per job (probabilistic) | Volume of work, price, uptime |
| **Inflation rewards** | LPT | New LPT minted each round | Once per round | Total bonded stake; the reward call |
The streams are structurally independent. Fees track how much **work** you do; rewards track how much
**stake** you have. Both require active-set membership.
## Service fees (ETH)
Gateways pay with **probabilistic micropayment tickets**. Each ticket has a face value and a win
probability; the orchestrator redeems only winning tickets on-chain for ETH. Over many tickets,
earnings converge to face value × win probability.
How fees are split is set by the orchestrator's **fee share** (`feeShare`) — the percentage of fees
passed through to delegators:
```
total fee value = orchestrator's keep + delegator fee pool
```
A `feeShare` of 80% means delegators share 80% of fee revenue and the orchestrator keeps 20%. For
delegators, **higher feeShare is better.**
Current Explorer surfaces label this **Fee Share** (the part passed to delegators), not "fee cut."
Read it as: higher is better for delegators.
## Inflation rewards (LPT)
The protocol mints new LPT each round. An active orchestrator's pool receives a share proportional
to its total bonded stake — but **only if it calls `reward()` that round.** A missed call forfeits
that round's LPT for the whole pool, permanently.
How the pool is split is set by the **reward cut** (`rewardCut`) — the percentage the orchestrator
keeps:
```
total round reward = orchestrator's reward cut + delegator reward pool
```
| Reward cut | Orchestrator keeps | Delegators receive | Implication |
| ---------- | ------------------ | ------------------ | ----------------------------------------------------------------------- |
| 0% | none | 100% | Maximum pull for delegated stake; operator earns nothing from rewards |
| 10–25% | 10–25% | 75–90% | Common production range; balances operator return with delegator appeal |
| 100% | 100% | none | Maximum operator return; delegators get no LPT rewards here |
For delegators, **lower rewardCut is better.** `rewardCut` and `feeShare` move in opposite
directions, which is a common source of confusion — see the table below.
## The two settings, side by side
| Setting | Controls | Better for delegators when |
| ----------- | ------------------------------------------------- | -------------------------- |
| `rewardCut` | Share of **LPT inflation** the orchestrator keeps | **Lower** |
| `feeShare` | Share of **ETH fees** passed to delegators | **Higher** |
## A worked example (delegator's view)
Suppose in one round:
* **900 LPT** of issuance is available to delegators and orchestrators (after any treasury cut),
* your orchestrator controls **5%** of total bonded stake → its pool gets **45 LPT**,
* its `rewardCut` is **10%** → delegators share **40.5 LPT**,
* you hold **10%** of that pool's stake.
Your reward for the round is **4.05 LPT**. If many more delegators join the same orchestrator after
you, your slice of the pool shrinks — your *percentage* of the pool is what matters, not the absolute
stake.
## Why inflation matters even if you don't operate
The protocol targets a bonding rate (\~50% of LPT bonded) and **adjusts inflation to steer toward
it**: under-bonded → inflation rises to attract stake; over-bonded → inflation falls to reduce
dilution. Issuance can also carry a **treasury cut** (LIP-92 set 10%, currently paused at its balance
ceiling). The practical takeaway for both roles: the mint rate is **not static** — check the
[live values](/network/reference/protocol-parameters) rather than an old annualized figure.
## An orchestrator's costs
Earnings are only half the picture. Orchestrator costs fall into three buckets:
* **Hardware** — GPU(s), server, networking (capital, amortized).
* **Infrastructure** — electricity, bandwidth, colocation/cloud (electricity is usually the largest recurring cost).
* **Staking opportunity cost** — LPT locked in self-bond can't be used elsewhere.
Unlike gateways, orchestrators **don't pay for the jobs they process — they're paid.** Very low-stake
orchestrators should also check that reward-call gas doesn't exceed the LPT earned; if so, disable
automatic reward calling until stake grows (see [Configure](/network/guides/orchestrator-configure)).
## Next
Price competitively so gateways select you.
Use these settings to compare operators.
Where the treasury cut goes — and the vote your stake carries.
# Governance & the treasury
Source: https://docs.livepeer.org/network/explanation/governance
Bonded stake is voting power. How Livepeer governance and the community treasury work — and why staking gives you a say.
Staking LPT does more than earn rewards — it gives you a **vote**. Livepeer is governed on-chain by
its bonded stakeholders: the same orchestrators and delegators who secure the network also decide how
it changes. This page explains how that works and how the community treasury is funded and spent.
**Voting power comes only from bonded LPT.** Your weight equals your share of total bonded stake.
Unbonded tokens earn nothing *and* carry no vote — another reason "doing nothing" isn't neutral.
## Who votes, and how
Governance authority derives entirely from bonded stake, so both supply-side roles participate:
* **Orchestrators** vote with their self-bonded stake and publicly signal their stance.
* **Delegators** vote directly with their own bonded stake. If you don't cast a vote, the orchestrator you're bonded to effectively votes on your behalf — which is why an operator's governance positions are part of [choosing one](/network/guides/delegator-choose-orchestrator).
Voting power is **snapshotted when a proposal is created** (via the `BondingVotes` contract), so
moving stake at the last minute can't swing an active vote.
## What governance can — and can't — change
Governance operates at the **protocol layer** (on-chain). It sets the rules; it doesn't run the
network.
| Governance **can** change | Governance **can't** touch |
| ----------------------------------------------------------- | ------------------------------------ |
| Inflation parameters (target bonding rate, adjustment rate) | Which orchestrator a gateway selects |
| Contract implementations (upgrades, where enabled) | GPU scheduling / job execution |
| Treasury allocations | Gateway pricing strategy |
| Protocol constants (e.g. active-set size, unbonding period) | Any off-chain operational behavior |
Everything in the right column is the **network layer** — it happens off-chain, inside the rules the
left column defines.
## How a change happens: two proposal tracks
Governance has **two proposal tracks** — but they're more alike than they first appear. Both run
through the **same on-chain lifecycle** and the **same vote**; what actually differs is the
*preparation* and the *effect*. Conflating the two is the most common mistake new proposers make.
| | Protocol proposal (LIP) | Treasury proposal |
| --------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
| **Changes** | The protocol's rules — parameters, contract upgrades | Releases treasury funds to a recipient |
| **Preparation** | A technical spec + implementation, reviewed in the [LIPs repo](https://github.com/livepeer/LIPs) with a 10-day Last Call | A budget + deliverable, workshopped as a [forum RFP](https://forum.livepeer.org/c/lips/18) |
| **The vote** | Identical (below) | Identical (below) |
The **shared lifecycle**, conceptually:
1. **Prepare** — an idea is raised on the forum, then worked into either a drafted LIP or a budgeted RFP.
2. **Submit on-chain** — anyone with **100 LPT** submits it; the stake is returned if it passes.
3. **Vote** — a stake-weighted, on-chain voting window opens, with bonded LPT as the weight.
4. **Decide** — it passes only with **≥33% quorum** and **>50% approval**.
5. **Execute** — on success, the Governor contract applies the change automatically.
Doing either is a task, not a concept — see [Submit a protocol LIP](/network/guides/submit-a-protocol-lip)
or [Submit a treasury proposal](/network/guides/submit-a-treasury-proposal).
## The on-chain rules
A binding vote must clear two thresholds, both enforced by the contracts:
* **Quorum — 33%** of all bonded LPT must participate, or the vote is invalid. This stops a small group from pushing changes through on low turnout.
* **Approval — >50%** of participating votes must be in favor.
Clear both and the proposal enters a **timelock** before execution — a delay that gives stakeholders
time to react to an approved change.
The exact numbers behind this — proposal threshold, quorum, voting delay and period, and the timelock
— are governance-controlled and can change. See [Protocol parameters](/network/reference/protocol-parameters)
for the live values and the contracts that hold them.
Ready to actually cast a vote? That's a task, not a concept — follow the
[Vote on a proposal](/network/guides/vote-on-a-proposal) how-to.
## The community treasury
The protocol can route a share of every round's LPT inflation to an on-chain **community treasury** —
LIP-92 set a **10% treasury reward cut**, taken before orchestrators and delegators split the rest,
with a **balance ceiling** that pauses contributions once the treasury is full. That ceiling has been
reached: as of July 2026 the live cut rate reads **0% (paused)**, and governance can resume it — see
[Protocol parameters](/network/reference/protocol-parameters) for the live value. Either way, the
treasury itself remains funded and active: a protocol-owned pool for the public goods a pure market
underprovides.
**What it funds:**
| Category | Examples |
| ----------------------- | ------------------------------------------------ |
| Ecosystem development | Apps, integrations, SDKs |
| Protocol R\&D | Security research, audits, economic modeling |
| Infrastructure support | Operator tooling, monitoring, reliability |
| Community programs | Education, onboarding, documentation, events |
| Strategic interventions | Bootstrapping supply or demand where markets lag |
**How it's spent:** a treasury proposal runs the same on-chain path as any other proposal — submit
with 100 LPT, clear 33% quorum and >50% approval, execute automatically. What's specific to the
treasury is the **preparation** and the **effect**: instead of a technical spec, it's a **budget and
a deliverable** workshopped as a [forum RFP](https://forum.livepeer.org/c/lips/18); instead of a rule
change, a passing vote **releases treasury LPT** to the recipient — no protocol-code change.
The recipient is usually a **Special-Purpose Entity**: a community-chartered, funded working group
that delivers a defined scope over time, draws its allocation against milestones, and reports back
publicly. This is how one-time governance approval becomes ongoing execution — core protocol
maintenance, research, real-time AI development, tooling. Track proposals and balances at
[explorer.livepeer.org/treasury](https://explorer.livepeer.org/treasury).
Requesting treasury funding is its own task — see the
[Submit a treasury proposal](/network/guides/submit-a-treasury-proposal) how-to.
The treasury is only as sound as the governance controlling it. Its risks are governance risks —
stake concentration, low turnout, or mis-specified proposals — not a separate trust assumption.
## Next
Put this into practice — cast a vote with your bonded stake.
Where the treasury cut fits in the reward split.
An operator's governance stance is part of the decision.
Live governance thresholds and the contracts behind them.
Governor, BondingVotes, and Treasury on Arbitrum.
# How the network works
Source: https://docs.livepeer.org/network/explanation/how-the-network-works
Rounds, the active set, reward calls, and the life of a single job — the shared machinery behind both roles.
Both orchestrators and delegators are governed by the same small set of on-chain mechanics. Once you
understand rounds, the active set, and reward calls, almost everything else follows.
## Rounds
A **round** is the protocol's unit of accounting. Each round, the protocol:
* elects the active set,
* updates inflation state,
* lets active orchestrators mint that round's rewards,
* snapshots bonded stake for governance.
The common shorthand is "about one day per round." The exact cadence depends on chain timing — use
the [Explorer](https://explorer.livepeer.org) for the current round and countdown rather than a fixed
hourly estimate.
## The active set
Only the **top orchestrators by total bonded stake** (self-stake + delegated stake) are in the
**active set** for a given round. Only active-set members:
* receive LPT inflation rewards, and
* receive jobs from gateways.
Stake below the threshold means an orchestrator is registered but earns nothing from either stream.
Livepeer's public product surfaces describe the active set as **100 orchestrators**. The size is
governance-controlled — if you need an operationally exact value, read `numActiveTranscoders()`
on-chain. See [Protocol parameters](/network/reference/protocol-parameters).
## The `reward()` call
Every active orchestrator must submit `reward()` on-chain **once per round**. That call is what
causes the protocol to mint and account for the round's inflationary LPT for that orchestrator's
pool — which is then split between the orchestrator and its delegators.
If the call is missed:
* no inflation is minted for that pool for that round,
* **the missed round is never backfilled**,
* every delegator in that pool permanently misses that round's inflation.
This is the single most important reliability signal on the network. It's why orchestrators automate
reward calling and why delegators check a candidate's reward-call history before bonding.
## How stake is accounted
When a delegator bonds to an orchestrator, the orchestrator's **effective stake** grows by that
amount. That total is what determines active-set ranking and the size of the orchestrator's reward
pool. Your tokens remain yours; only your stake *weight* is attributed to the operator you chose.
The protocol tracks earnings through cumulative accounting rather than rewriting every delegator's
balance each round. You realize accrued earnings by calling `claimEarnings()`, which also runs
automatically when you bond more, unbond, rebond, or redelegate.
**Claim timing has an edge case.** If you claim *before* your orchestrator has called `reward()`
for the current round, you can skip that round's accounting entirely. Safe default: claim **late
in the round**, after your orchestrator has already called `reward()`.
## Where demand comes from
Everything above is the supply side. The work itself comes from **applications** — real-time AI
video products, streaming platforms, and other services that need video transcoded or AI models run.
Applications don't talk to orchestrators directly: they integrate with a **gateway**, which
aggregates their jobs, selects orchestrators (by capability, price, latency, performance, and
stake), and pays for the work in ETH. From an orchestrator's seat, gateways *are* the demand.
Want to be on that side of the marketplace — sending jobs instead of serving them? A developer
platform and a Build section of these docs are on the way; until then, ask in the
[Livepeer Discord](https://discord.gg/livepeer).
## The life of a job
This is what happens when a gateway sends a single job to an orchestrator:
The gateway sends a video segment or AI request with an attached probabilistic micropayment ticket.
The orchestrator checks the ticket is valid — correct signer, sufficient face value, expected range.
The job goes to the video pipeline (transcoder) or AI pipeline (AI runner) based on its type.
The worker transcodes the segment to all requested profiles, or runs inference against the loaded model.
The orchestrator returns the result to the gateway over HTTP.
The ticket is stored. Each ticket has a probability of being a "winning" ticket.
Only winning tickets are submitted to the `TicketBroker` contract on Arbitrum, releasing ETH to the orchestrator.
Over many tickets, actual ETH earnings converge to the expected value (face value × win
probability). This **probabilistic micropayment** scheme avoids an on-chain transaction per segment.
## The protocol contracts
Orchestrators interact with four contracts; gateways touch only two of them. This protocol depth is
what distinguishes the orchestrator role.
| Contract | Role |
| ----------------- | --------------------------------------------------------- |
| `BondingManager` | Staking, delegation, reward/fee cuts, reward distribution |
| `RoundsManager` | Tracks rounds; gates the once-per-round reward call |
| `TicketBroker` | Redeems winning payment tickets for ETH |
| `ServiceRegistry` | Stores each orchestrator's service URI for discovery |
See [Contract addresses](/network/reference/contracts) for the deployed addresses and how to verify them.
## Next
Turn these mechanics into a revenue model.
The live, governance-controlled values referenced above.
# What an orchestrator is
Source: https://docs.livepeer.org/network/explanation/orchestrators
The compute supply layer of Livepeer: what orchestrators do, how they fit into the network, and what running one involves.
An **orchestrator** is the compute supply layer of the Livepeer network. It accepts jobs from
gateways, runs them on GPU hardware, and returns the results. Orchestrators do the actual work —
transcoding video and running AI inference — and get paid for it.
The clearest mental model: an orchestrator is a **GPU-for-hire on a decentralized marketplace**.
You connect your GPU, declare what it can run and at what price, and the network sends you work.
You earn ETH for each completed job and LPT for participating in the protocol each round.
## Where it sits
The network has three layers above the protocol. Orchestrators are the compute layer.
| Layer | Who | Responsibility |
| -------------------------- | ------------------------------------- | --------------------------------------------------------------------- |
| **Application** | Developers, streaming and AI products | Send requests to gateways; receive results |
| **Gateway** | Gateway operators | Aggregate demand, select orchestrators, dispatch jobs, handle payment |
| **Compute (orchestrator)** | **You** | Execute video and AI work on GPUs; receive payment tickets |
| **Protocol** | Arbitrum smart contracts | Staking, reward distribution, payment settlement, discovery |
A key consequence: **you don't choose your work — gateways choose you.** Selection runs in one
direction. Gateways rank orchestrators by capability, price, latency, reliability, and stake, then
send jobs to the winners. Everything you do as an operator is about being an attractive choice in
that ranking. See [How the network works](/network/explanation/how-the-network-works) for the full job flow.
## What it does
Core responsibilities of the `go-livepeer` node running in orchestrator mode:
* **Execute jobs** — receive video segments or AI inference requests and route them to GPU workers.
* **Advertise capabilities** — broadcast which pipelines, models, and codecs it supports, and the price for each.
* **Receive payments** — collect probabilistic micropayment tickets per segment or request from gateways.
* **Call rewards** — trigger the protocol's reward mechanism once per round to claim LPT inflation.
* **Manage workers** — coordinate the transcoder (video) and AI runner (inference) processes.
## Two pipelines, one node
A single orchestrator process runs two independent pipelines. Many operators run both at once — a
"dual-workload" node.
| | Video pipeline | AI pipeline |
| ----------- | ---------------------------------- | ------------------------------------------------ |
| **Input** | Live video segments from a gateway | An HTTP inference request (prompt, image, audio) |
| **Worker** | Transcoder (NVENC GPU) | AI runner (a Docker container per model) |
| **Output** | Encoded segments | Image, video clip, JSON, or audio |
| **Payment** | Wei per pixel per segment | Wei per pixel or per millisecond |
| **Session** | Long-lived (whole stream) | Short-lived (one request or batch) |
## What it is *not*
Orchestrators handle compute and payment receipt. They do **not** route jobs between nodes, ingest
RTMP from applications, or manage end-user API keys and billing — that is the **gateway** role. If
you want to aggregate demand and route work across many orchestrators, you're looking for a gateway,
which is out of scope for these docs.
## Ways to run one
| Setup | What it means | Best for |
| ----------------- | -------------------------------------------------------------- | ----------------------------------------- |
| **Solo operator** | One node on one machine handles everything | Single-GPU operators getting started |
| **O-T split** | Orchestrator and transcoder run as separate processes/machines | Multi-GPU operators optimizing throughput |
These docs assume you're running your own node.
## Next
Rounds, the active set, and the life of a job.
The two revenue streams and how they're split with delegators.
Put this into practice on mainnet.
Which GPUs work, and how much VRAM each workload needs.
# Acquire LPT on Arbitrum
Source: https://docs.livepeer.org/network/guides/delegator-acquire-lpt
Get LPT into a self-custody wallet on Arbitrum One so it can be delegated — by bridging, withdrawing, or swapping.
Delegation happens on **Arbitrum One**. Before you can bond, your LPT must be in a self-custody wallet
on that network, with a little ETH there for gas. This guide covers the three routes to get there.
This applies only to **unbonded** LPT. If your LPT is already bonded, you must
[unbond and withdraw](/network/guides/delegator-manage) — and wait out the unbonding period — before you can
bridge or move it.
## What "ready to delegate" means
Your LPT is ready once **all** of these are true:
* the token is in a self-custody wallet on **Arbitrum One**,
* you hold a small **ETH balance on Arbitrum One** for future protocol transactions,
* the wallet can connect to [Livepeer Explorer](https://explorer.livepeer.org).
You always need gas on the chain where you're signing. A canonical bridge deposit means **Ethereum
mainnet** gas first, then a small **Arbitrum** balance for delegation actions afterward.
## Route 1 — Canonical bridge (Ethereum → Arbitrum One)
Use this if you already hold LPT on Ethereum mainnet and want the trust-minimized path.
Go to [bridge.arbitrum.io](https://bridge.arbitrum.io/) and connect the wallet holding your
mainnet LPT.
Search for `LPT`. If it doesn't appear, paste the Ethereum-mainnet LPT token address directly.
Confirm the destination is **Arbitrum One**, enter the amount, and sign the approval.
Sign the deposit. The bridge locks mainnet LPT and mints the Arbitrum-side token. Track it in the
bridge UI or the [retryable dashboard](https://retryable-dashboard.arbitrum.io/).
Confirm the LPT is visible in your Arbitrum wallet before delegating.
LPT uses **dedicated bridge contracts**, not the generic ERC-20 gateway flow. Don't assume a
third-party bridge supports LPT unless it explicitly says so. See
[Contract addresses](/network/reference/contracts).
## Route 2 — Withdraw directly from an exchange
If you're buying LPT on an exchange, the fastest route is often a **direct withdrawal to Arbitrum
One**. Don't rely on any static list of supported exchanges — verify the exchange's network selector
offers Arbitrum One at the moment you withdraw.
## Route 3 — Swap on Arbitrum One
If you're already on Arbitrum One with ETH, WETH, or stablecoins, swapping into LPT on a DEX can be
simpler than bridging LPT itself. The end requirement is identical: the LPT must end up in your own
Arbitrum wallet.
## Next
Compare operators before you bond.
Execute the bond once your LPT is on Arbitrum.
# Choose an orchestrator
Source: https://docs.livepeer.org/network/guides/delegator-choose-orchestrator
Evaluate orchestrators on the factors that actually drive returns — reliability first, commission second — before you bond.
Choosing an orchestrator is the most consequential decision you make as a delegator. A well-run
operator with consistent reward calls and fair commission earns you meaningful returns; a poorly run
one can earn you nothing even with an attractive headline commission. Do this work in the
[Explorer](https://explorer.livepeer.org) before you bond.
## Before you start
You need LPT on Arbitrum One, a little ETH there for gas, and a wallet connected to the Explorer. If
that's not done yet, see [Acquire LPT on Arbitrum](/network/guides/delegator-acquire-lpt).
## Step 1 — Confirm active-set status
In the Explorer, filter to **currently active** orchestrators and open each candidate's profile. If
an operator isn't active now, your stake helps them compete for activation but **earns no round
rewards** until they're active.
## Step 2 — Check reward-call reliability
This is the first real quality gate — check it **before** commission or branding. Look at the recent
reward-call history.
| Strong signal | Weak signal |
| ------------------------------------------------ | ---------------------------------- |
| Near-perfect reward calling across recent rounds | Frequent missed rounds |
| No recent streak of misses | Long gaps |
| No sign of being underfunded for gas or absent | Recent inactivity with no recovery |
A missed `reward()` means the whole delegator pool simply misses that round's inflation — there's no
catch-up. Common causes are operator downtime, poor automation, or running out of gas.
## Step 3 — Compare commission terms
Two settings, moving in **opposite** directions for you:
* **`rewardCut`** — the % of inflationary LPT the orchestrator keeps. **Lower is better.** `10%` means delegators share the other `90%`.
* **`feeShare`** — the % of ETH fees passed to delegators. **Higher is better.** `80%` means delegators share `80%` of fee revenue.
Current Explorer surfaces show **Fee Share** (passed to delegators), not "fee cut." So for fee
share, higher is better; for reward cut, lower is better. Don't let a great `rewardCut` distract
you from weak reliability (Step 2).
## Step 4 — Check concentration and resilience
After reliability and commission, look at how much of total bonded stake the operator already
controls:
* Are they comfortably active, or just above the cutoff?
* Are they already highly dominant?
* Are you comfortable adding to that concentration?
From a pure-yield view, big operators aren't automatically better. From a network-health view,
delegating only to already-dominant operators worsens centralization.
## Step 5 — Look for durability
For meaningful positions, also weigh: how long they've been active, visible governance participation,
whether they communicate publicly, and whether their history shows consistency rather than one good
month.
## Selection checklist
* [ ] currently active
* [ ] reliable recent reward-call history
* [ ] acceptable `rewardCut` (lower is better)
* [ ] acceptable `feeShare` (higher is better)
* [ ] not uncomfortably concentrated
* [ ] durable enough for your risk tolerance
## Common questions
No. One bonded position maps to one orchestrator per wallet. Use separate wallets to split.
Your stake stays bonded but stops earning round rewards until they return or you redelegate.
A small, reusable Arbitrum ETH balance for the initial delegation plus later claims,
redelegation, or unbonding. Think "small reusable balance," not a fixed dollar amount.
## Next
Execute the bond now that you've chosen.
Claim, compound, redelegate, and exit.
# Manage your delegation
Source: https://docs.livepeer.org/network/guides/delegator-manage
Claim and compound rewards, switch orchestrators, and exit — without losing avoidable rewards to bad timing.
Once you're delegated, the work shifts from opening the position to managing it well. This guide
covers claiming, compounding, redelegating, and exiting — including the timing edge case that can
silently cost you a round's rewards.
## Rewards accrue automatically
If your orchestrator stays active and keeps calling `reward()`, your pending earnings update in
protocol state on their own. You don't need to "collect every round" for accrual to happen. What you
*do* manage is **when to checkpoint** those earnings, whether to **stay**, and when to **exit**.
## Claim your earnings
From the [Explorer](https://explorer.livepeer.org): connect your wallet → open your account page →
**Claim Earnings** → sign. This calls `claimEarnings()`, moving accrued rewards into your bonded
balance.
**Claim late in the round.** The protocol records `lastClaimRound` when `claimEarnings()` runs. If
your orchestrator has **not yet** called `reward()` for the current round when you claim, you can
skip that round's rewards and fees entirely. The Explorer may not warn you. Safe default: claim
**after** your orchestrator has already called `reward()` for the round.
## Compound your position
Claiming increases your bonded balance, so future rewards are earned on a larger base. If you intend
to stay delegated, compounding is usually the default. There's no forced schedule — pick a cadence
that fits your position size and the small gas cost of acting on Arbitrum. Not claiming for many
rounds doesn't forfeit rewards, but it delays compounding.
## Redelegate to switch operators
Redelegation moves your stake to a different orchestrator **without** the full unbonding wait. Use it
when the problem is the operator:
* they start missing reward calls,
* commission terms become unattractive,
* they drop out of the active set,
* you want to move away from an over-concentrated operator.
Redelegation also triggers earnings checkpointing. Moving at the **start** of a round, before your
current operator has called `reward()`, can create the same skipped-round problem as a mistimed
claim. Move late in the round when possible.
## Unbond and withdraw to exit
Full exit is a different path from switching — use it when you want **liquid tokens back**.
```
bond() → [Bonded] → unbond() → [Unbonding] → (wait the unbonding period) → [Withdrawable] → withdrawStake()
▲ │
└──────────────────────────── rebond() ───────────────────────────┘
```
Start unbonding from your Explorer account page. You can unbond part of your balance and leave the rest bonded.
The on-chain unbonding period is currently **7 rounds** — verify the live value in
[Protocol parameters](/network/reference/protocol-parameters).
Return once the position is withdrawable and withdraw to your wallet.
Changed your mind during unbonding? **`rebond()`** cancels the exit and returns the position to
bonded status.
## Keep an eye on your position
At a minimum, periodically check: active/inactive status, reward-call consistency, `rewardCut` and
`feeShare` changes, and any governance proposals affecting delegator economics.
## Common questions
No — earnings are accounted against your position, not abandoned with the old orchestrator. The
risk is timing, not loss of ownership.
Yes. Part of the balance can enter unbonding while the rest stays bonded and earning.
Yes. Rebonding cancels the exit and returns that stake to bonded status.
There's no protocol-enforced minimum. The practical question is whether the position justifies the
gas and effort of managing it.
## Next
Confirm the live unbonding period before you act.
Re-evaluate operators before redelegating.
# Activate on Arbitrum
Source: https://docs.livepeer.org/network/guides/orchestrator-activate
Fund your wallet, stake LPT, register your service URI, and enter the active set so gateways can send you jobs.
A configured node isn't earning yet. This guide connects it to the Livepeer protocol on Arbitrum One:
fund the wallet, stake LPT, activate on-chain, and confirm reward calling.
Start this **after** ETH and LPT are already in your orchestrator wallet on Arbitrum One. Acquiring
LPT often involves exchange settlement and bridging — plan for hours to days. See
[Acquire LPT on Arbitrum](/network/guides/delegator-acquire-lpt).
## 1. Point at a reliable Arbitrum RPC
`-ethUrl` connects the node to Arbitrum One. Free tiers from **Alchemy** (300M compute units/mo) or
**Infura** (100K req/day) work for most operators. Public endpoints like `arb1.arbitrum.io/rpc` are
for testing only — a dropped connection during round initialization can forfeit that round's reward.
Verify the endpoint is actually Arbitrum One:
```bash theme={null}
curl -s -X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' \
YOUR_RPC_URL
# Expect "result":"0xa4b1" (42161). "0x1" means you're on Ethereum L1 — switch endpoints.
```
## 2. Identify and back up the wallet
On first start, `go-livepeer` creates an account and prints the address in the logs. Record it — this
address receives ETH fees and holds your staked LPT.
```bash theme={null}
docker compose logs 2>&1 | grep -i "account\|address"
```
The private key lives at `~/.lpData/arbitrum-one-mainnet/keystore`. **Back it up offline now.**
Losing the keystore means permanent loss of the account and all bonded LPT.
## 3. Fund the wallet with ETH on Arbitrum
Every on-chain action (activation, reward calls, ticket redemption) costs gas. Keep at least
**0.05 ETH** on Arbitrum One to start, and never let it fall below \~0.01 ETH. Get arbETH by
withdrawing from an exchange that supports Arbitrum, or bridging from L1 at
[bridge.arbitrum.io](https://bridge.arbitrum.io). Verify the balance on [Arbiscan](https://arbiscan.io).
## 4. Stake LPT
LPT bonded to your address is what puts you in the active set (top orchestrators by total stake).
Check the current threshold on the [Explorer](https://explorer.livepeer.org/orchestrators) before
deciding how much to acquire. Then open the CLI and bond:
```bash theme={null}
docker exec -it livepeer-orchestrator livepeer_cli
```
Select the bond/stake option and enter an amount. Two transactions are submitted — `approve`, then
`bond`. Wait for both to confirm.
## 5. Activate on-chain
In `livepeer_cli`, select **"Invoke multi-step 'become an orchestrator'"** and set your commission:
| Prompt | Example | Meaning |
| --------------- | --------------------- | ------------------------------------------------------ |
| Reward Cut | `10` | % of LPT inflation you keep (10% → delegators get 90%) |
| Fee Cut | `95` | % of ETH fees you keep (95% → delegators get 5%) |
| Service address | `YOUR_PUBLIC_IP:8935` | Must match `-serviceAddr` exactly |
**The Explorer displays Fee Cut inverted, as "Fee Share."** Set Fee Cut `95` here and your profile
will show **Fee Share 5%** — the portion passed to delegators. That's the same setting, not a
misconfiguration. (Reward Cut displays as-is.)
Your node joins the active set at the **start of the next round** (\~22h), and only if your total
stake is in the top 100. The Explorer may show **Registered** until then.
See [Economics](/network/explanation/economics) for how these two settings affect both your earnings and your
appeal to delegators.
## 6. Confirm reward calling
`go-livepeer` calls `reward()` automatically each round by default. Make sure it isn't disabled:
```bash theme={null}
docker compose logs 2>&1 | grep -i reward
```
The startup command should **not** include `-reward=false`. A missed round forfeits that round's LPT
permanently — there is no catch-up.
**Exception for very low stake:** if reward-call gas costs more than the LPT you'd earn, disabling
automatic calling and calling manually until your stake grows can be the rational choice. Reward
calls use \~350k–450k gas (cents at typical Arbitrum prices).
## 7. Verify
On [explorer.livepeer.org/orchestrators](https://explorer.livepeer.org/orchestrators), search your
address and confirm **Status**, **Service URI**, **Stake**, **Reward Cut**, and **Fee Cut**. Then
confirm external reachability:
```bash theme={null}
curl -k https://YOUR_PUBLIC_IP:8935/status
```
If the Service URI is wrong or unreachable, update it in `livepeer_cli` (this costs gas). A bad or
unreachable service address is the most common reason an active node still receives no jobs — see the
[FAQ](/network/reference/faq).
## Next
The other half of getting selected by gateways.
Open a second revenue stream.
# Add AI inference
Source: https://docs.livepeer.org/network/guides/orchestrator-add-ai
Add AI pipelines to a working transcoding orchestrator: check VRAM, configure aiModels.json, and enable the AI worker.
This guide adds AI inference to an orchestrator that is **already running and activated** for
transcoding. By the end, your node accepts AI jobs alongside video work.
Setting up from scratch? Do [Run your first orchestrator](/network/tutorials/run-your-first-orchestrator)
first, then come back here. AI pipelines require **Linux**.
## 1. Check your available VRAM
AI inference runs in a separate Docker container. If it shares a GPU with transcoding, VRAM is split
between them. Check what's free:
```bash theme={null}
nvidia-smi --query-gpu=index,name,memory.total,memory.free --format=csv
```
Pick a pipeline you can actually fit:
| Pipeline | Min VRAM |
| ------------------------- | -------- |
| `image-to-text` | 4 GB |
| `segment-anything-2` | 6 GB |
| `llm` (quantized 7–8B) | 8 GB |
| `audio-to-text` (Whisper) | 12 GB |
| `image-to-video` | 16 GB+ |
| `image-to-image` | 20 GB |
| `text-to-image` (SD/SDXL) | 24 GB |
If the GPU lacks free VRAM for both transcoding and your chosen pipeline, AI runner containers fail
to start. Pick a lower-VRAM pipeline, dedicate a second GPU to AI, or stop transcoding on that GPU.
See the [hardware reference](/network/reference/hardware) for the full VRAM-by-workload table.
## 2. Pull the AI runner image
```bash theme={null}
docker pull livepeer/ai-runner:latest
# Some pipelines need a dedicated image, e.g.:
docker pull livepeer/ai-runner:segment-anything-2
```
## 3. Configure `aiModels.json`
This file tells your node which pipelines and models to serve, what to charge, and what to keep warm
in VRAM. Create `~/.lpData/aiModels.json` with at least one entry:
```json theme={null}
[
{
"pipeline": "text-to-image",
"model_id": "ByteDance/SDXL-Lightning",
"price_per_unit": 4768371,
"warm": true
}
]
```
| Field | Required | Description |
| -------------------- | -------- | ------------------------------------------------------------- |
| `pipeline` | Yes | Pipeline name (e.g. `text-to-image`, `audio-to-text`, `llm`) |
| `model_id` | Yes | Hugging Face model ID (must be on the Livepeer-verified list) |
| `price_per_unit` | Yes | Price in wei per unit |
| `warm` | No | If `true`, preload into VRAM on startup |
| `capacity` | No | Max concurrent requests (default `1`) |
| `optimization_flags` | No | `SFAST` (~~+25% speed) and/or `DEEPCACHE` (~~+50% speed) |
Don't use `DEEPCACHE` with Lightning/Turbo models — they're already optimized and quality drops.
`SFAST` and `DEEPCACHE` can't be combined. Changes to `aiModels.json` are **not** hot-reloaded —
restart the node after editing.
## 4. Enable the AI worker
Add three flags to your startup command:
```bash theme={null}
livepeer \
...your existing transcoding flags... \
-aiWorker \
-aiModels ~/.lpData/aiModels.json \
-aiModelsDir ~/.lpData/models
```
| Flag | What it does |
| -------------- | ----------------------------------------------------------- |
| `-aiWorker` | Enables the AI worker; without it, all AI config is ignored |
| `-aiModels` | Path to `aiModels.json` |
| `-aiModelsDir` | Host directory holding cached model weights |
Running in Docker? Mount the Docker socket so the node can spawn AI runner containers, and use port
`8936` to avoid clashing with the transcoding orchestrator on `8935`:
```bash theme={null}
docker run --name livepeer-ai-orchestrator \
-v ~/.lpData/:/root/.lpData/ \
-v /var/run/docker.sock:/var/run/docker.sock \
--network host --gpus all \
livepeer/go-livepeer:master \
-orchestrator -serviceAddr 0.0.0.0:8936 -nvidia 0 \
-aiWorker \
-aiModels /root/.lpData/aiModels.json \
-aiModelsDir ~/.lpData/models
```
With Docker-out-of-Docker, `-aiModelsDir` must be a path on the **host machine**, not inside the
container — the node passes it directly to the runner containers it spawns.
## 5. Verify AI is active
Within seconds of startup you should see a managed-container log line for each warm model:
```
INFO Starting managed container gpu=0 name=text-to-image_ByteDance_SDXL-Lightning ...
```
Then send a test request to the runner:
```bash theme={null}
curl -X POST "http://localhost:8000/text-to-image" \
-H "Content-Type: application/json" \
-d '{"model_id":"ByteDance/SDXL-Lightning","prompt":"A cool cat on the beach","width":512,"height":512}'
```
A successful response contains an `images` array. Finally, confirm your pipelines appear externally at
[tools.livepeer.cloud/ai/network-capabilities](https://tools.livepeer.cloud/ai/network-capabilities)
(search your orchestrator address; allow 2–5 minutes).
If jobs still don't arrive, check `aiModels.json` is valid, the `model_id` matches a verified model,
and the runner is reachable — see the AI troubleshooting entries in the [FAQ](/network/reference/faq).
## Next
Price each pipeline and model competitively.
VRAM planning and GPU selection for AI.
# Configure your orchestrator
Source: https://docs.livepeer.org/network/guides/orchestrator-configure
Set the go-livepeer flags that define how your node runs: GPU selection, session limits, networking, and deployment mode.
This guide covers the flags every orchestrator sets, and how to choose their values. It assumes
`go-livepeer` is installed and your GPU is detected. For the full flag list, see the
[CLI flags reference](/network/reference/cli-flags).
## The essential flags
These must be set every time the node starts as an orchestrator.
| Flag | Purpose |
| ------------------------------- | --------------------------------------------------------------------------------- |
| `-network arbitrum-one-mainnet` | Join the production network (default is `offchain` — no protocol participation) |
| `-ethUrl ` | An **Arbitrum One** RPC endpoint for on-chain reads/writes |
| `-orchestrator` | Enable the on-chain protocol role (routing, reward calls, discovery) |
| `-transcoder` | Enable local GPU transcoding |
| `-nvidia ` | Which NVIDIA GPUs to use (`0`, `0,1`, or `all`) |
| `-maxSessions ` | Max concurrent transcode sessions |
| `-pricePerUnit ` | Price per pixel, in **wei** (see [Pricing](/network/guides/orchestrator-pricing)) |
| `-serviceAddr ` | Public address gateways use to reach you |
A complete combined-mode startup command:
```bash theme={null}
livepeer \
-network arbitrum-one-mainnet \
-ethUrl https://arb-mainnet.g.alchemy.com/v2/YOUR_API_KEY \
-orchestrator \
-transcoder \
-nvidia 0 \
-maxSessions 10 \
-pricePerUnit 1000 \
-serviceAddr YOUR_PUBLIC_IP:8935
```
Add `-v 6` while getting started for verbose logs (transcoding activity, RPC calls, sessions).
## Choosing the GPU
```bash theme={null}
nvidia-smi -L # list device IDs first
```
```bash theme={null}
-nvidia 0 # single GPU, device 0
-nvidia 0,1 # two GPUs
-nvidia all # all available GPUs
```
Omitting `-nvidia` falls back to CPU transcoding, which is too slow to be competitive. For AI-only
operation you still need `-nvidia` to expose the GPU to AI runner containers, even without
`-transcoder`.
## Setting the session limit
Set `-maxSessions` to the **minimum of your hardware limit and your bandwidth limit**:
```
session limit = min(hardware limit, bandwidth limit)
```
* **Hardware limit** — the highest concurrent session count your GPU sustains at a real-time ratio ≤ 0.8 (benchmark with `livepeer_bench`).
* **Bandwidth limit** — `available symmetric Mbps ÷ 6 Mbps per stream × 0.8 margin`.
Example: hardware limit 12, 100 Mbps bandwidth (\~13) → use `-maxSessions 12`.
`-maxSessions` applies to **video transcoding only**. AI capacity is set per pipeline by the
`capacity` field in `aiModels.json` — see [Add AI inference](/network/guides/orchestrator-add-ai).
## Setting the service address
`-serviceAddr` is how the network finds you. Common mistakes that silently cost you all your jobs:
* using an internal IP (`192.168.x.x`, `10.x.x.x`) — not routable from the internet
* using `0.0.0.0` — binds locally but isn't a network address
* changing the IP without updating on-chain registration — gateways lose contact
Prefer a **domain name** (`orch.yourdomain.com:8935`): if the server IP changes, you update DNS
instead of paying for a new on-chain registration transaction.
## Deployment modes
| Mode | Flags | Use when |
| -------------------------- | ----------------------------------- | -------------------------------------------------------------------- |
| **Combined** (most common) | `-orchestrator -transcoder` | One machine handles everything |
| **Orchestrator-only** | `-orchestrator` | Remote transcoders connect via `-orchSecret` |
| **Transcoder-only** | `-transcoder -orchAddr ` | Running a GPU worker that reports to a separate orchestrator process |
In a split (O-T) setup, add `-reward=false` to **all transcoder** processes — only the orchestrator
process should call `reward()`. Also drop `-ethUrl` from transcoders sharing the wallet so they
don't submit on-chain transactions.
## Run it as a service
For production, supervise the process so it restarts on failure. A minimal `systemd` unit:
```ini title="/etc/systemd/system/livepeer.service" theme={null}
[Unit]
Description=Livepeer Orchestrator
After=network.target
[Service]
Type=simple
User=ubuntu
ExecStart=/usr/local/bin/livepeer \
-network arbitrum-one-mainnet \
-ethUrl https://arb-mainnet.g.alchemy.com/v2/YOUR_API_KEY \
-orchestrator -transcoder -nvidia 0 \
-maxSessions 10 -pricePerUnit 1000 \
-serviceAddr YOUR_PUBLIC_IP:8935
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
```
```bash theme={null}
sudo systemctl daemon-reload && sudo systemctl enable --now livepeer
journalctl -u livepeer -f
```
## Next
Fund the wallet, stake LPT, and register on-chain.
Price so gateways actually select your node.
# Monitor your orchestrator
Source: https://docs.livepeer.org/network/guides/orchestrator-monitor
Expose Prometheus metrics, stand up a dashboard, watch the signals that affect earnings, and catch failures before they cost you jobs or rewards.
A running node isn't the same as a *healthy* one. Missed reward calls, a saturated GPU, or an
unredeemed-ticket backlog quietly cost you income and gateway reputation. This guide instruments your
orchestrator so you see problems before they show up in your earnings.
Logs explain individual incidents; **metrics** show whether throughput, latency, capacity, and
ticket flow are trending the right way. You want both.
## 1. Enable metrics
`go-livepeer` exposes a Prometheus endpoint when you start it with `-monitor`:
```bash theme={null}
livepeer \
-orchestrator -transcoder \
-monitor \
-metricsPerStream \
-network arbitrum-one-mainnet \
# ...your other flags
```
The metrics are served at **`http://localhost:7935/metrics`** — the same port as the go-livepeer CLI;
`-monitor` just activates the `/metrics` path on it.
| Flag | What it does |
| ------------------- | ------------------------------------------------------------------------------------ |
| `-monitor` | Enables `/metrics`. Required for any Prometheus scraping. |
| `-metricsPerStream` | Breaks performance metrics out per stream — useful for diagnosing a single session. |
| `-metricsClientIP` | Adds the client IP to metric labels, so you can see which gateway is routing to you. |
In a split orchestrator/transcoder setup, pass `-monitor` on **both** processes — each exposes its
own `/metrics` on its own CLI port.
## 2. Stand up a dashboard
Livepeer maintains an image bundling Prometheus, Grafana, and starter dashboards:
```bash theme={null}
docker pull livepeer/monitoring
docker run --net=host \
--env LP_MODE=standalone \
--env LP_NODES=localhost:7935 \
livepeer/monitoring:latest
```
Then open Grafana at `http://localhost:3000` (default login `admin` / `admin`). For multiple
nodes, pass a comma-separated list: `LP_NODES=node1:7935,node2:7935`. `LP_MODE` also supports
`docker-compose` and `kubernetes`. Source and dashboards:
[livepeer/livepeer-monitoring](https://github.com/livepeer/livepeer-monitoring).
Already running Prometheus? Add the node as a scrape target:
```yaml theme={null}
# prometheus.yml
scrape_configs:
- job_name: 'livepeer-orchestrator'
static_configs:
- targets: ['localhost:7935']
scrape_interval: 15s
metrics_path: /metrics
```
Reload with `kill -HUP ` or the reload API at `http://localhost:9090/-/reload`.
Add **Node exporter** (host) and the **NVIDIA DCGM exporter** (GPU) for full hardware coverage.
## 3. Watch the signals that matter
Monitor across five layers — the last two are where money is won or lost:
| Layer | What to watch | How |
| --------------- | ------------------------------------------------- | ----------------------------------------- |
| **Hardware** | GPU utilization, VRAM, temperature | `nvidia-smi`, DCGM exporter |
| **Application** | Segment / job success rate, session capacity | `/metrics`, dashboard |
| **Network** | Latency, packet loss | host monitoring |
| **On-chain** | Active-set status, bonded stake, **reward calls** | [Explorer](https://explorer.livepeer.org) |
| **Economics** | ETH fees, LPT rewards | Explorer, `/metrics` |
The metrics you'll actually act on:
| Metric | Signal |
| -------------------------------------------------------------------- | ------------------------------------------------------------------- |
| `livepeer_current_sessions_total` vs `livepeer_max_sessions` | How close to capacity you are (idle → lower price; maxed → add GPU) |
| `livepeer_segment_processed_total` / `livepeer_segment_errors_total` | Core transcoding health. Rising errors → gateways deprioritize you |
| `livepeer_transcode_latency_seconds` | GPU saturation or a slow pipeline — both hurt gateway scoring |
| Winning tickets received vs redeemed | A growing gap means an ETH-balance or redemption problem |
| Round number & reward-call status | Whether you're claiming inflation every round |
The single highest-value alert: **a missed `reward()` call.** Miss a round and that round's LPT is
gone permanently — there's no catch-up. Alert on it, and keep enough ETH on Arbitrum for gas. See
[Activate on Arbitrum](/network/guides/orchestrator-activate#6-confirm-reward-calling).
## 4. Monitor the AI runner (if you serve AI)
AI inference runs in a separate `ai-runner` container, so watch it independently for a faster signal:
```bash theme={null}
docker ps --filter name=livepeer-ai-runner # status
docker logs -f livepeer-ai-runner # live logs
docker stats livepeer-ai-runner # CPU / mem / GPU usage
```
Log lines worth alerting on:
| Message | Meaning |
| ------------------------------- | ----------------------------------------------------------------------- |
| `Loaded model ` | Model is warm in VRAM, ready to process |
| `Error loading model` | Bad model ID or not enough VRAM |
| `CUDA out of memory` | VRAM exhausted — lower `capacity` in `aiModels.json` or the model count |
| `Container health check failed` | Alive but not responding |
Confirm your pipelines are actually advertised to the network:
```bash theme={null}
curl http://localhost:7935/getNetworkCapabilities | jq
```
Cross-check network-wide at [tools.livepeer.cloud/ai/network-capabilities](https://tools.livepeer.cloud/ai/network-capabilities).
## 5. Capture logs
By default logs go to stdout only. For a production node, persist them and know the two debug levers:
```bash theme={null}
# Keep a log file while still printing to the terminal
livepeer -orchestrator -transcoder -monitor ... 2>&1 | tee /var/log/livepeer/livepeer.log
# -v 6 prints per-segment activity — the fastest way to confirm you're receiving work
livepeer -orchestrator -transcoder -v 6 ...
```
```bash theme={null}
grep -i "reward" /var/log/livepeer/livepeer.log # confirm reward calls are happening
```
## Also on the Explorer
Even without a metrics stack, [explorer.livepeer.org](https://explorer.livepeer.org) shows your
active-set status, bonded and delegated LPT, reward-call history, fee earnings, and historical
performance — the fastest external gut-check that your node is healthy and earning.
## Related
The flags these metrics reflect — sessions, GPUs, pricing.
Reward calling and the ETH balance your alerts depend on.
When the dashboard says idle, work through the four causes.
VRAM and session-limit context for capacity metrics.
# Set competitive pricing
Source: https://docs.livepeer.org/network/guides/orchestrator-pricing
Price video and AI work so gateways select you — without leaving money on the table or pricing yourself out.
Price is one of the strongest levers on whether gateways send you jobs. Every gateway filters
orchestrators against its own `-maxPricePerUnit` ceiling, then ranks the rest. Too high and you get
no work; too low and you under-earn per job. This guide covers how to set each price.
## How gateways use your price
Gateways don't assign jobs randomly. For each session they rank orchestrators by **capability match,
price, latency, performance history, and stake weight**. Price is the lever you can change instantly
— and the most common reason an otherwise healthy node receives nothing.
Survey the market before setting anything. Check live per-pixel rates for comparable orchestrators
at [tools.livepeer.cloud](https://tools.livepeer.cloud/ai/network-capabilities) and on the
[Explorer](https://explorer.livepeer.org), then price near or slightly below the going rate.
## Video transcoding price
Set with `-pricePerUnit`, in **wei per pixel** — not ETH.
```bash theme={null}
-pricePerUnit 1000 # a typical starting point is ~500–2,000 wei/pixel
-autoAdjustPrice=true # optional: adjust to network conditions automatically
```
The number-one pricing mistake: entering the value in **ETH** (e.g. `0.0001`) instead of wei. That
prices you orders of magnitude above market, and gateways route around you with no error in your
logs. Remember: 1 ETH = 1,000,000,000,000,000,000 wei.
### Sanity-check the math
You're paid per pixel of video you **encode** — so what a price means in ETH depends on the
renditions a stream asks for. Work one example before you commit to a number. Say a gateway requests
three output renditions at 30 fps:
```
pixels per second = (1280×720 + 854×480 + 640×360) × 30 ≈ 46.9M px/s
pixels per hour ≈ 46.9M × 3600 ≈ 1.69 × 10¹¹ px
at -pricePerUnit 1000 (wei/pixel):
1.69 × 10¹¹ px × 1,000 wei ≈ 1.69 × 10¹⁴ wei ≈ 0.00017 ETH per stream-hour
```
If your own calculation comes out at whole ETH per hour, your price is off by orders of magnitude —
almost always the ETH-instead-of-wei mistake above. (Numbers are illustrative; actual pixel counts
depend on the profiles each gateway requests, and `pixelsPerUnit` defaults to `1`.)
## AI capability price
AI is priced **per pipeline and per model** in `aiModels.json` via the `price_per_unit` field (wei
per unit). Example:
```json theme={null}
{
"capabilities_prices": [
{ "pipeline": "text-to-image", "model_id": "stabilityai/stable-diffusion-3-medium-diffusers", "price_per_unit": 4768371, "pixels_per_unit": 1 },
{ "pipeline": "audio-to-text", "model_id": "openai/whisper-large-v3", "price_per_unit": 15000, "pixels_per_unit": 1 }
]
}
```
Each pipeline/model pair is advertised and priced independently, so you can be aggressive on
workloads your hardware runs efficiently and conservative on the rest.
## Per-gateway pricing
Commercial orchestrators can negotiate a different rate with a specific high-volume gateway,
independent of the base network price:
```bash theme={null}
-pricePerGateway='{"0xGatewayAddress": 800}'
```
## Updating price on a running node
You can change price two ways:
* **Live, via `livepeer_cli`** — select the update-price option and enter a new wei value. No restart.
* **On restart** — change the `-pricePerUnit` flag.
`-pricePerUnit` sets the **startup** price. The on-chain price used for discovery is set during
activation and can be adjusted separately in `livepeer_cli`. Keep them consistent so gateways see
what you intend to charge.
## A sensible starting strategy
1. **Survey** current rates for orchestrators with similar GPUs.
2. **Match or slightly undercut** the median to start attracting sessions.
3. **Watch job flow** in your logs and on the Explorer for a few rounds.
4. **Raise gradually** once you have steady work and reliable performance — reputation and low latency let you command more.
## Next
How fee revenue splits with your delegators.
Price is one of four common causes — check them all.
# Serve real-time AI
Source: https://docs.livepeer.org/network/guides/orchestrator-realtime-ai
Configure your orchestrator for the live-video-to-video (Cascade) pipeline: ComfyStream, the live-base runner, and continuous frame processing.
Real-time AI is Livepeer's flagship workload — the **`live-video-to-video`** pipeline (also called
**Cascade**) that powers live style transfer and generative video apps like Daydream. Unlike
[batch AI](/network/guides/orchestrator-add-ai), your node doesn't answer discrete requests: it
continuously transforms a live WebRTC stream, **frame by frame, with a \~33 ms budget per frame at
30 fps.**
This guide assumes a working orchestrator (see the [tutorial](/network/tutorials/run-your-first-orchestrator))
and familiarity with [batch AI setup](/network/guides/orchestrator-add-ai) — the flags are the same;
the runner, models, and hardware bar are not.
## How it differs from batch AI
| | Batch AI | Real-time AI (Cascade) |
| -------------- | --------------------------------- | ---------------------------------------------------- |
| Input / output | Discrete request → result | Continuous WebRTC stream in → transformed stream out |
| Latency target | Seconds per request | **\< 100 ms per frame** |
| Runner image | `livepeer/ai-runner` | `livepeer/ai-runner:live-base` |
| Models | Standard diffusion, Whisper, BLIP | StreamDiffusion, ComfyUI DAGs, ControlNet |
| Min VRAM | 4–24 GB by pipeline | **24 GB recommended** |
GPUs below 24 GB VRAM (RTX 3080 10 GB, RTX 3060 12 GB) are typically insufficient — model weights,
ComfyStream overhead, and frame buffers exhaust VRAM. **RTX 4090 strongly recommended**; RTX 3090
works with less headroom; A100/H100 for production multi-stream. You'll also want 8+ CPU cores
(frame encode/decode is CPU-bound) and a low-latency, low-jitter connection — WebRTC punishes
packet loss.
## The moving parts
Your orchestrator receives a WebRTC stream from a gateway, hands it to the AI runner, and streams
processed frames back:
```
Gateway → go-livepeer AI worker → ai-runner:live-base (ComfyStream)
→ frame loop: receive → inference → emit → processed stream back
```
**[ComfyStream](https://github.com/livepeer/comfystream)** is the runtime inside the container — it
wraps ComfyUI's node-based workflows for continuous processing: WebRTC frame ingestion, an async
frame queue, and warm-model management. **[StreamDiffusion](https://github.com/cumulo-autumn/StreamDiffusion)**
is the primary model family, purpose-built for live inference (30+ fps on an RTX 4090) via frame
batching, reduced-step sampling, and skipping near-identical frames.
## Set it up
```bash theme={null}
nvidia-smi
docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi
```
Both must show your GPU. CUDA 12.0+ and the NVIDIA Container Toolkit are required.
```bash theme={null}
docker pull livepeer/ai-runner:live-base
```
This is a **separate image** from the batch `livepeer/ai-runner` — it bundles ComfyStream and its
dependencies.
Add a `live-video-to-video` entry:
```json theme={null}
[
{
"pipeline": "live-video-to-video",
"model_id": "streamdiffusion",
"price_per_unit": 500,
"warm": true
}
]
```
For live pipelines, `model_id` names the **ComfyUI workflow/pipeline**, not a Hugging Face model —
the models load inside the ComfyStream container. Your `price_per_unit` must be at or below the
gateway's `-maxPricePerCapability` for this pipeline — a hard filter, regardless of your hardware.
Weights must exist before the container starts:
```bash theme={null}
git clone https://github.com/livepeer/comfystream
cd comfystream
pip install -r requirements.txt
python scripts/download_models.py
```
Download into the directory your node exposes via `-aiModelsDir`.
The same three flags as batch AI — `-aiWorker`, `-aiModels`, `-aiModelsDir` — with your live
entry in `aiModels.json`. Run with `-v 6` initially to watch frame-loop activity in the logs.
Your node should appear under **live-video-to-video** with *Warm* status at
[tools.livepeer.cloud/ai/network-capabilities](https://tools.livepeer.cloud/ai/network-capabilities).
Test end-to-end with the utilities in the [ComfyStream repo](https://github.com/livepeer/comfystream).
## Tuning for the frame budget
Everything about Cascade operation is a fight for milliseconds:
* **Keep models warm.** A cold model load mid-stream is a dropped stream. `"warm": true` is not optional here.
* **Trade steps for latency.** StreamDiffusion workflows run at inference steps as low as `2`; quality vs latency is tunable in the workflow definition.
* **Watch VRAM headroom.** Frame buffers ride on top of model weights — a node that fits batch models exactly will OOM on live streams.
* **Dedicate the GPU.** Sharing a Cascade GPU with transcoding or batch AI undermines the latency that gets you selected.
## Going further
Operators who want custom live pipelines (beyond ComfyUI workflows) can implement the AI runner's
Python `Pipeline` interface and package it as an image extending `ai-runner:live-base` — see the
[ai-runner docs](https://github.com/livepeer/ai-runner) and the
[Pipeline interface](https://github.com/livepeer/ai-runner/blob/main/runner/src/runner/live/pipelines/interface.py).
Note that custom pipelines currently require small upstream additions (the pipeline registry is a
static mapping); a dynamic plugin architecture is in progress.
## Related
The batch pipelines — start here if you haven't run AI yet.
VRAM requirements across workloads.
Watch the AI runner container and frame latency.
Price per capability, and gateway price caps.
# Submit a protocol LIP
Source: https://docs.livepeer.org/network/guides/submit-a-protocol-lip
Propose a change to the Livepeer protocol itself: draft a Livepeer Improvement Proposal, shepherd it through review, and submit it on-chain.
This guide is for changing the **protocol's on-chain rules** — inflation parameters, a contract
upgrade, or a protocol constant. Those changes are made through a **Livepeer Improvement Proposal
(LIP)**, Livepeer's equivalent of an Ethereum EIP. It's a specialized, technical task; for the
concepts, see [Governance & the treasury](/network/explanation/governance).
A protocol LIP changes how the protocol works. If instead you want to **request funding** from the
treasury, that's the other track — see [Submit a treasury proposal](/network/guides/submit-a-treasury-proposal).
The on-chain vote is the same for both; the preparation is not.
## Before you start
* A change to the protocol you can specify precisely — the affected contract/parameter and the intended effect.
* Enough technical detail for a **full specification** (and, for a contract change, an implementation plan).
* **100 LPT** to submit on-chain — locked during the vote, returned if the proposal passes.
* A little ETH on **Arbitrum One** for gas.
## Propose a LIP
Post the idea on the [Livepeer Forum](https://forum.livepeer.org/c/lips/18) or Discord. Most ideas
are refined or dropped here — the forum is where the early technical feedback happens.
Write a structured LIP: a header preamble (number, title, author, type, status) and a full
specification. Open it as a pull request against the [LIPs repository](https://github.com/livepeer/LIPs)
for editorial review.
Once editors approve the draft, it enters a **10-day Last Call** — the community's final window to
surface objections before it moves to a vote.
Anyone with **100 LPT** can submit the LIP on-chain to the Governor contract. The 100 LPT is locked
during voting and returned if it passes — a threshold high enough to filter serious proposals from
frivolous ones.
An on-chain voting window opens — **10 rounds (\~9 days)** as verified on-chain (see [Protocol parameters](/network/reference/protocol-parameters)
for the current length). Anyone with bonded LPT can vote; this is the [same vote](/network/guides/vote-on-a-proposal)
used for every proposal.
It passes only if **≥33% of all bonded LPT participates** (quorum) **and** **>50% of votes cast are
For**. Both are required — either alone isn't enough.
On success, the Governor contract executes the change automatically — a parameter update or a
contract upgrade. No separate signer, no multisig.
## What a strong LIP has
The 100 LPT threshold filters noise, but passing quorum takes substance:
* **A precise specification** — exactly which contract/parameter changes, and to what.
* **An implementation plan** for any contract change — reviewers need to see it's buildable and safe.
* **Economic and security analysis** — what the change does to incentives and to the protocol's safety.
* **Community buy-in** — a LIP that skipped forum discussion and Last Call rarely clears quorum.
## Related
Why governance is on-chain, what it can change, and how the two tracks differ.
The vote step — identical for protocol and treasury proposals.
The other track: requesting funds instead of changing the rules.
Every LIP, draft and final, with full specifications.
# Submit a treasury proposal
Source: https://docs.livepeer.org/network/guides/submit-a-treasury-proposal
Request funding from the Livepeer community treasury: scope and budget, forum RFP, on-chain submission to LivepeerGovernor, and delivery.
This guide is for requesting **funding from the community treasury** — the protocol-owned pool
funded by a cut of LPT inflation (LIP-92; contributions pause at a balance ceiling). It's a specialized task: most stakeholders only ever [vote](/network/guides/vote-on-a-proposal),
while proposals typically come from **Special-Purpose Entities** or teams taking on a defined scope of
work. For the concepts behind all of this, see [Governance & the treasury](/network/explanation/governance).
A treasury proposal is **not** a protocol LIP. It uses a different contract and different
preparation — a budget and deliverable rather than a technical spec. Only the *vote* is shared with
protocol governance. Mixing the two up is the most common mistake new proposers make.
## Before you start
* A concrete **scope of work** and an itemized **budget**.
* A **recipient address** (usually an SPE or team multisig) to receive the LPT.
* **100 LPT** available to submit — it's returned if the proposal passes.
* A little ETH on **Arbitrum One** for gas.
## Submit a proposal
Write exactly what you'll do, over what timeline, with what deliverable. Itemize the budget by
category (engineering, research, infrastructure, communications). Proposals without a defensible,
line-item budget rarely pass.
Publish the proposal as an RFP in the [LIPs category on the forum](https://forum.livepeer.org/c/lips/18).
This is where orchestrators and delegators ask questions, raise concerns, and negotiate scope. A
proposal that hasn't been workshopped here is unlikely to clear quorum.
Iterate on the feedback, then lock the **scope**, the **recipient address**, and the **requested
LPT amount**. Post the final version with a clear "ready for on-chain submission" marker.
Anyone with **100 LPT** can submit the proposal to the [`LivepeerGovernor`](/network/reference/contracts)
contract. The text, recipient, and amount are committed on-chain at this step. Your 100 LPT is
returned if the proposal passes.
An on-chain voting window opens — **10 rounds (\~9 days)** as verified on-chain (see [Protocol parameters](/network/reference/protocol-parameters)
for the current length). Stake-weighted voting decides the outcome under the standard **33% quorum**
and majority-of-votes-cast rules — bonded LPT, with delegator override. This is the same vote
covered in [Vote on a proposal](/network/guides/vote-on-a-proposal).
On a successful vote, `LivepeerGovernor` releases the requested LPT to the recipient address — no
protocol-code change. You're then expected to deliver the scope and report progress publicly.
Treasury funding is a relationship, not a one-time grant.
## What makes a proposal pass
Clearing quorum takes more than favorable votes — passed proposals consistently show:
| Signal | What it looks like |
| ------------------------- | --------------------------------------------------------------------------- |
| **Defensible budget** | Line items, not lump sums; benchmarks where possible |
| **Track record** | Prior public delivery in Livepeer or an adjacent protocol |
| **Concrete deliverables** | Working software, public research, measurable outputs — not "we'll explore" |
| **Ongoing reporting** | Forum threads, dashboards, regular updates |
| **Network alignment** | Strengthens the protocol or network — not a single operator or vendor |
Miss any one and a proposal tends to fail quorum even when the votes it *does* get are favorable.
## Track it
Follow live proposals and treasury balances at
[explorer.livepeer.org/treasury](https://explorer.livepeer.org/treasury).
## Related
Why the treasury exists, what it funds, and how the two proposal tracks differ.
The other track: changing protocol rules instead of requesting funds.
The vote step — identical for treasury and protocol proposals.
LivepeerGovernor and Treasury on Arbitrum One.
Live quorum, proposal threshold, and voting-window values.
# Vote on a proposal
Source: https://docs.livepeer.org/network/guides/vote-on-a-proposal
Cast your bonded stake on any Livepeer proposal — protocol (LIP) or treasury — through the Explorer.
This guide walks through casting a vote on any active proposal — a **protocol change (LIP)** or a
**treasury spend**. It assumes you already hold **bonded LPT** — that's what carries voting weight.
For *why* staking gives you a vote and how the process works end to end, see
[Governance & the treasury](/network/explanation/governance).
**The vote is identical for both proposal types.** Protocol proposals (LIPs) and treasury spends are
prepared and executed differently, but you cast a vote on them the exact same way — same quorum, same
threshold, same bonded-stake weighting. The only practical difference is *where you find them*,
covered in step 1.
## Before you start
* **Bonded LPT.** Only bonded stake can vote; unbonded tokens carry no weight. Not bonded yet? Do [Delegate your first LPT](/network/tutorials/delegate-your-first-lpt) first.
* A wallet you can connect to the [Livepeer Explorer](https://explorer.livepeer.org), on **Arbitrum One**.
* A little ETH on Arbitrum for gas.
Your voting weight is your share of total bonded LPT **at the moment the proposal was created** —
not when you vote. Bonding more after a proposal opens won't increase your weight on it.
## Cast your vote
Both types are voted from the Explorer's voting view —
[explorer.livepeer.org/voting](https://explorer.livepeer.org/voting) — which lists each active
proposal with its current tally and deadline. Treasury proposals are *also* tracked, alongside
treasury balances, at [explorer.livepeer.org/treasury](https://explorer.livepeer.org/treasury). If
you came looking for a specific treasury spend and don't see it under voting, check there.
Read it and its linked material so you understand exactly what executes if it passes — a **protocol
proposal (LIP)** links its [specification](https://github.com/livepeer/LIPs); a **treasury proposal**
links its [forum RFP](https://forum.livepeer.org/c/lips/18) and budget. This is also how you tell
the two types apart at a glance.
Connect the wallet holding your bonded LPT. Confirm you're on **Arbitrum One**.
Cast your vote and sign the transaction. **Abstain** still counts toward quorum without taking a side.
Your vote appears in the proposal tally, weighted by your bonded stake at the snapshot.
## What happens next
A proposal passes only if it clears both thresholds — **33% quorum** (enough bonded stake
participated) and **>50% approval**. If it does, it enters a **timelock** and then executes
automatically; nothing more is required from you. You can watch its status on the Explorer through to
execution.
Delegators who don't vote are effectively represented by their orchestrator's vote — so if you feel
strongly, cast your own. If you'd rather not track proposals, factor an operator's governance stance
into [choosing one](/network/guides/delegator-choose-orchestrator).
## Related
The full picture: who votes, what can change, and how the treasury is funded.
Live quorum, thresholds, voting delay/period, and timelock values.
# Run the Livepeer network
Source: https://docs.livepeer.org/network/index
Everything you need to operate a Livepeer orchestrator or delegate your LPT — and nothing you don't.
Livepeer is a decentralized marketplace for **AI video compute**. Applications send jobs;
GPU operators do the work and get paid. This site covers the two roles on the **supply side** of that
marketplace:
Connect GPUs to the network. Process video transcoding and AI inference jobs, and earn ETH fees plus LPT rewards.
Hold LPT? Bond it to an orchestrator to help secure the network and share in its rewards — no hardware required.
## Start here
A guided, end-to-end walkthrough: from a bare GPU machine to a node that earns on mainnet.
A guided walkthrough: from LPT in your wallet to a confirmed, reward-earning delegation.
**Looking to build on Livepeer instead?** These docs cover *running* the network. A developer
platform — and a Build section of these docs — is on the way. In the meantime, ask in the
[Livepeer Discord](https://discord.gg/livepeer); the team and community can point you at what's
possible today.
## How these docs are organized
The sidebar follows the [Diátaxis](https://diataxis.fr) framework. Each section answers a
different kind of question, so go to the one that matches what you need right now:
| If you want to… | Go to | Example |
| -------------------------------- | ----------------------------------------------------------- | ------------------------------ |
| **Learn by doing**, step by step | [Tutorials](/network/tutorials/run-your-first-orchestrator) | Run your first orchestrator |
| **Accomplish a specific task** | [How-to guides](/network/guides/orchestrator-configure) | Set competitive pricing |
| **Understand how it works** | [Explanation](/network/explanation/orchestrators) | How the network works |
| **Look up an exact value** | [Reference](/network/reference/cli-flags) | CLI flags, protocol parameters |
Network values such as inflation, the unbonding period, the active-set size, and contract
addresses are **governance-controlled and change over time**. Treat the numbers here as a
starting point and verify the live values on the [Livepeer Explorer](https://explorer.livepeer.org)
and on-chain. See [Protocol parameters](/network/reference/protocol-parameters).
# CLI flags
Source: https://docs.livepeer.org/network/reference/cli-flags
The go-livepeer flags orchestrators use most, grouped by purpose, plus how on-chain settings differ from node flags.
This is a working reference for the `go-livepeer` flags an orchestrator uses. It is not exhaustive —
run `livepeer -help` for the complete list, and see [Configure your orchestrator](/network/guides/orchestrator-configure)
for how to choose values.
## Network & identity
| Flag | Value | Purpose |
| -------------- | ---------------------- | ------------------------------------------------------------------------------- |
| `-network` | `arbitrum-one-mainnet` | Network to join (default `offchain` does not participate) |
| `-ethUrl` | RPC URL | Arbitrum One endpoint for on-chain reads/writes |
| `-ethAcctAddr` | ETH address | Orchestrator identity; holds stake, receives fees. Omit to create a new account |
| `-serviceAddr` | `ip:port` | Public address gateways use to reach the node |
| `-dataDir` | path | Where keystore and node data are stored (default `~/.lpData`) |
## Roles
| Flag | Purpose |
| --------------- | -------------------------------------------------------------------- |
| `-orchestrator` | Enable the on-chain protocol role (routing, reward calls, discovery) |
| `-transcoder` | Enable local GPU transcoding |
| `-orchAddr` | (transcoder mode) Address of the orchestrator to connect to |
| `-orchSecret` | Shared secret authenticating remote transcoders to an orchestrator |
## GPU & capacity
| Flag | Value | Purpose |
| -------------- | ----------------- | ---------------------------------------------- |
| `-nvidia` | `0`, `0,1`, `all` | NVIDIA GPU device IDs for transcoding/AI |
| `-maxSessions` | integer | Max concurrent transcode sessions (default 10) |
## Pricing
| Flag | Value | Purpose |
| --------------------- | --------- | ----------------------------------------- |
| `-pricePerUnit` | wei/pixel | Base transcoding price (**wei**, not ETH) |
| `-pixelsPerUnit` | integer | Pricing granularity (usually `1`) |
| `-autoAdjustPrice` | bool | Adjust price to network conditions |
| `-pricePerGateway` | JSON | Per-gateway price overrides |
| `-pricePerCapability` | path | Per-pipeline/model AI pricing (JSON) |
## AI inference
| Flag | Value | Purpose |
| -------------------- | --------- | ------------------------------------------------------- |
| `-aiWorker` | — | Enable the AI worker (without it, AI config is ignored) |
| `-aiModels` | path | Path to `aiModels.json` |
| `-aiModelsDir` | path | Host directory for cached model weights |
| `-aiRunnerImage` | image:tag | AI runner Docker image (pin in production) |
| `-aiServiceRegistry` | — | Register AI capabilities on the AI service registry |
## Rewards & operations
| Flag | Value | Purpose |
| --------- | ----- | --------------------------------------------------------- |
| `-reward` | bool | Call `reward()` automatically each round (default `true`) |
| `-v` | level | Log verbosity (`6` is useful while setting up) |
**Not everything configurable is a flag.** `rewardCut` (block reward cut) and `feeShare` are
**on-chain economic settings** configured via `livepeer_cli` during activation, not node flags.
See [Activate on Arbitrum](/network/guides/orchestrator-activate).
## livepeer\_cli
`livepeer_cli` is an interactive tool that connects to a running node for one-off on-chain actions —
activating as an orchestrator, staking/bonding LPT, updating price, updating the service URI, and
viewing node status. It does **not** need to stay running; only the `livepeer` daemon does.
```bash theme={null}
# Against a Docker node:
docker exec -it livepeer-orchestrator livepeer_cli
```
## Related
How to choose values for these flags.
Common errors and fixes.
# Contract addresses
Source: https://docs.livepeer.org/network/reference/contracts
The Livepeer protocol contracts orchestrators, delegators, and applications interact with, and how to verify any address on-chain.
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.
| Contract | Address | Used by / for |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| `Controller` | [`0xD8E8328501E9645d16Cf49539efC04f734606ee4`](https://arbiscan.io/address/0xD8E8328501E9645d16Cf49539efC04f734606ee4) | Registry that resolves every address below |
| `BondingManager` | [`0x35Bcf3c30594191d53231E4FF333E8A770453e40`](https://arbiscan.io/address/0x35bcf3c30594191d53231e4ff333e8a770453e40) | Stake, bond/unbond, reward & fee cuts |
| `TicketBroker` | [`0xa8bB618B1520E284046F3dFc448851A1Ff26e41B`](https://arbiscan.io/address/0xa8bb618b1520e284046f3dfc448851a1ff26e41b) | Redeem winning payment tickets for ETH |
| `RoundsManager` | [`0xdd6f56DcC28D3F5f27084381fE8Df634985cc39f`](https://arbiscan.io/address/0xdd6f56dcc28d3f5f27084381fe8df634985cc39f) | Round progression; gates the reward call |
| `Minter` | [`0xc20DE37170B45774e6CD3d2304017fc962f27252`](https://arbiscan.io/address/0xc20de37170b45774e6cd3d2304017fc962f27252) | Inflation issuance |
| `ServiceRegistry` | [`0xC92d3A360b8f9e083bA64DE15d95Cf8180897431`](https://arbiscan.io/address/0xc92d3a360b8f9e083ba64de15d95cf8180897431) | Orchestrator service URI for discovery |
| `LivepeerToken` (L2) | [`0x289ba1701C2F088cf0faf8B3705246331cB8A839`](https://arbiscan.io/address/0x289ba1701c2f088cf0faf8b3705246331cb8a839) | The LPT ERC-20 on Arbitrum |
| `LivepeerGovernor` | [`0xcFE4E2879B786C3aa075813F0E364bb5acCb6aa0`](https://arbiscan.io/address/0xcfe4e2879b786c3aa075813f0e364bb5accb6aa0) | Proposals and voting (protocol + treasury) |
| `Treasury` | [`0xf82C1FF415F1fCf582554fDba790E27019c8E8C4`](https://arbiscan.io/address/0xf82c1ff415f1fcf582554fdba790e27019c8e8c4) | Governance-controlled community funds |
| `BondingVotes` | [`0x0B9C254837E72Ebe9Fe04960C43B69782E68169A`](https://arbiscan.io/address/0x0b9c254837e72ebe9fe04960c43b69782e68169a) | Stake snapshots for voting power |
| `MerkleSnapshot` | [`0x10736ffaCe687658F88a46D042631d182C7757f7`](https://arbiscan.io/address/0x10736ffaCe687658F88a46D042631d182C7757f7) | Merkle-proof earnings claims |
| `L2Migrator` | [`0x148D5b6B4df9530c7C76A810bd1Cdf69EC4c2085`](https://arbiscan.io/address/0x148D5b6B4df9530c7C76A810bd1Cdf69EC4c2085) | Arbitrum side of the Confluence migration; unmigrated stake is still claimable |
| `L2LPTDataCache` | [`0xd78b6bD09cd28A83cFb21aFa0DA95c685A6bb0B1`](https://arbiscan.io/address/0xd78b6bD09cd28A83cFb21aFa0DA95c685A6bb0B1) | Caches L1 LPT supply data on Arbitrum |
These Arbitrum One contracts are **not** registered in the Controller. Addresses come from Livepeer's
own deployment artifacts ([livepeer/protocol](https://github.com/livepeer/protocol/tree/delta/deployments/arbitrumMainnet),
[livepeer/arbitrum-lpt-bridge](https://github.com/livepeer/arbitrum-lpt-bridge/tree/main/deployments)),
cross-checked against on-chain state:
| Contract | Address | Used by / for |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| `AIServiceRegistry` | [`0x04C0b249740175999E5BF5c9ac1dA92431EF34C5`](https://arbiscan.io/address/0x04C0b249740175999E5BF5c9ac1dA92431EF34C5) | AI capability registration (`-aiServiceRegistry`) |
| `L2LPTGateway` | [`0x6D2457a4ad276000A615295f7A80F79E48CcD318`](https://arbiscan.io/address/0x6D2457a4ad276000A615295f7A80F79E48CcD318) | Arbitrum side of the canonical LPT bridge |
| `Governor` | [`0xD9dEd6f9959176F0A04dcf88a0d2306178A736a6`](https://arbiscan.io/address/0xD9dEd6f9959176F0A04dcf88a0d2306178A736a6) | Protocol admin / parameter execution (pre-treasury governance) |
| `PollCreator` | [`0x8bb50806D60c492c0004DAD5D9627DAA2d9732E6`](https://arbiscan.io/address/0x8bb50806D60c492c0004DAD5D9627DAA2d9732E6) | Poll-based LIP voting |
## 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**:
| Contract | Address | Used by / for |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| `LivepeerToken` (L1) | [`0x58b6A8A3302369DAEc383334672404Ee733aB239`](https://etherscan.io/address/0x58b6A8A3302369DAEc383334672404Ee733aB239) | The original LPT ERC-20 (2018 genesis deployment) |
| `BridgeMinter` | [`0x8dDDB96CF36AC8860f1DE5C7c4698fd499FAB405`](https://etherscan.io/address/0x8dddb96cf36ac8860f1de5c7c4698fd499fab405) | Owns L1 LPT minting; backs the bridge when escrow is short |
| `L1Escrow` | [`0x6A23F4940BD5BA117Da261f98aae51A8BFfa210A`](https://etherscan.io/address/0x6A23F4940BD5BA117Da261f98aae51A8BFfa210A) | Holds all L1 LPT locked into the bridge |
| `L1LPTGateway` | [`0x6142f1C8bBF02E6A6bd074E8d564c9A5420a0676`](https://etherscan.io/address/0x6142f1C8bBF02E6A6bd074E8d564c9A5420a0676) | Ethereum side of the canonical LPT bridge |
| `L1LPTDataCache` | [`0x1d24838b35A9c138Ac157A852e19e948aD6323D7`](https://etherscan.io/address/0x1d24838b35A9c138Ac157A852e19e948aD6323D7) | Publishes L1 LPT supply data to Arbitrum |
| `L1Migrator` (V2) | [`0x2a69191B43c9DB47C927bD7287F9C93838d07759`](https://etherscan.io/address/0x2a69191B43c9DB47C927bD7287F9C93838d07759) | L1→L2 state migration (Confluence, 2022) |
**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`](https://etherscan.io/address/0xf96d54e490317c557a967abfa5d6e33006be69b3)
(`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](https://github.com/livepeer/protocol/tree/streamflow).
## 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:
```bash theme={null}
# Example: resolve the BondingManager proxy address
cast call 0xD8E8328501E9645d16Cf49539efC04f734606ee4 \
"getContract(bytes32)(address)" \
$(cast keccak "BondingManager") \
--rpc-url https://arb1.arbitrum.io/rpc
```
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](https://arbiscan.io/accounts/label/livepeer) or
[Blockscout](https://arbitrum.blockscout.com): 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](https://webencrypt.org/onlinetoolsjs/keccak_256.html) 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](https://arbiscan.io/address/0xD8E8328501E9645d16Cf49539efC04f734606ee4#readContract#F1) (or via `cast`, as above).
The returned address is the live implementation behind that proxy.
## Canonical sources
The deployed contract code (commit-pinned).
On-chain verified contract labels.
## Related
Governance values read from these contracts.
What each contract does in the job and reward flow.
# FAQ & troubleshooting
Source: https://docs.livepeer.org/network/reference/faq
Fixes for the most common orchestrator errors, plus answers to frequent orchestrator and delegator questions.
Find your symptom or question below. Each entry is self-contained.
## Orchestrator: not receiving jobs
This is the most common question after activation. There are four distinct causes — work through all
of them before concluding the network is at fault.
Gateways only route to the top orchestrators by total LPT stake (self + delegated). If your stake
is below the 100th orchestrator's, you won't receive jobs. Find the current threshold on the
[Explorer](https://explorer.livepeer.org), then increase your stake (self-bond more, or attract
delegators with a competitive `rewardCut`) and re-activate via `livepeer_cli` if needed.
Gateways select on stake **and** price. If your price is well above market, jobs go elsewhere with
no error in your logs. `-pricePerUnit` is **wei per pixel** — a common mistake is entering an ETH
value (e.g. `0.0001`), which is orders of magnitude too high. Check market rates at
[tools.livepeer.cloud](https://tools.livepeer.cloud) and update via `livepeer_cli`. See
[Set pricing](/network/guides/orchestrator-pricing).
Running in orchestrator mode does **not** auto-register the node. Activation is a one-time on-chain
step: run `livepeer_cli`, choose the multi-step "become an orchestrator" flow, set your cuts,
price, service address, and stake. Each step is an on-chain transaction needing ETH for gas.
Gateways read your address from the chain but can't connect. Open port `8935/tcp` in your firewall
(`sudo ufw allow 8935/tcp`), configure NAT/port-forwarding or cloud security groups, then verify
from another machine: `curl -k https://YOUR_PUBLIC_IP:8935/status`. Any response means it's
reachable. If your IP changed, update the service URI in `livepeer_cli` (costs gas) — or register
a domain name instead of a bare IP.
## Orchestrator: installation & GPU
The driver is below the minimum, or (in Docker) the NVIDIA Container Toolkit isn't installed.
Check `nvidia-smi` for the driver version; update if needed. For Docker, verify with
`docker run --gpus all nvidia/cuda:12.0-base nvidia-smi`, and install the toolkit if it fails:
`sudo apt-get install -y nvidia-container-toolkit && sudo systemctl restart docker`.
The node hit its session limit. Raise `-maxSessions`, or if it appears at startup with `-nvidia`,
the GPU itself hit its hardware NVENC session cap (consumer cards cap at 3–5). See the
[NVENC limits table](/network/reference/hardware#nvenc-session-limits).
Confirm `-ethUrl` is an **Arbitrum One** endpoint (chain ID `0xa4b1`), not Ethereum L1. Test it
with an `eth_chainId` call. If rate-limited, switch providers or upgrade the plan; check the API
key hasn't expired.
Your current public IP differs from the address registered on-chain. Update the service URI in
`livepeer_cli`, or override locally with `-serviceAddr YOUR_PUBLIC_IP:8935`. Use a domain name to
avoid this when your IP changes.
## Orchestrator: AI pipelines
Usually the NVIDIA Container Toolkit isn't configured, the GPU lacks VRAM for the model, the image
tag doesn't match the go-livepeer version, or a host port conflicts. Check `docker logs `.
For OOM, load a smaller model or use a higher-VRAM GPU.
If go-livepeer can't load a valid config it won't advertise AI capabilities. Verify the JSON is
well-formed, `model_id` matches a Livepeer-verified Hugging Face model, the runner is reachable
(`curl http://localhost:8000/health`), and **restart** — `aiModels.json` is not hot-reloaded.
Multiple warm models add up. Set some to `"warm": false` to load on demand, or enable `SFAST`
optimization to reduce VRAM. Don't combine `SFAST` and `DEEPCACHE`, and avoid `DEEPCACHE` on
Lightning/Turbo models.
## Orchestrator: earnings
In a split O-T setup, only the **orchestrator** process should call `reward()` — add `-reward=false`
to all transcoder processes (and drop `-ethUrl` from transcoders sharing the wallet). Ensure the
wallet has enough ETH for gas. A combined node handles reward calls automatically.
Explorer indexing can lag minutes to hours (allow up to 24h for new nodes). LPT rewards only mint
if a reward call was made that round. Confirm you're on Arbitrum One, not a testnet.
## General questions
An **orchestrator** is the on-chain participant — it holds staked LPT, is registered, receives
routing, sets pricing, and calls rewards. A **transcoder** is a compute process that does the
actual encoding/inference and has no on-chain identity. Most solo setups run both in one process
with `-orchestrator -transcoder`.
There's no fixed minimum. The active set is the top 100 by total stake; the effective minimum is
the 100th orchestrator's stake, which moves over time. Check the [Explorer](https://explorer.livepeer.org).
Yes for **video transcoding**. **AI inference requires Linux** (AI runner containers, aiModels.json).
Possible, but you must port-forward `8935`, handle dynamic IPs (use dynamic DNS), and have enough
upload bandwidth. A VPS or data center is strongly recommended for production.
No — one bonded position per wallet maps to one orchestrator. Use separate wallets to split.
Not from switching itself — earnings stay attributed to your position. The risk is **timing**:
claiming or moving before your orchestrator calls `reward()` for the round can skip that round.
See [Manage your delegation](/network/guides/delegator-manage).
## Still stuck?
The most active real-time support. Search before posting.
Longer-form troubleshooting.
Confirmed bugs in go-livepeer.
# Glossary
Source: https://docs.livepeer.org/network/reference/glossary
The Livepeer-specific terms used throughout these orchestrator and delegator docs.
## Roles & network
**Orchestrator** — A GPU operator that runs `go-livepeer`, executes video and AI jobs, and earns ETH
fees plus LPT rewards. The on-chain participant that holds staked LPT.
**Transcoder** — The compute process that performs video encoding (or, via the AI runner, inference).
Has no on-chain identity; runs in-process or split out from the orchestrator.
**Delegator** — An LPT holder who bonds tokens to an orchestrator to share in its rewards without
running hardware.
**Gateway** — The demand-side node that aggregates application requests, selects orchestrators, and
pays for work. Out of scope for these docs, but it's what sends you jobs.
**Active set** — The top orchestrators by total bonded stake (commonly 100) eligible to receive jobs
and inflation rewards in a round.
## Staking & economics
**LPT** — The Livepeer Token. A work/coordination token used for staking, rewards, and governance —
**not** used to pay for jobs (that's ETH).
**Bond / Bonding** — Attributing your LPT stake to an orchestrator. Tokens stay in the
`BondingManager` contract; the operator never takes custody.
**Unbond / Unbonding period** — Starting a full exit. After unbonding you must wait the unbonding
period (currently 7 rounds) before withdrawing. **Rebond** cancels it.
**Redelegate** — Move bonded stake to a different orchestrator without the unbonding wait.
**Reward cut (`rewardCut`)** — The % of LPT inflation an orchestrator keeps; the rest goes to
delegators. Lower is better for delegators.
**Fee share (`feeShare`)** — The % of ETH fees an orchestrator passes to delegators. Higher is better
for delegators.
**Reward call (`reward()`)** — The once-per-round on-chain call that mints an orchestrator's
inflation reward. Missing it forfeits that round for the whole pool, with no catch-up.
**Claim earnings (`claimEarnings()`)** — Checkpointing accrued rewards into your bonded balance.
Timing relative to the reward call matters.
**Inflation** — New LPT minted each round and distributed to bonded stake. The rate adjusts toward a
target bonding rate (\~50%).
**Treasury** — An on-chain fund for community/public-goods spending, governed by proposal. Funded by
a cut of LPT inflation (LIP-92 set 10%, with a balance ceiling that pauses contributions when full).
## Payments
**Probabilistic micropayment (PM) ticket** — How gateways pay. Each ticket has a face value and a win
probability; orchestrators redeem only winning tickets on-chain for ETH. Expected earnings = face
value × win probability.
**Round** — The protocol's accounting unit (\~1 day). Governs active-set election, inflation, reward
calls, and governance snapshots.
## Infrastructure
**NVENC / NVDEC** — NVIDIA's hardware video encoder/decoder used for transcoding. Consumer GPUs cap
concurrent NVENC sessions.
**AI runner** — A Docker container that performs AI inference for a configured pipeline/model, spawned
and managed by the orchestrator process.
**Pipeline** — A category of AI task (e.g. `text-to-image`, `audio-to-text`, `llm`) mapped to
compatible models. Configured in `aiModels.json`.
**Service URI / `serviceAddr`** — The public address gateways use to reach an orchestrator, stored
on-chain via the ServiceRegistry.
## Related
See these terms in context.
The live values behind these concepts.
# Hardware & GPU support
Source: https://docs.livepeer.org/network/reference/hardware
NVIDIA GPU compatibility, NVENC session limits, VRAM requirements by workload, and driver versions for orchestrators.
Livepeer orchestrators use **NVIDIA** GPUs for video transcoding (NVENC/NVDEC) and AI inference
(CUDA / Tensor cores). **AMD and Intel GPUs are not supported.**
## Supported GPUs
| GPU family | Transcoding | AI inference | Notes |
| ------------------------- | ----------- | ------------ | ---------------------------------------------------------- |
| GeForce RTX 40xx (Ada) | Yes | Yes | Best consumer option; AV1 encode |
| GeForce RTX 30xx (Ampere) | Yes | Yes | Widely used; good price/performance |
| GeForce RTX 20xx (Turing) | Yes | Yes | Supported but older |
| GeForce GTX 16xx (Turing) | Yes | Limited | No Tensor cores — AI slower/unsupported for some pipelines |
| GeForce GTX 10xx (Pascal) | Yes | Limited | Legacy; NVENC Gen 6; no Tensor cores |
| Tesla T4 | Yes | Yes | Data center, 16 GB, common in cloud |
| Tesla V100 | Yes | Yes | Data center, 16/32 GB |
| A100 | Yes | Yes | Data center, 40/80 GB, highest throughput |
| A10 / A10G | Yes | Yes | Cloud-optimized (AWS G5), 24 GB |
| L4 | Yes | Yes | Ada data center, 24 GB, good for AI |
| L40 / L40S | Yes | Yes | 48 GB, high-end AI + transcoding |
| H100 | Overkill | Yes | 80 GB, primarily LLM / large-model inference |
## NVENC session limits
Consumer GPUs cap concurrent NVENC encode sessions, which limits simultaneous transcode streams per
GPU.
| GPU class | Default NVENC sessions | |
| ------------------------- | ---------------------- | ---------------- |
| GeForce GTX 10xx | 2 | Can be patched |
| GeForce GTX 16xx | 3 | Can be patched |
| GeForce RTX 20xx | 3 | Can be patched |
| GeForce RTX 30xx | 3–5 (by model) | Can be patched |
| GeForce RTX 40xx | 3–8 (by model) | Can be patched |
| Tesla / Quadro / A-series | Unlimited | No session limit |
The community [nvidia-patch](https://github.com/keylase/nvidia-patch) removes the limit on consumer
GPUs and is widely used by orchestrators.
Patching modifies a system binary, is unsupported by NVIDIA, must be re-applied after driver
updates, and may be disallowed on some managed cloud GPU instances.
## VRAM by workload
| Workload | Minimum VRAM | Recommended | Notes |
| ------------------------------- | ------------ | ----------- | ---------------------------------------------- |
| Video transcoding only | 4 GB | 8 GB | NVENC/NVDEC uses minimal VRAM |
| Batch AI (single warm model) | 8 GB | 16 GB | SDXL needs \~7 GB |
| Batch AI (multiple warm models) | 16 GB | 24 GB+ | Each warm model consumes VRAM simultaneously |
| LLM inference (quantized) | 8 GB | 16 GB | Via Ollama runner, quantized weights |
| LLM inference (full precision) | 24 GB+ | 48 GB+ | Large models at full precision |
| Real-time AI (ComfyStream) | 12 GB | 16 GB+ | Latency-sensitive; headroom improves stability |
## Driver & toolkit versions
| Component | Minimum | Notes |
| ------------------------ | ------- | ----------------------------------------------------------- |
| NVIDIA driver | 525+ | |
| CUDA toolkit | 12.0+ | |
| NVIDIA Container Toolkit | Latest | Required for Docker (AI runner, containerized orchestrator) |
```bash theme={null}
nvidia-smi # driver version
nvcc --version # CUDA version
docker run --gpus all nvidia/cuda:12.0-base nvidia-smi # Docker GPU access
```
## GPU selection guidance
| Goal | Pick |
| ------------------------ | ---------------------------------------------------------------------------------------- |
| Transcoding only, budget | GTX 1660 Super (6 GB); patch the NVENC limit for more sessions |
| Transcoding + AI | RTX 4070 Ti Super (16 GB) or RTX 3090 (24 GB) — 24 GB runs 2–3 warm models + transcoding |
| AI-heavy / LLM | RTX 4090 (24 GB), or A100 / L40S in a data center |
## Related
GPU selection and session-limit flags.
Match a pipeline to your available VRAM.
# Protocol parameters
Source: https://docs.livepeer.org/network/reference/protocol-parameters
Governance-controlled values that shape orchestrator and delegator behavior — verified on-chain, with the exact getters to re-check them.
These values are **governance-controlled**. They can change without a docs release if governance
updates them on-chain.
**Last verified: 1 July 2026**, read directly from the contracts on Arbitrum One
(`eth_call` via `arb1.arbitrum.io/rpc`, round `4253`). Anything can have changed since — the
getters below let you re-check in seconds.
## Staking & rewards
| Parameter | Verified value | Getter | Why it matters |
| ------------------------- | ------------------------------------------------------ | ------------------------------------------- | ---------------------------------------------------------------------- |
| Unbonding period | `7` rounds | `BondingManager.unbondingPeriod()` | Full exit is delayed this long after you unbond |
| Active set size | `100` orchestrators | `BondingManager.getTranscoderPoolMaxSize()` | Only the top 100 by stake earn rewards and receive jobs |
| Treasury reward cut | `0%` — **paused** (see below) | `BondingManager.treasuryRewardCutRate()` | When active, reduces the issuance shared by orchestrators + delegators |
| Treasury balance ceiling | `750,000 LPT` | `BondingManager.treasuryBalanceCeiling()` | Contributions pause when the treasury reaches this balance |
| Target bonding rate | `50%` | `Minter.targetBondingRate()` | Inflation adjusts around this target |
| Inflation adjustment step | `500` (per round, parts-per-billion) | `Minter.inflationChange()` | How fast inflation moves toward the target |
| Current inflation | `560,500` parts-per-billion per round (\~0.056%/round) | `Minter.inflation()` | Changes every round — always read live |
| Round length | `6,377` L1 blocks (\~21.3 hours) | `RoundsManager.roundLength()` | The protocol's clock; "a round ≈ a day" is shorthand |
**The treasury cut is currently paused.** LIP-92 set a 10% treasury reward cut with a balance
ceiling; the ceiling has been reached, so both `treasuryRewardCutRate()` and
`nextRoundTreasuryRewardCutRate()` currently read `0`. Older docs (including Livepeer's own) still
say "10%" — treat that as the *design*, not the live state. Governance can resume contributions.
## Governance thresholds
| Parameter | Verified value | Getter |
| ---------------------- | ------------------------ | ------------------------------------------------------------------------------- |
| Proposal threshold | `100 LPT` bonded | `LivepeerGovernor.proposalThreshold()` |
| Quorum | `33.33%` of voting power | `LivepeerGovernor.quorumNumerator()` / `quorumDenominator()` (333300 / 1000000) |
| Voting delay | `1` round | `LivepeerGovernor.votingDelay()` |
| Voting period | `10` rounds (\~9 days) | `LivepeerGovernor.votingPeriod()` |
| Timelock minimum delay | `0` | `Treasury.getMinDelay()` |
Some public Livepeer guides describe a "30-round (\~3.75 days)" voting window. The chain says
otherwise: `votingPeriod()` returns `10`, and at \~21.3h per round that's roughly nine days. The
same window applies to both protocol and treasury proposals.
## Verify these yourself
Every value above is one `eth_call` away — no tooling beyond `curl` required. Example, reading the
voting period:
```bash theme={null}
# votingPeriod() on LivepeerGovernor — selector 0x02a251a3
curl -s -X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0xcFE4E2879B786C3aa075813F0E364bb5acCb6aa0","data":"0x02a251a3"},"latest"],"id":1}' \
https://arb1.arbitrum.io/rpc
# → 0x...0a = 10 rounds
```
Or browse the contracts directly:
* [BondingManager on Arbiscan](https://arbiscan.io/address/0x35bcf3c30594191d53231e4ff333e8a770453e40)
* [Minter on Arbiscan](https://arbiscan.io/address/0xc20de37170b45774e6cd3d2304017fc962f27252)
* [RoundsManager on Arbiscan](https://arbiscan.io/address/0xdd6f56dcc28d3f5f27084381fe8df634985cc39f)
* [LivepeerGovernor on Arbiscan](https://arbiscan.io/address/0xcfe4e2879b786c3aa075813f0e364bb5accb6aa0)
* [Treasury on Arbiscan](https://arbiscan.io/address/0xf82c1ff415f1fcf582554fdba790e27019c8e8c4)
## Related
The full set of deployed addresses, Controller-resolved.
How these values translate into returns.
# Delegate your first LPT
Source: https://docs.livepeer.org/network/tutorials/delegate-your-first-lpt
A guided walkthrough from LPT in your Arbitrum wallet to a confirmed, reward-earning delegation.
By the end of this tutorial you'll have bonded LPT to an orchestrator through the
[Livepeer Explorer](https://explorer.livepeer.org) and confirmed a live delegator position that earns
a share of that orchestrator's rewards.
This is a **learning path**. For the decision-making behind each step — *how* to pick a good
orchestrator, or *how* to claim and compound later — follow the linked how-to guides.
## Before you start
You need all three of these to be true:
* your LPT is in a self-custody wallet on **Arbitrum One** (not Ethereum mainnet),
* you have a small **ETH balance on Arbitrum One** for gas,
* your wallet can connect to [explorer.livepeer.org](https://explorer.livepeer.org).
If your LPT is on Ethereum mainnet or an exchange, bridge or withdraw it to Arbitrum One first —
see [Acquire LPT on Arbitrum](/network/guides/delegator-acquire-lpt). You **cannot** delegate from
Ethereum mainnet.
## Step 1 — Choose an orchestrator
Open the [Explorer](https://explorer.livepeer.org), filter to **active** orchestrators, and pick one
that is currently active, has a **reliable recent reward-call history**, and acceptable commission
terms (`rewardCut` low, `feeShare` high).
This choice matters more than any other — a great commission headline with weak reliability can earn
you less than a slightly worse commission with near-perfect reliability. Use the full checklist in
[Choose an orchestrator](/network/guides/delegator-choose-orchestrator) before committing a meaningful amount.
## Step 2 — Connect your wallet
On [explorer.livepeer.org](https://explorer.livepeer.org), click **Connect Wallet** and connect the
wallet holding your Arbitrum-side LPT.
## Step 3 — Open the orchestrator and start the delegate flow
Navigate to your chosen orchestrator's profile, confirm it still shows **Active**, then click
**Delegate** and enter the amount of LPT to bond. You don't have to bond your whole balance — you can
start partial and add more later from the same wallet.
## Step 4 — Sign two transactions
The first transaction authorizes the `BondingManager` contract to move the LPT amount you entered.
No stake is bonded yet.
The second transaction actually bonds your LPT and attributes your stake to the orchestrator.
Both are on Arbitrum and cost a small amount of ETH in gas.
## Step 5 — Verify your position
Return to your account page in the Explorer and confirm you now see:
* a **bonded LPT balance**,
* the **orchestrator address** your stake points to,
* a **pending rewards** area that will update in later rounds.
If you delegated mid-round, don't expect immediate reward growth. First accrual typically appears in
the **next round**, after the orchestrator calls `reward()`.
## One warning before your first claim
Don't claim too early. If you call `claimEarnings()` *before* your orchestrator has called
`reward()` for the current round, you can **skip that round's rewards entirely**. The Explorer may
not warn you. Safe default: claim **late in the round**, after your orchestrator has already called
`reward()`. Full details in [Manage your delegation](/network/guides/delegator-manage).
## You're delegated
Your position is live. From here, the work shifts to managing it:
Claim, compound, redelegate, and exit — with the timing edge cases.
How rewardCut, feeShare, and inflation shape what you earn.
# Run your first orchestrator
Source: https://docs.livepeer.org/network/tutorials/run-your-first-orchestrator
A guided, end-to-end walkthrough from a bare GPU machine to a node earning on Livepeer mainnet.
By the end of this tutorial you'll have a `go-livepeer` orchestrator running on **Arbitrum One**,
registered on-chain, visible in the Explorer, and ready to receive video transcoding jobs.
This is a **learning path** — it makes opinionated choices so you can get to a working node in about
an hour. When you want to change those choices, the [how-to guides](/network/guides/orchestrator-configure)
cover each step in depth.
We'll use **Docker** and **GPU video transcoding** throughout. Adding AI inference is a separate
step once this is working — see [Add AI inference](/network/guides/orchestrator-add-ai).
## Before you start
You need:
| Requirement | Details |
| ---------------- | ------------------------------------------------------ |
| **GPU** | NVIDIA with NVENC (GTX 1060+ for transcoding) |
| **OS** | Linux (recommended for production) |
| **Docker** | Docker Engine + NVIDIA Container Toolkit |
| **Wallet funds** | ETH **and** LPT on Arbitrum One |
| **Network** | Port `8935/tcp` open to the public internet |
| **RPC** | An Arbitrum One endpoint (Alchemy or Infura free tier) |
Acquiring LPT on Arbitrum can take **hours to days** (exchange settlement + bridging). Start that
now — it's the slowest part. See [Acquire LPT](/network/guides/delegator-acquire-lpt), which applies to
orchestrators too.
## Step 1 — Confirm your GPU and Docker
```bash theme={null}
# List your NVIDIA GPUs (note the device IDs)
nvidia-smi -L
# Confirm Docker can see the GPU
docker run --gpus all nvidia/cuda:12.0-base nvidia-smi
```
If the second command fails, install the NVIDIA Container Toolkit before continuing
(`sudo apt-get install -y nvidia-container-toolkit && sudo systemctl restart docker`).
## Step 2 — Get an Arbitrum One RPC URL
Create a free app at [Alchemy](https://www.alchemy.com) (select **Arbitrum** → **Mainnet**) and copy
the HTTPS URL. Verify it points at Arbitrum One — the chain ID must be `0xa4b1` (42161):
```bash theme={null}
curl -s -X POST -H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' \
YOUR_RPC_URL
# Expect: {"result":"0xa4b1"}
```
A `0x1` result means you're on Ethereum L1 — switch to an Arbitrum endpoint.
## Step 3 — Start the node
Run `go-livepeer` in combined orchestrator + transcoder mode. On first start it creates an Ethereum
account and prompts for a passphrase.
```bash theme={null}
docker run --name livepeer-orchestrator \
-v ~/.lpData/:/root/.lpData/ \
--network host \
--gpus all \
livepeer/go-livepeer:latest \
-network arbitrum-one-mainnet \
-ethUrl YOUR_RPC_URL \
-orchestrator \
-transcoder \
-nvidia 0 \
-maxSessions 10 \
-pricePerUnit 1000 \
-serviceAddr YOUR_PUBLIC_IP:8935
```
Mounting `~/.lpData/` is what persists your keystore between restarts. Without it, a **new wallet
is created every run** and any staked LPT becomes unreachable. Back up
`~/.lpData/arbitrum-one-mainnet/keystore` to offline storage immediately — a lost keystore cannot
be recovered.
A quick orientation on the flags you just used:
* `-pricePerUnit 1000` — wei **per pixel**, not ETH. (Setting this in ETH prices you far above market.)
* `-maxSessions 10` — concurrent transcode sessions; tune later in [Configure](/network/guides/orchestrator-configure).
* `-serviceAddr` — the **public** address gateways will reach. A domain name is more resilient than a bare IP.
## Step 4 — Fund the wallet, stake LPT, and activate
Find your orchestrator address in the startup logs, then send it **ETH on Arbitrum** (≥ 0.05 ETH for
gas) and **LPT**. Once both are in the wallet, open the CLI:
```bash theme={null}
docker exec -it livepeer-orchestrator livepeer_cli
```
Then:
1. Select the **bond/stake** option and stake your LPT (two transactions: `approve`, then `bond`).
2. Select **"Invoke multi-step 'become an orchestrator'"** and set:
| Prompt | Suggested start | Meaning |
| --------------- | --------------------- | ------------------------------------------------- |
| Reward Cut | `10` | You keep 10% of LPT inflation; delegators get 90% |
| Fee Cut | `95` | You keep 95% of ETH fees; delegators get 5% |
| Service address | `YOUR_PUBLIC_IP:8935` | Must match `-serviceAddr` exactly |
Your node enters the active set at the **start of the next round** (\~22h) — and only if your total
stake is in the top 100. Check the current threshold on the
[Explorer](https://explorer.livepeer.org/orchestrators) before acquiring LPT.
## Step 5 — Verify
Open [explorer.livepeer.org/orchestrators](https://explorer.livepeer.org/orchestrators) and search
your address. Confirm:
* **Status** is Active (may show Registered until the next round),
* **Service URI** matches your `-serviceAddr`,
* **Stake**, **Reward Cut**, and **Fee Cut** match what you set.
Confirm external reachability from a *different* machine:
```bash theme={null}
curl -k https://YOUR_PUBLIC_IP:8935/status
```
Any response (even an error) means the port is reachable. A timeout means port `8935` is blocked —
see the [FAQ](/network/reference/faq#port-8935-not-reachable).
## Step 6 — Confirm reward calling
`go-livepeer` calls `reward()` automatically each round by default. Make sure it isn't disabled:
```bash theme={null}
docker logs livepeer-orchestrator 2>&1 | grep -i reward
```
Your command should **not** contain `-reward=false`. A missed round forfeits that round's LPT
permanently — there's no catch-up.
## You're live
Your orchestrator is on mainnet and discoverable. Where to go next:
The biggest lever on whether gateways actually select you.
Earn from AI pipelines alongside transcoding.
Metrics, dashboards, and an alert for missed reward calls.
Work through the four common causes.
# Which path is yours?
Source: https://docs.livepeer.org/network/who-this-is-for
Pick the role that matches what you have — GPUs or LPT — and the right starting page.
There are two ways to participate on the supply side of Livepeer. They are independent: you can do
either, both, or move between them over time.
## I have GPUs → Orchestrator
You run hardware and want it to earn. As an orchestrator you install `go-livepeer`, advertise what
your GPU can do, and the network sends you video and AI jobs. You earn **ETH** for completed work
and **LPT** for participating in the protocol each round.
What an orchestrator is and how it fits into the network.
Go from a bare machine to a working mainnet orchestrator.
**You'll want:** an NVIDIA GPU, a Linux machine with a public IP, some ETH and LPT on Arbitrum One,
and a willingness to keep a server online.
## I have LPT → Delegator
You hold LPT and want it to work without running infrastructure. As a delegator you **bond** your
LPT to an orchestrator you trust. Your tokens stay in your control — they are never handed to the
operator — and you share in that orchestrator's rewards.
What bonding actually means, and the risks involved.
Go from LPT in your wallet to a confirmed delegation.
**You'll want:** LPT on **Arbitrum One**, a small amount of ETH on Arbitrum for gas, and a wallet
you can connect to the [Livepeer Explorer](https://explorer.livepeer.org).
## I want to build an app → Developer (coming soon)
You want to *use* the network's compute — send video or AI jobs from your application — rather than
supply it. That's the **demand side**, and its docs aren't here yet: a developer platform, and a
Build section of this site, are on the way.
Until then, the best place to ask what's possible today is the
[Livepeer Discord](https://discord.gg/livepeer). If you're curious how demand reaches the network in
the meantime, [How the network works](/network/explanation/how-the-network-works) shows the full
path from application to GPU.
## Not sure yet?
Both roles share the same economics — read [Economics](/network/explanation/economics) to see how ETH fees
and LPT inflation are split between orchestrators and their delegators. That one page explains why
each side does what it does.