Skip to main content
Gateways sit at the application layer of Livepeer. They accept requests from apps, route them to orchestrators, and coordinate payment and failover across the compute and protocol layers. For what gateways do, see Capabilities. For why you would run one, see Business Model.

​
Gateway Layer Context

The Livepeer network has three functional layers. Gateways operate at the application layer, bridging end-user applications and the compute layer where orchestrators run GPU workloads. Gateways are the only demand-side participants that interact with both the compute layer (sending jobs to orchestrators) and the protocol layer (payment tickets, orchestrator discovery via the on-chain registry).

​
Gateway Interactions

A gateway interacts with four categories of actors:

​
Applications

Applications are the gateway’s customers. They send workloads and receive results.
  • Video applications send RTMP streams (port 1935) and receive HLS/DASH output
  • AI applications send HTTP requests (port 8935, enabled via -httpIngest) and receive JSON/binary inference results
  • BYOC applications send custom payloads via HTTP and receive container output
The gateway abstracts orchestration and protocol details for applications. Applications send workloads and receive results through gateway interfaces.

​
Orchestrators

Orchestrators are the supply side. The gateway selects, negotiates with, and dispatches work to them.
  • Discovery - on-chain gateways query the ServiceRegistry contract on Arbitrum; off-chain gateways receive orchestrator lists from the remote signer
  • Negotiation - the gateway requests an orchestrator’s capabilities and price, then establishes a session with an acceptable orchestrator
  • Dispatch - video segments or AI requests are sent to the orchestrator with an attached payment ticket
  • Failover - on failure, the gateway retries with the next-best option from its ranked list

​
Remote Signer

In the off-chain operational mode, the gateway delegates all payment operations to a remote signer service. The remote signer:
  • Holds the ETH deposit and reserve
  • Generates probabilistic micropayment tickets on the gateway’s behalf
  • Provides orchestrator discovery (list of known orchestrators)
  • Handles all on-chain interactions (ticket redemption is on the orchestrator side)
This architecture allows gateways to operate with zero crypto knowledge and zero ETH. See for the full protocol.

​
Arbitrum Protocol

In the on-chain operational mode, the gateway interacts directly with Arbitrum smart contracts:
Gateways interact with TicketBroker and ServiceRegistry. Orchestrators handle BondingManager, RoundsManager, and Governance interactions.

​
Dual Pipeline Architecture

The gateway node (LivepeerNode in go-livepeer) runs two independent session managers - one for video, one for AI. This allows a single gateway to handle both workload types simultaneously without interference.

​
Video vs AI Pipelines

Both pipelines share the same orchestrator selection logic, payment system, and failover behaviour. The separation is at the session management layer.

​
Job Lifecycle

This is what happens when an application sends a request to a gateway, from intake through result delivery and payment.

​
Lifecycle Steps

  1. Job arrives - An application sends a video segment (RTMP) or AI request (HTTP) to the gateway.
  2. Pipeline routing - The gateway routes the request to the appropriate session manager (BroadcastSessionsManager for video, AISessionManager for AI).
  3. Orchestrator selection - The session manager selects the best orchestrator from its pool based on capability, price, latency, and performance history.
  4. Payment ticket generation - The gateway (or remote signer in off-chain mode) generates a probabilistic micropayment ticket and attaches it to the job.
  5. Work dispatch - The job + ticket are sent to the orchestrator over HTTP.
  6. Execution - The orchestrator routes the work to its GPU worker (transcoder for video, AI Runner for inference) and returns the result.
  7. Result delivery - The gateway sends the processed output back to the application.
  8. Payment settlement - The orchestrator accumulates payment tickets and periodically redeems winning tickets on Arbitrum for ETH.

​
Software Components

​
go-livepeer

The core node software. When started in gateway mode (-gateway), it runs as the gateway controller. Handles:
  • Job intake (RTMP server + HTTP API server)
  • Orchestrator discovery and session management
  • Payment ticket generation (on-chain operational mode) or remote signer communication (off-chain operational mode)
  • Prometheus metrics (port 7935)
Source: github.com/livepeer/go-livepeer - specifically core/livepeernode.go
The gateway was previously called the broadcaster. Legacy CLI flags still use -broadcaster in some contexts. The -gateway flag is the current standard.

​
livepeer_cli

A command-line tool that connects to a running go-livepeer node. Used for:
  • Setting broadcast configuration (max price, transcoding profiles)
  • Funding the on-chain deposit and reserve
  • Viewing node status and connected orchestrators

​
Remote Signer (off-chain)

A separate service that handles ETH custody and payment ticket signing for off-chain gateways. It runs as a sidecar or external service alongside go-livepeer. See for architecture and configuration.

​
Arbitrum Contracts (on-chain)

See for deployed addresses.

Gateway Role

What gateways are and how the role has evolved.

Gateway Capabilities

Workload types, orchestrator selection, and session management.

Gateway Business Model

Revenue models, cost structures, and pricing.

Payment System

How probabilistic micropayments work.
Last modified on March 16, 2026