> ## Documentation Index > Fetch the complete documentation index at: /llms.txt > Use this file to discover all available pages before exploring further. # Payment Clearinghouses > How third-party clearinghouses manage ETH custody, PM signing, and orchestrator settlement on behalf of gateway operators. Covers architecture, developer setup, building a clearinghouse, and current status. { /* TODO: Terminology Validation: - Ensure the terminology and definitions used in this page is consistent with the resources/glossary terminology Verify: - ~~Mermaid diagrams use theme colours~~ (N/A - ASCII diagram kept intentionally) - ~~Fontawesome icons are used on accordions and tabs~~ - ~~Tables use StyledTable component~~ - ~~No em-dashes are used (instead use standard -)~~ - UK spelling is used - ~~Headers are concise and technical - no long headers or questions (aim for max 3 words)~~ - ~~CustomDivider is used~~ - Placeholders for Media & Video Resources are in comments with a TODO for a human. (N/A) - ~~REVIEW flags are in JSX flags for a human.~~ Human: - H1 removed (was repeating frontmatter title) - "Why clearinghouses exist" removed (redundant with payment-guide router) - "Clearinghouse vs remote signer" trimmed to brief statement with link - PM internals cross-referenced instead of duplicated - Voice converted to entity-led throughout - Port 8937 → 8935 - Broken link payment-paths → payment-guide - Em dashes removed */} > [!TIP] > > #### **Protocol status:** > > The clearinghouse protocol was implemented in [PR #3791](https://github.com/livepeer/go-livepeer/pull/3791) and [PR #3822](https://github.com/livepeer/go-livepeer/pull/3822) and is operational. > \ > \ > ***Public Use Status*** > > * No public clearinghouse service has reached general availability as of early 2026. > * The community remote signer hosted by Elite Encoder (`signer.eliteencoder.net`) provides a testing surface in the interim. 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 [remote signer](/v2/gateways/guides/payments-and-pricing/remote-signers.md) with additional commercial services including: * Multi-user support, * API key authentication, * Usage accounting, and * Billing in fiat, stablecoins, or credits. > [!NOTE] > > 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. ```icon="terminal" theme={null} 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: Responsibility Self-managed With clearinghouse **ETH deposit and reserve** Gateway operator Clearinghouse **PM signing keys** Gateway operator Clearinghouse (remote signer) **Ticket generation** Gateway operator Clearinghouse **Orchestrator discovery** Gateway operator Clearinghouse (optional) **On-chain redemption** Orchestrators Orchestrators (unchanged) **Job routing and media** Gateway operator Gateway operator (unchanged) **Billing** N/A Clearinghouse to developer
> [!NOTE] > > 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: ### 1. Register with a clearinghouse provider Obtain an API key from the clearinghouse. Depending on the provider, this may involve identity verification, credit card details, or a crypto wallet sign-in via [SIWE (ERC-4361)]("https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4361.md"). ### 1. Configure the gateway or SDK Point the `go-livepeer` gateway at the clearinghouse signer address: ```bash icon="terminal" theme={null} livepeer \ -gateway \ -signerAddr :7936 \ -orchAddr , \ -httpAddr 0.0.0.0:8935 \ ... ``` Or, if the clearinghouse provides a full gateway-as-service endpoint, configure the Livepeer SDK with the API key directly: ```python icon="terminal" theme={null} # Livepeer Python SDK example (conceptual) client = LivepeerClient(api_key="clearinghouse-api-key") result = client.live_video_to_video(stream_url="...", pipeline="...") ``` ### 1. Route jobs and monitor usage Submit jobs through the gateway as normal. The clearinghouse handles all PM mechanics. Usage reports come from the clearinghouse, billed in its chosen currency: fiat, stablecoins, or internal credits. Orchestrators are paid from the clearinghouse's ETH pool and settle on-chain without any action from the Gateway operator. ## Building A Clearinghouse For operators building gateway-as-a-service infrastructure (a "Provider" or NaaP operator), the minimum components are: Component Purpose Starting point **Remote signer instances** ETH custody and PM signing [Remote Signers](/v2/gateways/guides/payments-and-pricing/remote-signers.md) **User management** API key issuance, SIWE login Standard web auth + SIWE libraries **Accounting service** Track usage per API key, manage credits Custom or off-the-shelf billing tooling **Billing layer** Invoice developers in chosen currency Stripe, crypto payment processors, etc. **Orchestrator discovery** Select and route to suitable Orchestrators go-livepeer discovery endpoint or custom list
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 [NaaP Multi-Tenancy](/v2/gateways/guides/roadmap-and-funding/naap-multi-tenancy.md) and the NaaP-related proposals on the [Livepeer Forum](https://forum.livepeer.org). ## 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](https://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. > [accordion] Operator Benefits > > Elimination of all Ethereum complexity: no ETH to acquire, no keys to secure, no PM internals to understand, no balance monitoring. Onboarding reduces to an API key sign-up. ETH price volatility becomes the clearinghouse's concern. > [accordion] Operator Tradeoffs > > Direct control over Orchestrator selection (the clearinghouse may limit selection or impose its own routing logic). Pricing transparency (the clearinghouse rate, not the raw network rate). Independence (dependency on a third party remaining operational). Potential margin markup on top of raw network costs. > [accordion] Decision Guide > > Full Orchestrator selection control, exact network pricing, or sufficient engineering capacity to manage ETH all favour self-management. Video transcoding operators have no clearinghouse option at present: remote signing is not supported for that workload, so self-management is the only path. ## Related Pages > [card] [Remote Signers](/v2/gateways/guides/payments-and-pricing/remote-signers.md) > > The technical primitive clearinghouses are built on. > [card] [Payments Guide](/v2/gateways/guides/payments-and-pricing/payment-guide.md) > > Decision guide for choosing between self-managed, remote signer, and clearinghouse. > [card] [NaaP Multi-Tenancy](/v2/gateways/guides/roadmap-and-funding/naap-multi-tenancy.md) > > Design Stage Only! \ > Network as a Platform architecture for multi-tenant gateway operation. > [card] [go-livepeer PR #3822](https://github.com/livepeer/go-livepeer/pull/3822) > > Implementation PR for remote signer and clearinghouse protocol support. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.