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.
Network Interfaces
A developer integrating with Livepeer touches different surfaces depending on their role. An application developer calls a gateway. A gateway implementation talks to orchestrators. An orchestrator implementation talks to its workers and to the chain. The four surfaces below are described at the conceptual level; reference specs and code live in the Developers and Gateways tabs.Gateway Entry Surface
The gateway is the front door. Application developers do not talk to orchestrators or to the chain directly; they talk to a gateway. The gateway then handles discovery, payment, and result delivery on the application’s behalf. Three entry transports are supported by gateway implementations today: A developer integrating with Livepeer typically uses one of the language SDKs against a hosted gateway (Studio, Daydream) or a self-operated gateway. The gateway URL is an HTTPS endpoint; authentication and rate limiting are gateway-side decisions, not protocol-level. The HTTP surface a gateway exposes covers four families of route. Specific paths vary slightly between gateway implementations; the families are stable. SDKs, API references, integration patterns.
Orchestrator Handshake
The handshake between gateway and orchestrator is a session-level RPC. The gateway callsGetOrchestratorInfo; the orchestrator returns its capability set, its current price-per-unit, and the ticket parameters the gateway must use.
The handshake establishes the session. Once open, the gateway dispatches segments or frames with tickets attached. Tickets are signed by the gateway against the parameters the orchestrator returned in the handshake; the orchestrator validates each ticket before performing the work. Most tickets do not win; only winning tickets are submitted to TicketBroker for on-chain settlement.
Capability Bitstrings
OrchestratorInfo.Capabilities is a bitstring carrying every capability the orchestrator offers, plus a per-capability constraint map keyed by model identifier. Each entry records whether the model is warm-loaded, the orchestrator’s per-model concurrency capacity, and the runner version. The compatibility check at the gateway is a simple AND across the bitstrings: the gateway’s required capability bits must be a subset of the orchestrator’s offered bits, plus all per-model constraints must be satisfiable.
Trickle Protocol
For real-time AI workloads, the segment-and-result pattern is too slow. Frames need to move between gateway and orchestrator at sub-second latency, with audio and metadata streaming alongside. The trickle protocol is the transport. Trickle is a Livepeer-developed transport with three properties that matter for real-time AI: The trickle protocol is implemented in thepytrickle Python library and in the go-livepeer AI worker. ComfyStream and other real-time pipelines depend on it. Real-time AI integrators typically run a pytrickle-based gateway client or use a hosted gateway that implements the protocol on the client’s behalf.
The protocol shape: a publisher posts to POST /channel/seq with a monotonically increasing sequence number; subscribers fetch with GET /channel/seq for a specific segment, or GET /channel/-1 for the live edge. Subscribers can preconnect on seq+1 to remove latency between segment boundaries. Audio, video, and control flow as parallel channels on the same connection, distinguished by channel name.
The trickle protocol library and integration reference.
On-Chain Reads
Network state is publicly readable on Arbitrum One. Anyone can query the protocol contracts directly, or query the indexed view through the Livepeer subgraph. No operator relationship is needed to see what the Network is doing.Related Pages
Where each surface fits in the Network.
What workloads run across these surfaces.
SDKs, APIs, and code-level reference.
Operator-side gateway implementation.