Alt-Gateway Overview

Building non-Go gateway clients using the remote signer architecture: livepeer-python-gateway and the off-chain integration pattern.

---

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.

Related Pages

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.