Skip to main content
A Payment Clearinghouse is a third-party service that takes over all Ethereum-related responsibilities from gateway operators and application developers. Instead of managing ETH, private keys, and PM internals, the operator registers with a clearinghouse, receives an API key, and routes gateway traffic through it. The clearinghouse handles ETH custody, PM signing, Orchestrator settlement, and billing. A Payment Clearinghouse is an abstraction implementation of a with additional commercial services including:
  • Multi-user support,
  • API key authentication,
  • Usage accounting, and
  • Billing in fiat, stablecoins, or credits.
Note that Payment Clearinghouses are designed to become independent economic actors in the Livepeer Network - providing services for a fee to end-users.

​
Architecture

A clearinghouse sits between application developers and the Livepeer network. From the developer’s perspective it looks like a traditional API provider. From the network’s perspective it looks like a Gateway using remote signers. 
Application / Developer
        |  API Key  <-  traditional auth
        v
Clearinghouse Service
  |-- Remote Signer(s)        <- ETH custody, PM ticket signing
  |-- User management         <- accounts, API keys, rate limits
  |-- Accounting              <- usage tracking, credit balances
  |-- Orchestrator discovery  <- selects from network, geo-matches
  +-- Billing                 <- invoicing in fiat, stablecoins, or credits
        |  Livepeer PM tickets on Arbitrum One
        v
Orchestrator Network
Orchestrators receive exactly the same PM tickets they would receive from a self-managed Gateway. They settle on-chain via the TicketBroker contract as normal.

​
Responsibilities

The following table clarifies what shifts from the Gateway operator to the clearinghouse:
Job routing and media handling remain with the Gateway operator. A clearinghouse manages payments, not the pipeline.

​
Clearinghouse Setup

The intended developer experience is designed to abstract pain points:

​
Building A Clearinghouse

For operators building gateway-as-a-service infrastructure (a “Provider” or NaaP operator), the minimum components are: The remote signer’s stateless design means horizontal scaling is straightforward: run multiple signer instances behind a load balancer with no shared database. Each instance is independent. For the NaaP Design Stage Only! (Network as a Platform) planned architecture that frames clearinghouse infrastructure, see and the NaaP-related proposals on the Livepeer Forum.

​
Current Status

Beta While a fully productionised public clearinghouse matures, the following access points exist: Community remote signer (testing): https://signer.eliteencoder.net/ - hosted by Elite Encoder, free ETH for testing. Uses SIWE auth and per-user JWT tokens. Not for production without understanding custody implications. Livepeer Tools: tools.livepeer.cloud - the current community tool suite for network monitoring and Gateway observability. Not a clearinghouse, but a useful surface for understanding network state.

​
Operator Choice Matrix

Reference to help guide Gateway Operator decisions on using a Clearinghouse.

Remote Signers

The technical primitive clearinghouses are built on.

Payments Guide

Decision guide for choosing between self-managed, remote signer, and clearinghouse.

NaaP Multi-Tenancy

Design Stage Only!
Network as a Platform architecture for multi-tenant gateway operation.

go-livepeer PR #3822

Implementation PR for remote signer and clearinghouse protocol support.
Last modified on March 16, 2026