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

2 Likes
About the Direct Grants category
Pre-Proposal: Network Engineering SPE
2

According to the process, a known contributor of the community must champion this grant before it can move to the review stage.

Given the strong support this work has already received within the community, and the fact that it has been discussed several times both publicly and privately, I am happy to champion this grant myself.

1 Like
3

Direct Grant AI Review — Livepeer Payment Clearinghouse

Rubric: Network Engineering SPE Retroactive Grants Rubric · Direct Grants — eligibility & cap

This is a structured rubric pre-screen, not a funding decision, selection sits with the Review.

Verdict: :white_check_mark: Strong

The technical substance is strong — clear scope, real builder fit, deep network context. The $15,000 ask sits within the $20K Direct Grant cap, and the champion gate is met.

Rubric check

Process compliance — :white_check_mark:

  • Correctly filed under Direct Grants; extends a named pilot priority (Payment Clearinghouse & Remote Signer) and J0sh’s clearinghouse vision. :white_check_mark:
  • Champion secured. Mehrdad is championing the grant (citing existing community support); this satisfies the Step-3 gate. :white_check_mark:
  • 7-day public comment window still open (posted 9 Jun; closes ~16 Jun). :white_check_mark:
  • Disclosure: the champion is also part of the SPE team — surface this dual role transparently in the thread. It doesn’t change the rubric scoring. :warning:

Pricing Agreement readiness — :white_check_mark:

  • Scope is tightly bounded with per-deliverable acceptance criteria — easily reducible to a definition of done. :white_check_mark:
  • Budget $15,000 is within the $20K Direct Grant cap. :white_check_mark:
  • Payment structure should align to the SPE model. The proposal pays five milestones in full on code review / demo. Also the last trench of funding is tied to the retrospective report.

Execution standards — :white_check_mark:

  • Technical capability is well-evidenced: reviewing engineer on go-livepeer PR #3897 (authored the OIDC/JWKS recommendation this grant implements), active orchestrator operator, Transformation SPE contributor, working prototype (pymthouse), FinTech auth background. :white_check_mark:
  • Commits to weekly forum + Discord updates (exceeds the monthly floor). :white_check_mark:
  • GitHub milestone board already linked; documentation to docs.livepeer.org is an explicit deliverable. :white_check_mark:

Quality bar — :white_check_mark:

  • Substantive and specific — references concrete flags (-remoteSignerWebhookUrl), the merged PR, contract-level detail, and a clear out-of-scope section. Not AI-padded. :white_check_mark:
  • Demonstrates strong understanding of the gateway/orchestrator payment path. :white_check_mark:

Notable strengths

  • Builder fit is unusually defensible — extends the applicant’s own merged contribution and prototype.
  • Explicit out-of-scope and future-roadmap sections keep the deliverable honest.
  • Provider-agnostic, composable design lowers onboarding for future SPE-funded clearinghouse work.
2 Likes
Pre-Proposal: Network Engineering SPE
4

@elitmik has already created significant value by shipping pymthouse, building on top of the remote signer to provide a hosted clearinghouse that enables developers to use the Livepeer network without having to manage crypto payments themselves. This work has helped unlock the Livepeer Developer Dashboard and NaaP, which will make it easier for people to discover what is available on the network and try it out.

I feel this direct grant is a strong continuation of that work. It gives John the opportunity to take a step back, apply what he has learned from pymthouse and community feedback, and focus on building a modular, extensible suite. This should make it easier for others to operate their own clearinghouses and help applications that need more direct control over authentication, billing, and metering onboard the network. It also creates a clearer path for developers to adopt the new remote signer architecture while generating valuable real-world feedback that can help improve the remote signer itself.

I look forward to seeing the suite in action and spinning up a clearinghouse using the official documentation.

1 Like
5

Thank you @Mehrdad for the review and @rickstaa for the ongoing support on this initiative. I am excited to be building this developer-facing project for the Livepeer community!

Today I’m publishing the first community update for this project, which I will be publishing weekly following each deliverable.

Weekly Recap

The project kicked off Monday by migrating the current pymthouse.com signer proxy architecture over to OpenMeter with Kafka, to bring it into compliance with the specified new Kafka events architecture for usage tracking. This was necessary to provide a working Livepeer Dashboard demo on Tuesday.

