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.

Paying for every transcoding segment or AI inference request on-chain would make each transaction uneconomic given gas costs. Probabilistic micropayments (PM) solve this by replacing per-job on-chain transactions with a lottery scheme that provides the correct expected payment in aggregate, with only a small fraction of tickets settled on-chain.

​
Tickets

For each job, the gateway creates a PM ticket with:
  • Face value (faceVal): the ETH amount the orchestrator receives if the ticket wins
  • Win probability (winProb): the fraction of tickets expected to win, expressed as a fraction of 2^256
  • Sender nonce: a monotonically increasing counter preventing ticket replay
  • Recipient digest: a hash of the segment data (for transcoding) or job ID (for AI)
  • Signature: signed by the gateway’s Ethereum key (or remote signer)
The expected payment per ticket is faceVal × winProb. Ticket parameters are chosen so this product equals the per-unit price the gateway is paying for the job: 
expected_payment = face_value × win_probability
                 = price_per_pixel × pixel_count  (for transcoding)
                 = price_per_second × elapsed_seconds  (for live AI)

​
Win Determination

The orchestrator determines whether a ticket wins by computing: 
ticket_hash = keccak256(ticket_params || senderNonce)
is_winner = ticket_hash < winProb
This is verifiable by both parties and cannot be manipulated by either. The TicketBroker contract validates the computation when the orchestrator submits a winning ticket.

​
Sender Deposit and Penalty Escrow

Before sending jobs, a gateway must fund two escrow accounts in TicketBroker: Sender deposit (deposit): covers expected winning ticket payouts. When a winning ticket is submitted, deposit decreases by faceVal. If the deposit falls below the ticket’s faceVal, the ticket is invalid. Penalty escrow (reserve): slashed if the gateway double-spends (submits the same ticket twice) or sends tickets with invalid signatures. This creates a financial disincentive for misbehaviour. Orchestrators check the gateway’s deposit level before accepting jobs. A gateway whose deposit is below a threshold will have jobs rejected until the deposit is replenished. Fund a gateway deposit: 
livepeer_cli -sender-deposit <AMOUNT_ETH>
livepeer_cli -sender-reserve <AMOUNT_ETH>
Or via the TicketBroker contract directly: 
ticketBroker.fundDeposit{value: depositAmount}();
ticketBroker.fundReserve{value: reserveAmount}();

​
Configuring Ticket Parameters

The gateway configures ticket parameters via the -maxTicketEV flag, which sets the maximum expected value per ticket: 
livepeer -broadcaster \
  -maxTicketEV 3000000000000000 \  # max EV = 0.003 ETH
  ...
Orchestrators set -pricePerUnit (for transcoding, in wei per pixel) or per-second pricing in aiModels.json (for AI). The gateway selects orchestrators whose price falls within its configured maximum. For AI pipelines, orchestrators advertise pricing per pipeline. The recommended baseline pricing for each pipeline is listed in the AI pipeline reference pages.

​
From Ticket to Settlement

  1. Gateway creates a ticket and sends it alongside the job to the orchestrator
  2. Orchestrator receives the job, checks the ticket is valid (deposit sufficient, signature correct, nonce fresh)
  3. Orchestrator processes the job and returns the result
  4. Orchestrator evaluates win probability: keccak256(ticket) < winProb
  5. If winner: orchestrator submits ticket to TicketBroker and receives faceVal
  6. If not winner: ticket is discarded; orchestrator retains the expected value as credit toward future winning tickets
Over many tickets, the orchestrator receives approximately sum(faceVal x winProb), the expected total compensation for all work performed.

Payments Overview

Payment modes, billing models, and the gateway deposit flow.

ETH Escrow and Deposits

Managing sender deposits and topping up escrow in TicketBroker.

Per-Second Compute

How per-second billing works for the live-video-to-video pipeline.

Remote Signer

Delegating ticket signing to a separate service for off-chain gateways.
Last modified on May 19, 2026