Track Progress: Forum, Transformation SPE Release Notes

1. Purpose

Livepeer’s current payment model requires developers and gateway operators to manage crypto payments and private keys as part of running media workflows. This increases operational complexity and security risk, raises onboarding friction, and concentrates usage around a small number of centralized gateway providers, limiting access to the network and constraining growth.

To support Livepeer’s evolution into a scalable real-time AI and video network, the protocol needs a simpler and safer foundation for payments and gateway access. A standalone payment signer and local gateway SDK allow applications and gateways to use the network without directly managing crypto keys or payment logic, reducing gateway complexity and improving security. This work unlocks account-based payment services (clearinghouses), enables more direct and lower-latency interactions with orchestrators, broadens participation by builders and gateway operators, and prepares the network to support higher-scale real-time AI workloads aligned with the updated network vision.

2. Outcome

Overall success is when Livepeer offers a developer-friendly payment and gateway access layer that allows applications to use the network without managing crypto wallets or payment infrastructure. Gateways can safely delegate payment signing to a standalone signer, and developers can interact with the network through a lightweight local SDK, including directly from browser or server environments, without operating a full gateway stack. This enables low-latency, direct interactions with orchestrators required for real-time use cases such as cloud gaming and interactive AI, while significantly lowering the barrier to onboarding and experimentation.

Key Metrics To Measure The Outcome Against:

Payment Signer Adoption: At least two gateway operators or ecosystem partners successfully using signer mode in testing or production.
Local SDK Functionality: A minimal, documented SDK enabling applications to submit jobs and handle payments from at least one environment (browser or server)
Integration Examples: At least one working reference integration demonstrating end-to-end usage of payment signer and local SDK.

3. Requirements

Must have:

Clearinghouse Design Document: A written design and phased roadmap defining the clearinghouse model, signer mode, and future extension paths.
Payment Signer Mode: A standalone go-livepeer signer that signs payment tickets with payment keys isolated from media workflows, without changing orchestrator job flows.
Local Gateway SDK (MVP): A minimal SDK enabling applications to interact with Livepeer from a browser or server without operating a full gateway.
End-to-End Validation & Documentation: Signer mode and SDK validated through an end-to-end real-time AI workflow, with clear setup documentation for developers and operators.

Should have:

Reference Example: One minimal example showing how an application uses the local SDK together with signer mode.
Operator Adoption Guidance: Clear instructions for operators to deploy and test signer mode in a non-production or pilot setting.

Nice to have:

Developer Utilities: Small utilities for validating signed tickets and troubleshooting local SDK interactions.
Transcoding Compatibility: Optional support for transcoding workflows alongside real-time AI workflows.

4. Proposal Guidelines

Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: Livepeer RFP — Proposal Template

Company Overview & Capabilities
Experience and why you are a great fit for this work
Milestones (with funding amount, timeline, deliverables, demo day for each)
Outcomes
Budget & Governance (how funds will be distributed)

Livepeer