On Wednesday, I began preparing the PR for the OpenMeter bootstrap scripts. It soon became apparent that the original implementation in builder-sdk was unnecessarily extensive and fragile due to a recent shift in SDK / API compatibility related to KongHQ’s recent acquisition of OpenMeter.

The only well-supported SDK that KongHQ provides for their hosted OpenMeter API is the go-lang package sdk-konnect. The OpenMeter OSS NodeJS SDK was not fully forward compatible with KongHQ’s hosted OpenMeter service which created a requirement to either use the go-lang SDK or generate client wrappers with OpenAPI. I made the choice to use the go-lang SDK to OpenMeter integration.

This led to a draft OpenMeter go-lang CLI, which can be found here feat: Go bootstrap CLI for Auth0 + OpenMeter/Konnect by eliteprox · Pull Request #33 · livepeer/clearinghouse · GitHub . Since OpenMeter Bootstrap is set for delivery in Milestone 3, this was used only to scaffold the OpenMeter hosted environment and not cleaned up for review yet.

OpenMeter provisioning is being moved into the OpenMeter Collector instance to make the solution more maintainable and will build on the work from the Milestone 2 PR which adds automatic customer provisioning for usage events feat(collector): implement customer upsert functionality in OpenMeter collector by eliteprox · Pull Request #39 · livepeer/clearinghouse · GitHub .

This can certainly be implemented more directly in the administrative API, which will be considered this week.

Milestone 1 & 2 Status

In conclusion, last week I created the first two pull requests to satisfy Milestone 1 & 2 and one PR to satisfy Milestone 3. All of which are currently under review:

This Week’s Focus - Milestone 3

The focus this week will be on first merging the initial PRs proposed for Milestone 1 & 2, with the majority of the week focused on Milestone 3 which will ship the bootstrap scripts to fully provision the hosted OpenMeter instance.

We also plan to implement a lightweight administrative API for querying usage at the platform, app or user level. This is initially planned to ship as new http endpoints within the OpenMeter Collector, which already has credentials for managing the billing instance.

Project Scope Clarity
I want to address an FAQ I’ve got from a few community members about the scope of this project as it relates to pymthouse.com (the current production clearinghouse site).

Q: Is github.com/pymthouse/pymthouse being replaced by livepeer/clearinghouse?
A: No, the project repository at livepeer/clearinghouse will be clean, modular example of a Livepeer Remote Signer / OpenMeter clearinghouse implementation as described in the milestones outlined above. The architecture is an improvement from PymtHouse and will make the stack modular, documented and straightforward for other builders to deploy, should they wish to operate their own infrastructure.

Each improvement to the solution will be up-streamed to pymthouse/pymthouse and deployed to pymthouse.com incrementally as I have done last week with the OpenMeter / Kafka integration.

This delivery pattern supports a dual validation approach for both webhook authentication adapters described in this grant (api-key and OIDC).

  1. livepeer/clearinghouse will be validated locally with builder-sdk using the signer webhook configured with api-key authentication.
  2. pymthouse/pymthouse will be validated in live deployments with the signer webhook configured with OIDC authentication.

Q: What is builder-sdk? Should we re-write that too?
A: builder-sdk is the NodeJS package which implements the webhook used by clearinghouses and platform applications to perform RFC 8693 OIDC token exchange, which allows them to issue a signed JWT for their own users. The builder-sdk supports both api-key and JWT authentication, allowing for both integration patterns to be supported. I am considering moving this work to a fresh repo so it can be minimized in scope

Thank you to the community for your continued support and feedback. Please feel free to comment below with any questions

2 Likes
6

It has been quite a journey working with them lately, to make the Clearinghouse vision come to fruition. What he has done in pymthouse has unlocked a major blocker: how to empower other vendors, to easily provision network accessibility, capabilities, and SLAs to their target user groups without having to set up complex web3 infra. By working with NaaP initiative (to be the control plane), while pymthouse is the reference implementation of billing provider, for the first time, vendors can provide their desired services by providing the network resources.

This new grant will simply enable @elitmik to further modularize and generalize this critical service.

3 Likes
7

Thank you for your support @qiang.han!

