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.

The Livepeer gateway is responsible for two distinct concerns: media routing (receiving video, submitting segments to orchestrators, returning transcoded output) and Ethereum payment operations (PM bookkeeping, ticket generation, signing, ETH balance management). Historically these were coupled inside the single go-livepeer process. The remote signer architecture, introduced in go-livepeer PRs #3791 and #3822, separates them. The signer service holds the Ethereum key and handles all payment logic. The gateway handles media. A gateway client makes HTTP calls to the signer for each payment operation; the signer returns signed tickets and updated payment state.

​
Remote Signing Goals

Three problems motivated the design: Gateway diversity. Before remote signing, implementing a Livepeer gateway required deep knowledge of the PM mechanism. The livepeer-python-gateway is the first non-Go gateway implementation, enabled directly by this architecture. Security posture. In the monolith design, the Ethereum signing key sits in the same process that handles untrusted media from users. A media-path exploit could compromise the key. Remote signing removes the key from the hot path. Clearinghouses. The remote signer design allows a third-party clearinghouse to operate the signer on behalf of multiple gateways. Each gateway operator pays the clearinghouse in a traditional currency; the clearinghouse settles with orchestrators via PM under the hood. Gateway operators no longer need to hold ETH or manage Arbitrum operations.

​
Signing Protocol

The signing protocol covers two operations: the GetOrchestratorInfo authentication signature and per-job payment tickets. GetOrchestratorInfo signature: The gateway sends a static signature with each GetOrchestratorInfo RPC to authenticate the request. Because this signature never changes while the key is in use, the signer returns it once on startup and the gateway caches it. Payment ticket signing: For each PM payment, the gateway calls signTicket on the signer service: 
Gateway → Signer: signTicket(signerState, ticketParams)
Signer  → Gateway: signedTicket, updatedSignerState

Gateway → Orchestrator: pay(signedTicket)
Orchestrator → Gateway: updatedTicketParams

Gateway → Signer: signTicket(updatedSignerState, updatedTicketParams)
...
The signerState carries the accumulated PM session bookkeeping (elapsed time, balance tracking, nonce counters). The signer updates this state on each call and returns it alongside the signed ticket. The gateway stores and forwards the state; it never interprets it.

​
Stateless Signer Design

The signer is intentionally stateless across calls. It does not persist session state between requests and does not require a shared database when running multiple instances. The client (gateway) carries the state. On the first signing call of a session, the gateway sends signerState=null; the signer creates a fresh state from the provided orchestrator info. On each subsequent call, the gateway sends the signerState returned from the previous call. Consequences of this design:
  • Multiple signer instances can run without coordination: any instance can handle any request, because the full session state arrives with every call
  • Restarting the signer does not lose session state: the gateway retains the last known state and resumes correctly
  • Sending stale or null state after the first call leads to nonce repetition and invalid tickets. Gateway implementations must persist and forward state correctly

​
Current Scope

Remote signing is implemented for Live AI (live-video-to-video) only. Batch AI and transcoding workloads are not in scope for this initial implementation. Transcoding handles payments differently: tickets are signed with the segment hash, placing signing in the hot path. This is incompatible with the async remote signing model, and transcoding is considered a legacy workload with no active development. The service registry (orchestrator discovery via Arbitrum contract) is also not handled by the remote signer. Discovery is a separate concern; local gateway clients use explicit orchestrator URI lists or external discovery services.

​
Security Properties

Hot key removal. The Ethereum key is no longer co-located with media processing. An exploit from malicious video input cannot reach the signing key. Reduced blast radius. In the monolith, all gateway instances share a single Ethereum key. With remote signing, gateway instances do not hold the key at all. Compromise of a gateway binary does not yield the key. Guardrails over open signing. The signer implements the PM protocol with proper guardrails (balance checks, nonce tracking, fee limits) instead of blindly signing arbitrary payloads. This limits the damage from an exploited signer compared to a general signing endpoint.
Remote signing does not provide signing key management or rotation. The signer service must be secured, backed up, and operated with the same care as any Ethereum hot wallet holding operational funds.

Alt-Gateway Overview

livepeer-python-gateway and the off-chain client pattern enabled by remote signing.

Per-Second Compute

How LivePaymentSender state flows through the signing protocol for live AI.

Probabilistic Micropayments

The PM mechanism whose ticket generation and bookkeeping the remote signer handles.

Payments Overview

On-chain vs off-chain gateway payment modes.
Last modified on May 19, 2026