Payment Clearinghouse

Who Are You?

Name: John Mull

Your connection to this problem (Why did you spot it? Are you affected by it? Do you work in the area it touches?): 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?

One specific sentence. Not a theme — the actual friction or gap.

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?

2–3 sentences. Who is affected and how? What is the cost of leaving it unsolved? Is there a window or urgency?

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?

Name at least one other person, persona, or group who experiences this problem.

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?

Prior attempts, related Forum threads, GitHub issues, Discord conversations, or past Advisory Board recommendations.

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?

Concrete and observable. "X goes from Y to Z" or "teams can now do X without Y."

• 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

2–4 genuine unknowns you’d want the group to help answer.

• 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)?