Network Interfaces

The reachable surfaces by which clients, gateways, and orchestrators talk to the Livepeer Network: gateway entry, orchestrator handshake, real-time frame transport.

Where Code Talks to the Network

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

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.

SDKs, API references, integration patterns.

Orchestrator Handshake

The handshake between gateway and orchestrator is a session-level RPC. The gateway calls GetOrchestratorInfo; 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.

Real-Time Frame Transport (Trickle)

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 the pytrickle 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 trickle protocol library and integration reference.

On-Chain Anchor 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 fleet.

What workloads run across these surfaces.

SDKs, APIs, and code-level reference.

Operator-side gateway implementation.