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.
The Livepeer network settles payments between gateways and orchestrators using probabilistic micropayments in ETH on Arbitrum One. Applications built on top of gateways typically need a different billing model: per-user metering, subscription tiers, or fiat currency invoicing. These concerns sit between your application and the gateway, not inside the Livepeer protocol itself.
Clearinghouse Operators
The remote signer architecture enables a clearinghouse model: a third-party operator runs the Ethereum-facing signer service and manages ETH deposits on behalf of multiple gateway operators. Gateway operators settle with the clearinghouse using traditional currency; the clearinghouse handles PM ticket generation and on-chain redemption transparently. From the gateway operator’s perspective:- No ETH required in the gateway process
- No Arbitrum RPC dependency
- No PM bookkeeping in the gateway implementation
- Bills arrive from the clearinghouse in a traditional currency at agreed intervals
signTicket HTTP service is the boundary point. It prices compute, validates requests, and signs tickets only for sessions the clearinghouse has authorised.
This is the primary mechanism for third-party gateway providers (such as community gateways) to offer Livepeer compute access without requiring every developer to operate their own Arbitrum account.
Per-User Metering
A gateway operator running a multi-tenant platform needs to track usage per user to issue invoices, enforce quotas, or implement credit-based billing. This metering layer sits above the gateway and below the application:- Authentication middleware: Validate the incoming request (API key, JWT, session token) and associate it with a user account
- Usage recording: Record session start time, pipeline type, and associated user ID
- Fee calculation: At session end or billing cycle close, multiply elapsed seconds by the per-second price
- Billing integration: Push usage records to your billing system (Stripe, internal ledger, etc.)
stream.started and stream.idle webhook events (for managed gateway scenarios) or implement session tracking at the proxy layer.
Quota and Rate Limiting
Quota enforcement sits in the clearinghouse or authentication proxy, not the gateway. Patterns:Fiat Settlement
When a clearinghouse operator runs the signer on behalf of gateway operators, fiat settlement replaces direct ETH management for those operators:- The clearinghouse tracks ETH spending per gateway operator (derivable from the PM state it manages)
- The clearinghouse invoices operators periodically (weekly, monthly) in USD or another fiat currency
- Operators pay via bank transfer, credit card, or any agreed method
- The clearinghouse replenishes its ETH deposit pool from this revenue
A production clearinghouse requires careful ETH deposit pool management. The clearinghouse’s sender deposit in TicketBroker must cover the outstanding expected value of all in-flight tickets across all gateways it is signing for. Underfunding the deposit causes job rejections across all client gateways simultaneously.
Related Pages
Remote Signer
The signer architecture that enables clearinghouse and off-chain gateway patterns.
ETH Escrow and Deposits
Managing TicketBroker deposits for a gateway or clearinghouse.
Payments Overview
Payment modes and gateway deposit flow.
Alt-Gateway Overview
Non-Go gateway implementations that connect to a clearinghouse signer.