Qiang has been a valuable partner over the past week, serving the role of a real platform consumer of the pymthouse/builder-sdk by maintaining the existing NaaP billing provider integration with pymthouse. Much appreciated :clap:

1 Like
8

Funding lane: Direct Grant

Amount: $15,000 USD-equivalent in LPT

Decision

After reviewing the application, the Review Team has decided to approve this Direct Grant for John Mull (@elitmik).

Rationale

@elitmik was selected on the strength of a long track record of impact in the Livepeer ecosystem and a clear, proportional path to more of it.

  • Delivery confidence & relevant experience — He has a long history of shipping for Livepeer, comes from one of the larger payment providers, and has spent the last several months deep in this problem space while building and operating pymthouse. That hosted clearinghouse is already adopted by real consumers, the Livepeer Developer Dashboard and NaaP.
  • Clarity & structure — The application sets out clear, attainable milestones with defined acceptance criteria.
  • Extensibility — It builds against the remote signer’s webhook contract instead of adding provider-specific logic to our core client. The integrations stay modular and outside the core software, so the suite can be extended to other open-source metering, auth, and billing solutions rather than locking the network into any one stack.
  • Path to follow-on impact — It documents the new remote signer so people can actually adopt the role, which simplifies the gateway and payment logic we shipped earlier this year. It gives application developers a reproducible, modular set of extensions to integrate against and host their apps on the network. And it improves the hosted clearinghouse early adopters already use, keeps it open-source and reproducible, and produces real usage data that helps harden the remote signer.

The ask is proportional to what this grant delivers and the follow-on impact it unlocks. The groundwork already laid in pymthouse makes the timeline credible.

Conditions & alignment

The award is subject to final scope alignment before signing. Before the agreement is countersigned, the Review Team would like @elitmik to confirm:

  • Milestones — confirm the milestones at github.com/livepeer/clearinghouse/milestones are final, or share an updated set.
  • Documentation — deliver the docs self-contained and ready to publish on docs.livepeer.org, so acceptance doesn’t depend on docs-team availability. Adam reviews and publishes.

The named external operator validating the public beta (D4) does not need to be confirmed now, but must be confirmed before the final milestone is delivered.

Questions on this decision or the next phase, drop them below.
— Mehrdad, on behalf of Network Engineering SPE review team

2 Likes
Pre-Proposal: Network Engineering SPE
9

Thank you @Mehrdad and the Review Team for the approval. Confirming the two conditions before countersigning, with a short note on what shifted during the first week of building.

1. Milestones — confirmed (refreshed)

Confirmed, with dates re-based to the actual June 15 start: first deliverable June 24 (in review tomorrow), production + public beta July 1, wrapping July 17. Payout structure unchanged.

# Deliverable Target
1 Auth webhook + runtime stack — /authorize webhook (builder-sdk, API-key verifier) + one-command compose stack (signer + Kafka + collector) Jun 24
2 Bootstrap + OpenMeter billing adapter — Go sdk-konnect bootstrap → .env.livepeer; collector → OpenMeter with Wei→USD oracle; trial balance allowances via config Jun 26
3 Administrative / Usage API + balance gate — usage query at platform/app/user level + the deny-at-zero gate Jun 30
4 Production + public beta + documentation — live July 1; draft docs July 1, final docs by July 8 Jul 8
5 Platform partnership + retrospective — partner integrations, forum retrospective with beta metrics Jul 17

Milestone 1 & Milestone 2 are already in review; the project then runs to production (Jul 1) → final docs (Jul 8) → partner integrations + retrospective (Jul 17), giving the beta a couple of weeks for real adoption.

2. Documentation

Self-contained and publish-ready for docs.livepeer.org — drafted from Milestone 1 so it never gates the ship, ready for Adam by ~July 1 and finalized by ~July 8. Covers signer standalone usage, suite integration, an app-integrator decision guide, and the API reference.

3. Public beta operator

Understood this doesn’t need confirming now. The Livepeer Developer Dashboard is the leading candidate — already a consumer of the hosted clearinghouse — and I’ll confirm the named operator before the final milestone.

Scope refinements (first-week learnings)

