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.

go-livepeer’s broadcaster mode is the canonical gateway implementation. The remote signer architecture (added in go-livepeer PRs #3791 and #3822) makes it possible to build gateway clients in other languages: your code handles media routing; a remote signer service handles all Ethereum payment operations. The primary reference implementation of a non-Go gateway is livepeer/livepeer-python-gateway.

​
Remote Signer Model

A gateway performing transcoding or AI inference jobs must create probabilistic micropayment tickets signed by an Ethereum key. In the standard go-livepeer broadcaster, the node manages its own keystore. In the remote signer model, the signing operations are delegated to a separate signer service over HTTP. This separation means:
  • The gateway implementation (media routing, orchestrator selection, job submission) can be written in any language
  • The signer service (ETH key management, ticket signing, balance management) runs as a separate process, typically go-livepeer in signer mode or a compatible implementation
  • The gateway connects to the signer via HTTP and passes unsigned tickets to it; the signer returns signed tickets
The gateway still needs to communicate with the Livepeer network protocol (orchestrator discovery, job protocol, segment submission) but does not need the full go-livepeer codebase.

​
Livepeer Python Gateway

livepeer/livepeer-python-gateway is the reference Python gateway implementation. It implements orchestrator session management, payment ticket lifecycle, and live video job handling. Key components: Working examples covering orchestrator selection, LV2V sessions, and payment integration are in github.com/livepeer/livepeer-python-gateway/tree/main/examples.

​
Discovery Patterns

On-chain gateways use the Arbitrum contract registry for orchestrator discovery. Off-chain SDK clients cannot query that registry without an Ethereum dependency. Three alternatives work for Python gateway clients: Explicit orchestrator list: Pass orchestrator URIs directly. Suitable for development or when operating alongside trusted orchestrators. 
orchestrators = [
    "https://orch-1.example.com",
    "https://orch-2.example.com",
]
session = OrchestratorSession(
    orchestrator_url=orchestrators[0],
    signer_url="http://localhost:8936",
)
Explorer API discovery: Query the Livepeer Explorer API to get the active orchestrator set, then filter by capability. This avoids an on-chain dependency while using current network data. Manual AI Service Registry query: For AI-capable orchestrators, the AI Service Registry on Arbitrum One lists registered orchestrators with their capabilities. Query it via a standard Arbitrum RPC endpoint.

​
Use Cases

The remote signer architecture requires coordination with the signer service for ticket signing on every job. The signer service must stay available; its unavailability blocks job submission.

Transcoding

Direct segment transcoding: the core operation a gateway performs.

BYOC Overview

Custom inference containers that gateway clients route to.

Real-Time AI Overview

Cascade architecture the Python gateway LiveVideoJob class targets.

AI Pipelines

Pipeline types and request schemas the gateway submits to orchestrators.
Last modified on May 19, 2026