Livepeer Payment Clearinghouse

Direct Grants
1

Direct Grant Application

Livepeer Network Engineering SPE - Clearinghouse Suite & Billing Composability

1 Applicant + Payout Details

  • Applicant: John Mull (Elite Code Solutions)
  • Email: john@eliteencoder.net
  • Payment address: eliteproxy.eth

2 Scope

Problem Statement

The Livepeer Network is modernizing it’s gateway architecture to support decentralized media transport via customizable, local gateway applications. The remote signer separates Ethereum key custody from the media path - but three integration gaps remain unsolved for app integrators building on the network today:

  • As an app developer (Scope, Daydream, or any platform), I need to plug my existing auth and billing stack into the remote signer without adopting a full, opinionated clearinghouse deployment - I just need clean, composable components.
  • As a platform operator, I need to attribute signing usage to a specific user identity so I can meter, bill, and enforce spend limits using my own choice of billing provider.
  • As an ecosystem contributor, there is no reusable, well-documented clearinghouse suite that app integrators can adopt layer by layer - the gap between “build everything from scratch” and “run a full hosted clearinghouse” is unaddressed.

Using the go-livepeer remote signer’s canonical -remoteSignerWebhookUrl / -remoteSignerWebhookHeaders flags, this grant extends the remote signer’s webhook authentication mechanism as a production-ready, provider-agnostic clearinghouse suite (github.com/livepeer/clearinghouse). Authorizaton for ticket signing and usage is granted with AuthExpiry caching, and AuthID binding in RemotePaymentState for tenant/user identity.

Proposed Solution

In scope:

  • NodeJS Auth Webhook (github.com/livepeer/clearinghouse): The primary deliverable. A NodeJS module implementing the go-livepeer webhook contract ({ status, expiry, auth_id }), allowing the remote signer to authenticate incoming web requests via -remoteSignerWebhookUrl. Ships with two provider-agnostic authentication adapters: API Key validation and Auth0 JWT/JWKS validation. These two adapters demonstrate the pluggable adapter pattern - any auth scheme is supported via env var configuration with no signer changes required.
  • OpenMeter Billing Adapter (github.com/livepeer/clearinghouse): Kafka consumer of create_signed_ticket events from the go-livepeer remote signer, with OpenMeter Collector configuration and instructions for connecting to hosted KongHQ OpenMeter Cloud. MVP targets hosted OpenMeter; self-hosted is a future option.
  • Bootstrap Scripts (github.com/livepeer/clearinghouse): Provisions Auth0 and OpenMeter in a single command. Outputs a complete .env.livepeer ready for the full NodeJS module stack.
  • Administrative API Wrapper (github.com/livepeer/clearinghouse): NodeJS module wrapping the KongHQ hosted OpenMeter metering and billing API for clearinghouse operators - covering entitlement management, meter configuration, plan provisioning, and usage querying.

Future roadmap (post-grant):

  • Kill Bill and Lago billing adapters
  • Self-hosted OpenMeter deployment path
  • Additional identity provider patterns (Keycloak, Okta, Zitadel)
  • ERC20-native protocol settlement

Out of scope:

  • Self-hosted / on-prem OpenMeter (documented as a future path; MVP is hosted KongHQ)
  • Enforcing a single auth model in go-livepeer - auth remains app-specific
  • USDC / on-chain payment rails

Dependencies / Assumptions

  • Auth0 tenant accessible for JWKS verification; RS256 signing algorithm configured.
  • KongHQ hosted OpenMeter account with admin API key.
  • Livepeer Dashboard, DayDream and CloudSPE considered as potential first adopters
  • Adam (docs team) available for coordination on docs.livepeer.org payment component pages.

3 Deliverables + Acceptance Criteria

Deliverable 1 - NodeJS Auth Webhook

A NodeJS module published in github.com/livepeer/clearinghouse implementing the go-livepeer remote signer webhook contract. The primary integration point: the remote signer calls this webhook via -remoteSignerWebhookUrl before signing any payment state. The webhook validates the incoming request’s identity credential and returns { status, expiry, auth_id }. Ships with two authentication adapters - API Key and Auth0 JWT/JWKS - demonstrating the provider-agnostic pattern in practice.

Acceptance criteria:

  • Module publicly reviewable in github.com/livepeer/clearinghouse.
  • API Key adapter: validates a shared API key from the request and returns the associated auth_id.
  • Auth0 adapter: validates JWTs via JWKS and returns auth_id = client_id:usage_subject; AuthExpiry aligned to jwt.exp.
  • Both adapters implement the same webhook contract ({ status, expiry, auth_id }); active adapter is selected via env var with no code changes.
  • Rejection propagates correctly back to the gateway caller.

