Skip to content
Simplify Billing & Payments With Livepeer Clearinghouse cover image
All commitments

Simplify Billing & Payments With Livepeer Clearinghouse

Status
In progress
Health
No updatesince August 20, 2026
Owner
Elite Code Solutions
Target
Q3 2026 · passed
Workstream
Network
Outcome
Non-core developers can build and monetise on Livepeer through a shared payment, usage metering and authentication layer.
Funding
Network Engineering SPE, Direct Grant #1 ($15k)
Lead
John Mull
Links
Last updated
October 12, 2026

Activity

  1. John Mull posted an update, on trackAug 20

    Milestone 3 complete; Milestones 4 and 5 rescoped to documentation and a retrospective.

    Read the full update on forum.livepeer.org
  2. John Mull posted an update, at riskAug 4

    PymtHouse is live for builders; Milestone 3 is delayed by the billing and usage changes for go-livepeer 0.9.

    Read the full update on forum.livepeer.org
  3. John Mull posted an update, on trackJul 1

    Milestone 1 closed and Milestone 2 largely complete, with device-code login demonstrated through Auth0.

    Read the full update on forum.livepeer.org
  4. John Mull posted an update, at riskJun 30

    Milestone 2 is past its June 26 date: the Docker runtime stack is merged, and the identity webhook and bootstrap scripts are in review.

    Read the full update on forum.livepeer.org
  5. John Mull posted an update, on trackJun 22

    Build kicked off: PymtHouse's signer proxy moved to OpenMeter and Kafka, and the OpenMeter bootstrap switched to the Go SDK.

    Read the full update on forum.livepeer.org

Who Are You?

Name: John Mull

Your connection to this problem: Core NaaP engineer actively building with the SDK. Over the past three months, John and Josh have been the only developers using it — this is a direct blocker to wider adoption.

What Is The Problem?

There is no general-purpose payment, usage metering, or authentication layer that multiple independent apps can rely on, which means non-core developers cannot build or monetize products on the Livepeer Network today.

Why Does It Matter To The Ecosystem?

Without a payment clearinghouse or remote signer, every developer is forced to use the existing go-livepeer gateway and long-lived API keys — a model that is incompatible with desktop apps, agentic tools (VS Code, Claude Code, BlueClaw), and OAuth 2.0 + OIDC device flows. This blocks the entire community from building with the SDK and makes it impossible to ship strategic initiatives like x402 payment support and MCP server tooling. The window is urgent: the NaaP roadmap and agent ecosystem integrations are waiting on this foundation.

Who Else Feels This?

All third-party app developers trying to build on Livepeer. Specifically: teams building desktop apps (e.g. Scope), agentic framework integrators (VS Code, Cursor, BlueClaw), and any developer who needs a billing or usage API for their product.

What Have You Already Tried or Seen?

Josh Allmann scoped a payments clearinghouse design document and roadmap as part of the Transformation SPE workstream (remote signer prototype merged into go-livepeer via PR#3822 and PR#3791). A TurnKey USDC pre-auth integration has been prototyped as a potential third-party auth option. DayDream’s current auth model (long-lived API keys, single-domain redirect) has been identified as insufficient for multi-app or desktop use cases.

What Does A Good Outcome Look Like?

  • At least 2 demand partners onboarded (1 web app + 1 desktop app) using the clearinghouse and SDK to access the Livepeer Network.
  • A working OAuth 2.0 + OIDC login flow demonstrated in a desktop or third-party integration (e.g. VS Code, BlueClaw, or Cursor).
  • A billing and usage API that lets apps show users their consumption, and lets developers view usage in the clearinghouse dashboard.
  • HTTP 402-driven automatic top-up flows working on the remote signer proxy for at least one integration.

What You Don't Know Yet

  • Where exactly is user prepay and ticket valuation measured — in the proxy, or in the value of the actual claimed ticket? This is critical for correct micropayment accounting on a shared remote signer.
  • What is the right account model for metering and billing (e.g. per-user wallet addresses on the remote signer side)?
  • Which third-party auth and signing providers (Turnkey, Privy, others) are viable, and what is the minimal interface needed if developers bring their own?
  • How are payments applied to accounts in a developer-facing Account Management API (roles, permissions, app linkage)?