Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.livepeer.org/llms.txt

Use this file to discover all available pages before exploring further.

Payments on the Livepeer network flow from gateway to orchestrator using probabilistic micropayments (PM). The gateway deposits ETH into the TicketBroker contract on Arbitrum One. For each transcoding or AI inference job, the gateway sends a PM ticket alongside the segment or request. Orchestrators accumulate tickets; when a ticket is a winning ticket (determined by a verifiable random draw), the orchestrator submits it to TicketBroker and receives the face value in ETH. From a developer’s perspective, this mechanism operates transparently inside go-livepeer. The relevant choices are the payment mode (on-chain vs off-chain gateway) and the pricing configuration.

​
Gateway Payment Modes

The on-chain and off-chain labels in Livepeer describe how a gateway handles Ethereum payment operations, not the type of workload. Off-chain gateways use the remote signer architecture introduced in go-livepeer PRs #3791 and #3822. The media routing logic is separated from Ethereum signing, enabling gateway implementations in languages other than Go. See for the protocol details.

​
Probabilistic Micropayments

The PM mechanism avoids on-chain settlement for every individual job by using a lottery-based scheme:
  1. The gateway deposits ETH into TicketBroker as a sender deposit (held in escrow) and a penalty escrow (slashed on misbehaviour)
  2. For each job, the gateway sends a signed ticket specifying a face value and a probability (win probability = face value / expected payment per ticket)
  3. The orchestrator determines whether the ticket is a winner by checking a verifiable random function against the ticket parameters
  4. Winning tickets are submitted to TicketBroker on-chain; the orchestrator receives the face value
  5. Non-winning tickets are discarded
The expected payment per ticket equals face value × win probability. Over many tickets, the orchestrator receives approximately the correct total compensation without an on-chain transaction for every job. The gateway’s ETH deposit covers the expected value of outstanding winning tickets. If a gateway’s deposit falls below a threshold, orchestrators will reject jobs until the deposit is topped up.

​
Batch vs Per-Second Billing

Batch AI pipelines and transcoding jobs use a per-output-unit pricing model: the gateway pays per pixel transcoded or per output pixel generated. The face value and win probability are configured to make the expected payment match the agreed per-unit price. The live-video-to-video pipeline (Cascade) uses per-second compute billing. The gateway charges the client per wall-clock second of active inference. The LivePaymentSender interface in go-livepeer handles fee calculation and ticket generation for this billing model. See for how per-second billing works and how to configure pricing.

​
TicketBroker

The TicketBroker contract manages ETH deposits and winning ticket redemption on Arbitrum One. It is part of the livepeer/protocol contract suite deployed on arbitrum-one-mainnet. Contract addresses are in the reference.

Probabilistic Micropayments

PM mechanism internals: tickets, win probability, and escrow management.

Per-Second Compute

Billing model for the live-video-to-video pipeline.

Remote Signer

Off-chain gateway pattern separating Ethereum signing from media routing.

ETH Escrow and Deposits

Managing sender deposits and penalty escrow in TicketBroker.
Last modified on May 19, 2026