Deliverable 2 - OpenMeter Billing Adapter

OpenMeter Collector configuration and integration documentation for connecting go-livepeer’s create_signed_ticket Kafka output to hosted KongHQ OpenMeter Cloud. Includes the Bloblang transform mapping identity and usage fields to CloudEvents 1.0 format, and instructions for configuring KongHQ meters, features, and entitlements.

Acceptance criteria:

  • Collector config and integration docs publicly reviewable in github.com/livepeer/clearinghouse.
  • Events from a live remote signer session appear in hosted OpenMeter with correct identity and usage dimensions.
  • Metering pipeline is asynchronous and decoupled from the signing path.
  • Internal demo confirms usage draw-down against an entitlement balance after a live signing session.

Deliverable 3 - Bootstrap Scripts + Administrative API Wrapper

Bootstrap scripts provisioning Auth0 and hosted OpenMeter (KongHQ) in a single command, outputting a complete .env.livepeer. Paired with a NodeJS administrative API wrapper module covering the KongHQ metering and billing API - entitlement management, meter and plan configuration, usage querying, and customer provisioning.

Acceptance criteria:

  • Bootstrap scripts and API wrapper module publicly reviewable in github.com/livepeer/clearinghouse.
  • Running the bootstrap against an Auth0 tenant and a KongHQ OpenMeter account produces a complete, runnable .env.livepeer.
  • API wrapper covers key KongHQ billing operations (see KongHQ Metering & Billing API v3).
  • New user authenticating for the first time receives configured trial credits in OpenMeter.

Deliverable 4 - Production Deployment + Public Beta + Documentation

Full NodeJS module stack deployed to production. Public beta open to external operators and developers. Payment component documentation published to docs.livepeer.org (in coordination with Adam), covering signer standalone usage, clearinghouse suite integration, and a decision guide for app integrators.

Acceptance criteria:

  • All components deployed; end-to-end flow validated (Auth0 login → JWT → webhook → remote signer → metered usage → OpenMeter balance draw-down).
  • Public beta accessible; at least one named external operator (Scope, Daydream, or equivalent) confirms real job completion.
  • API Reference Guide publicly available.
  • Documentation live on docs.livepeer.org or staging; reviewed by at least one core team member.

4 Milestones + Payment Tranches

Milestone What will be delivered Verification Target date Payout
1 NodeJS auth webhook module published in github.com/livepeer/clearinghouse. Implements go-livepeer webhook contract ({ status, expiry, auth_id }) with two provider-agnostic adapters: API Key authentication and Auth0 JWT/JWKS validation. Active adapter selected via env var. Code Review 6/13/2026 $3,325
2 OpenMeter Billing Adapter - Kafka->OpenMeter Collector config and KongHQ integration docs. auth_id parsing, Wei->USD conversion, CloudEvents 1.0 emission to hosted OpenMeter Cloud. Code Review + Internal Demo 6/20/2026 $3,325
3 Bootstrap scripts (Auth0 + KongHQ OpenMeter) outputting .env.livepeer. NodeJS administrative API wrapper for KongHQ metering and billing API. Code Review + Demo 6/27/2026 $3,325
4 Production deployment of full NodeJS stack. Public beta. API Reference Guide and docs.livepeer.org payment component pages published. Named external operator confirms end-to-end. Public Demo 7/3/2026 $3,325
5 Retroactive community engagement: active outreach to onboard operators and app integrators, collection of adoption feedback, forum summary post with beta metrics (authenticated sessions, trial activations, adopter testimonials), and incorporation of community feedback into docs and the repo. Forum post + adoption evidence 7/17/2026 $1,500

5 Update Cadence

  • Cadence: Weekly
  • Channel: Forum thread + Discord (#projects / #water-cooler)
  • Updates include: Progress vs milestones, blockers, risks, next steps, links to reviewable code

6 Budget + Use of Funds

Category Amount Notes
Engineering time $13,300 4 engineering milestones (M1–M4) at $3,325 each
Infrastructure $200 KongHQ OpenMeter Cloud, Auth0, Railway, Vercel. Expected ~$75/mo; buffer for unexpected usage.
Community engagement (retroactive) $1,500 M5 - operator onboarding, forum presence, Discord outreach, public beta coordination, docs.livepeer.org documentation, and post-completion impact report with adoption evidence. Paid after M4 delivery.
Total $15,000

7 Impact

Expected Impact

App integrators building on the Livepeer network today must either build billing from scratch or adopt a full, opinionated clearinghouse stack. This grant delivers github.com/livepeer/clearinghouse - a composable NodeJS suite where each component (auth webhook, billing adapter, bootstrap scripts, admin API wrapper) is independently useful and deployable.

  • App integrators can adopt only what they need: plug the NodeJS webhook into their existing auth stack, add the OpenMeter billing adapter, or run the full bootstrap to stand up a hosted clearinghouse.
  • Provider flexibility at every layer: any OIDC/JWKS-compatible IdP works via env var swap; additional billing adapters (Kill Bill, Lago) are the planned follow-on.
  • github.com/livepeer/clearinghouse becomes the canonical reference for app-level billing integration, lowering onboarding time for future SPE-funded clearinghouse work.
  • docs.livepeer.org payment component pages surface the signer and clearinghouse capabilities to the broader developer community - a gap today.

How Impact Will Be Evidenced

  • Named first adopters (Scope, Daydream, or NaaP / livepeer-naap) confirm end-to-end metered job completion against the deployed clearinghouse.
  • Public beta metrics: authenticated sessions, trial credit activations - reported in the weekly forum thread.
  • At least one external operator stands up the stack from the bootstrap scripts and published docs without direct assistance.

Risks + Mitigations

  • Kafka event drop under high volume: Mitigation: Collector is gap-tolerant - mid-stream gaps reconstructed from event fields; bounded impact under capped grant trial.
  • KongHQ API surface changes: Mitigation: admin API wrapper is versioned against the KongHQ v3 API; breaking changes tracked via KongHQ changelog.
  • Price Oracle Integration: We will implement a price oracle within the OpenMeter collector so that eth value is captured as it is used. This keeps the usage API accurate and mitigates billing inaccuracies associated with eth price volatility.

8 Prior Work + Relevant Context

Why John Mull

  • Reviewing engineer on go-livepeer PR #3897 - authored the timeout requirement and OIDC/JWKS recommendation that this grant now implements as one of the supported NodeJS webhook authentication methods.
  • Active Livepeer Orchestrator operator - firsthand understanding of the gateway/orchestrator payment flow and network economics.
  • Transformation SPE contributor - contributed to the SPE that shipped the remote signer and local SDK.
  • Extensive remote signer build experience: I’ve been working in this problem space for ~3 months with no funding and limited support, closely following progress in go-livepeer and rapidly protoyping GitHub - pymthouse/pymthouse: Hosted Builder API providing billing, identity and payments for Livepeer-powered applications · GitHub as an early reference implementation of a payment clearinghouse, which I feel our Network truly needs to compete with centralized providers.
  • FinTech background - Extensive experience integrating OpenID Connect and OAuth authentication in financial applications.

9 Network Engineering SPE Rubric Fit

Primary Eligibility Area

  • Developer Portal - The 5-Minute API

This grant delivers the auth and billing suite that reduces clearinghouse setup for an app integrator from weeks of custom engineering to a single bootstrap command. Any developer can plug the NodeJS webhook into their existing identity provider and connect to hosted OpenMeter billing in under an hour - or adopt only the components they need.

Design Principles

  • Community-originated - Directly extends the Improve App Payment Experience initiative (Transformation SPE), J0sh’s clearinghouse vision, and the merged PR #3897 on go-livepeer master.
  • Pre-agreed pricing - Scope and payout defined before work starts - 4 engineering milestones at $3,325 each + 1 retroactive community milestone at $1,500, $15,000 total.
  • Impact-linked payment - Each milestone has a concrete verification method (code review, internal demo, public demo). Payment tranches tied to reviewable output.
  • Transparent by default - Weekly forum updates; all code publicly reviewable under github.com/livepeer/clearinghouse; public beta open to the community.
  • Speed - Full suite delivered in 4 weeks, fitting the SPE cadence.

Impact Evidence Plan

  • Named adopter(s): Scope and Daydream (active app integrators on the Livepeer network); NaaP (livepeer/naap) is an additional confirmed consumer.
  • Downstream dependency: Any clearinghouse operator or app integrator building on the Livepeer network. The bootstrap scripts and billing adapter become the reference implementation for future SPE-funded clearinghouse deployments.
  • Capability confirmed in the wild: At least one named external operator confirms the stack end-to-end during Milestone 4 public demo. Candidates: DayDream, Livepeer Dashboard, CloudSPE (BlueClaw)

Rubric reference: How The RFP Process Works - Network Engineering SPE

1 Like
About the Direct Grants category