How Payments Work
Livepeer uses probabilistic micropayments (PM) to settle fees between gateways and orchestrators. Understanding this system is essential to operating a gateway responsibly — it determines your ETH obligations, your signing key security requirements, and whether you run fully on-chain or off-chain.Why Probabilistic Micropayments?
Paying for every individual AI inference job or transcoded segment on-chain would be prohibitively expensive in gas fees. Instead, Livepeer uses a lottery-style mechanism:- Gateways send orchestrators cryptographically signed tickets with each job.
- Each ticket has a small probability of being a “winning ticket” worth a larger face value.
- Orchestrators redeem winning tickets on-chain via the
TicketBrokercontract on Arbitrum.
PM significantly reduces gas costs compared to per-transaction settlement. A gateway processing thousands of jobs per hour may only trigger a handful of on-chain redemptions.
Gateway Payment Responsibilities
As a gateway operator, you are responsible for the payment side of every job routed through your node. This means:1. ETH Deposit Balance
Your gateway must maintain a funded deposit in theTicketBroker contract. This deposit is drawn from when orchestrators redeem winning tickets.
- Minimum recommended deposit: enough to cover several hours of expected workload.
- If your deposit falls too low, orchestrators will reject your tickets and jobs will fail.
- Monitor your balance via
livepeer_clior the Livepeer Explorer at explorer.livepeer.org.
2. Payment Signing Key
Each ticket must be signed with your gateway’s Ethereum private key. By default this key lives inside the samego-livepeer process handling untrusted media — a security risk if a malicious input were to exploit a vulnerability.
Security concern: A compromised gateway process could expose your signing key and drain your ETH deposit. For production deployments, consider using a Remote Signer to isolate signing from media handling.
3. Ticket Parameters and Session State
For Live AI workloads, the gateway tracks session state (nonce counters, cumulative fees, etc.) across a stream. This state is used to generate valid tickets at regular intervals. Sending stale or duplicated state produces invalid tickets that orchestrators reject.4. Reserve Balance
In addition to a deposit, gateways maintain a reserve balance as a penalty backstop. The reserve protects orchestrators in cases of gateway non-payment and is required for participating in the network with stake-based routing.On-Chain vs Off-Chain Operation
| Mode | Description | Use case |
|---|---|---|
| On-chain | Full Ethereum integration — gateway manages key, signs tickets, calls reward | Production transcoding, established gateways |
| Off-chain (Live AI) | Remote Signer handles all Ethereum operations; gateway contains no private key | Live AI workloads, embedded gateways, clearinghouse architecture |
Ticket Generation Flow
When your gateway starts a Live AI session with an orchestrator:- The orchestrator returns
ticketParams— parameters defining valid ticket shape and pricing. - Your gateway (or Remote Signer) generates and signs tickets at regular intervals.
- Orchestrators accumulate tickets and redeem winning ones on Arbitrum.
- Updated
ticketParamsare returned after each payment round, refreshing the session.