A few things tightened up against the live KongHQ/OpenMeter API:

  • Auth: API-key is the clearinghouse-core path; OIDC/Auth0 is validated in live pymthouse (dual-validation), keeping the example minimal-dependency.
  • Single store: hosted OpenMeter (KongHQ Konnect) is the system of record — no database; self-hosted/SQL stays on the future roadmap.
  • Bootstrap: moved to the Go sdk-konnect CLI after the KongHQ acquisition broke the OSS NodeJS SDK’s forward-compatibility.
  • Security (new): create_signed_ticket doesn’t carry model_id, so usage can’t be bound to the model served — a misattribution vector. Adding model_id + per-model RemotePaymentState signing across go-livepeer (draft PR #3947) and livepeer-python-gateway, with peer review. Additive hardening under Milestone 2.

Happy to move forward if it looks good on your side. I’ll review the planned milestone issues with @rickstaa again tomorrow to ensure we have full alignment. Thanks again, weekly updates continue.

1 Like
Pre-Proposal: Network Engineering SPE
10

Hello everyone,

Here’s a recap for week 2 (June 22 - 26) of the Livepeer Clearinghouse build and an update on our current milestones!

Weekly Recap

Milestone 1 and 2 Status Update

Since we are now past the June 26th planned delivery date for Milestone 2, I want to highlight the current status upfront

# Deliverable Target
1 Auth webhook + runtime stack — /authorize webhook (builder-sdk, API-key verifier) + one-command compose stack (signer + Kafka + collector) Jun 24
2 Bootstrap + OpenMeter billing adapter — Go sdk-konnect bootstrap → .env.livepeer; collector → OpenMeter with Wei→USD oracle; trial balance allowances via config Jun 26

Milestone 1:

Milestone 2:

Last week I worked with @rickstaa to test, review and merge the first PR for livepeer/clearinghouse which adds the docker runtime services for go-livepeer, openemeter-collector and kafka: feat(docker): add Docker Compose stack for runtime services by eliteprox · Pull Request #35 · livepeer/clearinghouse · GitHub

PymtHouse Updates

  • Added a public PymtHouse Builder API OpenAPI Scalar Spec so the Builder API can be better understood by developers building on it. Drafted a docs update
  • Formalized the API key - JWT exchange route/contract and removed several deprecated and unused routes.
  • Updated the current working go-livepeer branch for this project with the latest changes from Josh’s live-runner, which allowed Qiang to stream jobs other than LV2V through the signer. **Usage metering for jobs other than LV2V still needs validation

This Week

  • Merge carry-over PRs from last week (PR 36 + PR 53)
  • Implement demonstration of balance gate to satisfy Milestone 3
  • Complete Auth0 Integration as an example of modular identity provider (lots of value here, happy to demo)
  • Prepare documentation and launch

I will be out of office for US Independence Day July 2 - July 6th, so my goal is wrap up an MVP with enough documentation to share with other would-be clearinghouse operators by end of day on Wednesday July 1st.

PymtHouse is already fully functional in production with some UI improvements and improved API documentation. I drafted an automated ARB-ETH payment clearing mechanism powered by TurnKey. As usage ramps up on the platform, a next step will be to collect payments upon balance gate and automate those transactions as deposits to the shared signer in a pay-per-use billing mode. More to come on this after we ship!

1 Like
11

Quick follow-up on Milestone 1 and Milestone 2 from yesterday

Milestone 1 is now marked as closed. We have merged both PR 36 and 53 yesterday June 30th.

Milestone 2 is largely complete. Both are demonstrated together via the usage events in OpenMeter and the credit allowances applied during bootstrap. The bootstrap includes all business objects needed to start your own OpenMeter instance, since a single demo customer and pay-per-use plan. I will consolidate remaining Milestone 2 (aside from valid tests) into Milestone 3 before next week.

On Tuesday I demonstrated RFC 8628 Device Code Login, using Auth0 and the NodeJS Identity webhook. This shows how clearinghouse operators can easily integrate SSO login flows via GitHub, Google and other identity providers to streamline authentication to the clearinghouse remote signer. OpenMeter usage was measured for the logged in Google user.

Milestone 3 includes the Builder API for starting a signer session, RFC 8693 Token Exchange for platform applications, and a demonstration of the usage tracking in a multi-tenant deployment. Balance gate functionality will then be added to hooks into payment flows, driven by http status codes.

Wishing everyone in the US a memorable and safe holiday weekend! :united_states: