Livepeer
Livepeer orchestrators: job selection and LPT reward eligibility
Livepeer orchestrators need active status to receive video and AI jobs from gateways; inflationary Livepeer Token (LPT) rewards also require successful round reward calls. Gateways evaluate advertised capabilities alongside price, latency, performance history and stake weight. A running GPU alone establishes neither paid work nor eligibility for a round’s rewards.
· last updated
A lower reward cut leaves more of a round’s LPT allocation for delegators, provided the operator earns that allocation.
Active status on Arbitrum One
An orchestrator’s active-set position depends on bonded LPT, including tokens that delegators assign to it. Staking and protocol accounting run on Arbitrum One. The protocol state documented for 1 July 2026 used a 100-orchestrator active set, ranked by stake. Governance controls the pool limit, so that dated capacity is not a permanent admission threshold. Under the existing protocol, an operator outside the active set receives neither gateway jobs nor inflationary round rewards, even when its software remains online. Confirm current active status in Livepeer Explorer before relying on either income stream.
How do gateways choose an orchestrator?
Gateways select compatible active-set operators using price, latency, performance history and stake weight. An operator above the applicable price ceiling can lose access to that gateway’s jobs. Meeting the ceiling only admits the node to further selection; its advertised service must also match the requested work. More bonded stake cannot supply a missing model or remove a service mismatch.
For transcoding, requested output renditions determine the encoding work. AI requests identify a pipeline and model that the operator must serve.
Matching advertised work to actual capacity
On an active node with no AI job traffic, first examine the advertised pipeline and model. A live-video-to-video service needs a ready runner and warm models. Inspect capability registration and runner logs before changing the node’s price or bonded stake.
Transcoding uses NVIDIA’s video engines, while Livepeer’s GPU inference pipelines also require GPU memory (VRAM) and CUDA compute. Cascade adds continuous frame processing, so capacity for batch requests does not establish sufficient live-stream headroom. The selected models determine actual memory use, including the space occupied by every model kept warm.
| Service option | Processing pattern | Memory and service constraints |
|---|---|---|
| Video transcoding | Encoded video renditions | 8 GB VRAM recommended; NVENC session limits affect concurrency |
| Batch AI with one warm model | Discrete requests using a resident model | 16 GB VRAM recommended |
| Batch AI with multiple warm models | Requests across resident models | 24 GB+ VRAM recommended; resident models consume memory concurrently |
| Quantized large language model (LLM) inference | Quantized weights through the Ollama runner | 16 GB VRAM recommended for quantized weights |
| Full-precision LLM inference | Language-model inference at full precision | 48 GB+ VRAM recommended for full-precision models |
| Cascade live-video-to-video | Continuous WebRTC frame transformation | 24 GB VRAM recommended; warm models and frame-buffer headroom |
| Hardware compatibility does not bypass a gateway’s price ceiling. | ||
For Cascade, the runner image
livepeer/ai-runner:live-base
bundles ComfyStream. Model weights, runtime overhead and frame buffers consume available VRAM. Weights must exist before the container starts, and live entries require
warm
set to
true
. The worker uses
-aiWorker
,
-aiModels
and
-aiModelsDir
for its AI configuration and model directory. A live entry’s
model_id
identifies a ComfyUI workflow; its models load inside ComfyStream.
If the capability entry is wrong, correct it and restart the node with its AI worker configuration. Edits to aiModels.json are not hot-reloaded. Then inspect capability registration again. A ready live service should appear under
live-video-to-video
with Warm status. Confirm that an end-to-end test returns processed frames before treating the live service as operational. If the test succeeds but no gateway jobs follow, examine the gateway’s capability-specific price cap and the node’s service performance.
Which pricing units affect job selection?
Transcoding quotes use wei per configured pixel unit, while AI prices attach to individual pipeline/model pairs.
With
pixelsPerUnit
set to 1, the transcoding rate applies to each output pixel encoded.
Total encoded pixels depend on the requested renditions and frame counts. A quote therefore needs its unit and output configuration before it can describe the cost of processing a stream.
AI operators set
price_per_unit
in
aiModels.json
. A gateway can reject an AI service whose rate exceeds its
-maxPricePerCapability
setting. A competitive transcoding rate does not override an incompatible AI quote, because the gateway evaluates the requested capability separately.
Reward calls separate LPT issuance from service fees
A successful
reward()
call accounts for an active orchestrator’s inflationary LPT allocation for that round. Service fees arise from processing work.
Under the existing model, bonded stake determines the operator pool’s proportional share of LPT allocated to active participants. The pool then divides its allocation under the operator’s reward-cut terms.
An active operator can have little customer work while still participating in stake-based issuance. Conversely, processing logs alone do not establish whether its round reward call succeeded. Fee revenue and LPT issuance need separate records because they respond to different causes. A decline in paid jobs can reduce service fees without proving a missed reward call; a missed call permanently forfeits that round’s LPT for the pool, even when the node continues processing.
Protocol transactions require ETH for gas on Arbitrum One. Running out of gas can prevent reward calls despite functioning compute hardware. That operational failure affects the reward pool shared with delegators.
Delegator shares and operator commission
In the existing protocol,
rewardCut
is the percentage of inflationary LPT that the orchestrator keeps. The
feeShare
is the percentage of ETH service fees that it passes to delegators.
A lower reward cut leaves more LPT rewards for the delegator pool; a higher fee share passes through more ETH fee revenue. These percentages apply to different amounts. Neither describes a return on the bonded LPT balance. A generous fee share can apply to little service revenue, while a low reward cut provides no inflationary allocation for a missed round. Reliability therefore changes what otherwise attractive commission settings actually distribute.
Which operator records matter before delegation?
Active status and recent reward-call reliability come before commission comparisons, followed by stake concentration and a longer operating record. An operator’s recent calls show whether the pool consistently receives its round allocations. Its position near the active-set cutoff also matters: additional delegated stake can strengthen that position, while an already dominant operator increases concentration when it attracts still more stake.
Public communication, governance participation and a sustained activity history add context to an operator’s durability. Delegation assigns capital to a specific operator, so its ongoing service and protocol behavior affect the position after the initial bond.
The October 2026 proposal would tie rewards to paid work
Under the October 2026 Livepeer 2.0 proposal, an operator’s eligible share of a round’s node emissions equals the smaller of its network-fee share and network-stake share. This Min-Fee-Stake formula would cap inflationary rewards when either contribution falls short. A node with no fee earnings would receive no LPT rewards for processing work under that formula. Additional legitimate work could still increase fee earnings after the node reaches its LPT reward ceiling. The proposed registry would admit operators without a fixed LPT bond or a cap on the number of operators.
Proposed validators would assess honest work, with their median score scaling a node’s eligible LPT rewards. That judgment would target conduct such as fabricated fees and self-dealing, rather than grade ordinary service quality. The design would also move network payments to USDC. Its proposed starting split would send half of USDC job fees directly to the node and half toward buying and burning LPT. Separate minting would fund inflationary LPT rewards.
Those mechanisms describe a design subject to implementation, simulation and governance approval. If governance adopts and deploys that design, fee generation and honesty scoring become necessary inputs alongside stake when estimating an operator’s LPT rewards.
Frequently asked questions about Livepeer orchestrators
Can one wallet delegate LPT to several orchestrators?
A wallet’s bonded position in Livepeer’s Arbitrum One staking system points to one orchestrator. Splitting delegation across operators requires separate wallets. Each position then has its own selected operator, so the operator’s reward-call record and commission terms apply to the stake assigned there.
Do delegators have to claim rewards every round?
Delegators do not need to claim every round for earnings to accrue when their orchestrator remains active and calls reward(). Claiming checkpoints accrued LPT rewards into the bonded balance. A claim before the operator’s reward call for the current round can skip that round’s earnings.
When should a new delegation show its first rewards?
A delegation made during a round typically starts showing rewards in the next round, after its active orchestrator calls reward(). A confirmed bonded balance establishes the staking position, while later reward accrual depends on the operator’s eligibility and reward call. Immediate balance growth is not part of the bonding confirmation.
Is there a minimum LPT amount for delegation?
The delegation mechanism does not impose a protocol-enforced minimum LPT amount. That differs from the competitive stake that an orchestrator needs to enter the active set. Gas costs still apply to delegation and position-management transactions on Arbitrum One, regardless of the amount of LPT assigned.
How does negotiated gateway pricing affect an orchestrator’s base rate?
A gateway-specific rate applies to the specified gateway independently of the base network price. Operators can configure that rate with -pricePerGateway after negotiating the commercial terms. The arrangement concerns the price charged for that gateway’s work; it does not change rewardCut or feeShare, which govern the operator pool’s distributions.
Must an orchestrator restart to update its transcoding price?
The livepeer_cli update-price option can change a running orchestrator’s transcoding price without a restart. The -pricePerUnit flag supplies the startup price. Discovery pricing can differ from that startup setting. Keeping the settings consistent helps a later restart preserve the intended quote.