22:I[1103,["9433","static/chunks/9433-56626a365a8fc12b.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df","8290","static/chunks/8290-dfd68d4961ef5897.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df","4189","static/chunks/4189-2bd3c434870fac57.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df","4006","static/chunks/4006-8f2f2412294279b5.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df","6846","static/chunks/6846-a8292222d25eb9be.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df","8122","static/chunks/8122-9a72ef04f0c7586a.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df","4985","static/chunks/4985-f75bc6ac7575a5e1.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df","9329","static/chunks/app/roadmap/page-aa5ea50b18141899.js?dpl=dpl_8RL7DY25aMG3uawFaCDHTqqBp5Df"],"Roadmap"] 23:T1829,

1. Purpose

Before this work, adding a compute capability to the network meant one of two things: writing Livepeer-specific code into go-livepeer and the AI runner, which only the core team could do, or standing up a full gateway in front of the SDK. Roughly 170 capabilities were live and all were sourced centrally, with each new one adding to a core-team queue.

Live Runner lets an orchestrator put an ordinary HTTP service behind the network. The service is registered, health-checked, discoverable, reverse-proxied and priced, and needs no Livepeer-specific code for basic passthrough. The paired SDK covers the client side: discover an orchestrator, reserve a session, call it, settle payment, no gateway required.

This is Milestone 1 of the Livepeer Agent Framework. The other four milestones (capability onboarding, real-traffic validation, quality-of-service routing, billing and metering) all build on the same plumbing, so shipping it as one tagged release stopped them being built on branches that would keep moving. It also sat on the critical path for the Agent's closed beta and the orchestrator onboarding cohort.

2. Outcome

Overview:

One referenceable release of Live Runner and the paired SDK, consolidated from six to seven months of prototype work across the BYOC, stream diffusion and Scope PR stack, with operator-facing reference documentation. An operator can attach an existing HTTP, SSE, WebSocket or trickle application as a container alongside a running orchestrator and have it discovered, priced onchain and serving paid sessions. Complexity moves out of go-livepeer and ai-runner, and downstream milestones build against a fixed surface.

Key Metrics To Measure The Outcome Against:

Tagged release of Live Runner and the Go SDK merged to go-livepeer master, with reference documentation published. Met (Live Runner 2026-07-24, paired SDK 2026-07-27)
Both registration models (static and dynamic) and both session modes (persistent and single-shot) available and documented. Met
An off-the-shelf HTTP container can go behind the network with no Livepeer-specific application code for basic passthrough. Met
Onchain discovery and payment working end to end, with USD-denominated pricing converted and settled through probabilistic micropayments and usage tracked per session. Met (LiveRunner 0.9.0 tracks billable seconds; fixed-billing collector support followed)
Downstream milestones build on the released surface rather than on branches. Met; zero-code capability onboarding was in progress against it within the same week

3. Requirements

Written as the opportunity would have been issued, with delivery status recorded against each item.

Must Have

A single tagged release consolidating the prototype stack (BYOC, stream diffusion, Scope) into one referenceable surface. Delivered
An orchestrator-side registry tracking each runner's application, metadata, mode, readiness, capacity, price and active sessions, advertising only runners it currently considers ready. Delivered
A reverse proxy preserving request method, query string, headers, body, streaming responses and WebSocket upgrade, without exposing the runner's private address to clients. Delivered
Both registration models: static, where the operator owns configuration and the orchestrator polls a health URL, and dynamic, where the runner registers itself and holds readiness open with heartbeats. Delivered
Both session modes: persistent for realtime and stateful work, single-shot for stateless request/response, with capacity counted in sessions rather than connections. Delivered
Onchain pricing and payment: USD-denominated registration price across per-hour, per-720p and fixed units, probabilistic micropayment settlement, and session release on payment failure. Delivered
A paired SDK so a client can discover, reserve, call and pay without standing up a full gateway. Delivered (Go and Python)
Reference documentation covering the static configuration schema, CLI flags, dynamic runner protocol and full HTTP API. Delivered (doc/live-runner.md)

Should Have

Container-first deployment attachable to an existing orchestrator through ordinary tooling (Kubernetes, Docker, Ansible). Delivered
Session-scoped trickle channels and opaque session-scoped proxy URLs, so a runner can expose a secondary service without leaking the session identifier that would let a client manipulate the session. Delivered
Aggregated discovery through the remote signer, giving clients and gateways a single price-filtered endpoint across orchestrators. Delivered
Session reconciliation after a runner restart or network partition, so a recovering runner can stop stale local work against the orchestrator's authoritative session list. Delivered
Stable, human-readable public routes via label routing instead of generated runner IDs. Delivered

Nice To Have

Opaque, application-controlled metadata advertised verbatim through discovery, bounded and explicitly non-secret. Delivered (UTF-8, 1,024 bytes)
Configurable public proxy URL shapes, including per-proxy subdomains as well as path templates. Delivered
Live upsert of static runner configuration without restarting the node, validated atomically per batch. Delivered
A community-facing explainer covering how Live Runner connects to the agentic stack. Outstanding (Rick Staa with Josh, scheduled for a subsequent watercooler)

24:T98e,

1. Purpose

The second round of the Network Engineering SPE funds the work that makes the Livepeer network easier to take part in, for builders, orchestrators, delegators and, with Livepeer 2.0, validators. It keeps the pilot's mission and changes its shape. The pilot had no outcomes set at the start, one technical reviewer as a bottleneck and weak accountability. This round has four tracks, each with one named owner, one outcome to reach by 31 December and a budget that owner allocates.

2. Outcome

Each track has one outcome to reach by 31 December 2026:

Easy to build (Mike Zupper): a developer can go from a clean machine to a working, paid call on the Livepeer stack using only the published documentation, paying from a crypto wallet or through a third-party service for anyone who doesn't want to hold one.
Easy to operate (Josh Allmann): a network substrate that connects demand to supply end to end, takes new capabilities without a new integration stack each time, has the observability to diagnose issues, and makes every capability discoverable with clear pricing.
Easy to delegate (Elliott Conway): self-custody delegation that is clear, competitive and economically informed for Livepeer 2.0, measured by funnel conversion and ultimately delegation volume.
Easy to validate (Shane Burgett): self-dealing and gaming of Livepeer's tokenomics made expensive and untenable through economic levers, network data and validators, with real testing begun on validating the work itself. This track's shape will follow the final shape of Livepeer 2.0.

3. How it runs

Rick Staa chairs a committee of the four track owners, which sets outcomes, reviews milestones and decides allocations.
Foundation Operations runs programme management, payments and reporting, and releases funds only once a milestone's definition of done is verified.
Owners pick the funding mechanism per task: RFPs, direct, retroactive or scoping grants, bounties or fixed contracts.
Each track posts a monthly update on the forum, and the round closes with a retro and community session by 20 December, with a continue, change owner or stop call for each track.
Out of scope: the agent framework, demand generation and protocol design, which are funded or decided elsewhere.

25:T565,

1. Purpose

For the Agent to run at scale, the network has to be ready: orchestrator software, capability onboarding, quality of service, and payments clearing. This opportunity resources the five-milestone framework work that gets a cohort of community orchestrators live onchain on the new stack, opening future demand paths beyond the Agent.

2. Outcome

Overview:

A cohort of community orchestrators is live onchain running the new software, capabilities are adapted and standardised, performance is observable, and payments clearinghouse work is underway.

Key Metrics To Measure The Outcome Against:

Five to eight community orchestrators onboard capabilities end to end and report success
Real traffic routed to onboarded orchestrators, with performance observable
Payments clearinghouse work underway

3. Requirements

Live Runner and Go SDK shipped as a production release
No-code, config-based capability onboarding exposed to operators
Real-world validation: real traffic and feedback from onboarded operators
Quality-of-service monitoring with routing by measured performance
Billing and metering that fits every pricing model, with the Daydream key requirement removed
Community and in-house dashboards

26:Tc31,

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

27:T5a2,

1. Purpose

Livepeer Agent is a custom MCP connector for creators and marketers who need agents to generate, edit, and augment video affordably, across models, with high creative control. This opportunity validates it with real target users in public and drives it from closed alpha to open beta, so any go-to-market funding proposal is grounded in demand evidence rather than promises.

2. Outcome

Overview:

Target-user validation is explored in public and reflected in the product's core capabilities and user experience. Livepeer Agent is in open beta with its first weeks of real market data to inform the direction of the GTM.

Key Metrics To Measure The Outcome Against:

Successful install and repeated runs of the core loop: prompt → generate → output
Closed beta cohort activated and converting into repeated use
Open beta market data captured, or explicit launch gates defined

3. Requirements

Demand-validation interviews with target creators and marketers, surfaced publicly
One-click install paired with an automated onboarding funnel
Closed beta launched at the in-person demo (NYC Creative AI Forum)
Content and growth engine producing weekly market signal
First weeks of open beta market data
Go-to-market funding proposal informed by validation evidence

28:T667,

1. Purpose

Livepeer 2.0 has presented a series of key protocol changes: Burn-Mint Equilibrium, the stake-elected validator set, fixed node bonds, and extended unbonding. These now must be specified, simulated, and supported by the community before any upgrade vote. This opportunity resources the design and governance process that gets us there, carrying forward only upgrades with demonstrated support.

2. Outcome

Overview:

The 2.0 design is specified, simulated, and supported. The litepaper has been public for a month, the community process has worked through the open questions, and an economic simulation is completem. The completion will open the door to core protocol development and an audit before an LIP package is proposed.

Key Metrics To Measure The Outcome Against:

Litepaper published and public for at least four weeks, with open questions worked through
Economic simulation completed and observable by the community
Only upgrades with demonstrated community support carried into an LIP package

3. Requirements

Opinionated litepaper specifying recommended mechanisms and initial parameters
Structured community feedback period that resolves the open questions
Protocol prototype simulation using agents to play network roles, observable by the community
Security hardening and audit path defined for candidate production code
Clear governance route from supported design to an LIP package
Migration plan outline for moving the network fully onto 2.0

5:["$","div",null,{"className":"pt-10 pb-32","children":["$","div",null,{"className":"mx-auto w-full max-w-page px-4 sm:px-6 lg:px-10","children":["$","div",null,{"className":"max-w-[68rem]","children":[["$","header",null,{"className":"pt-6 lg:pt-8","children":[["$","span",null,{"className":"text-[0.6875rem] leading-4 font-medium tracking-[0.09em] text-muted-foreground uppercase","children":"Roadmap"}],["$","h1",null,{"className":"mt-3 text-display-sm leading-[1.02] tracking-[-0.04em] text-balance sm:text-display-md lg:text-display-lg","children":"What we’re building, and when."}],["$","p",null,{"className":"mt-7 max-w-[41.5rem] text-lg leading-relaxed text-pretty text-muted-foreground","children":"One place to see everything being built across Livepeer, and who owns what."}]]}],["$","$7",null,{"fallback":["$","div",null,{"className":"mt-20 h-10 lg:mt-28"}],"children":["$","$L22",null,{"commitments":[{"slug":"live-runner-go-sdk-release","cover":"https://cdn.sanity.io/images/l36s876e/production/1d3e9758aae6cdd4b854e4f9584f8011cbfd9a3f-1456x816.png","title":"Live Runner + Go SDK Release","outcome":"One referenceable release of Live Runner and the paired SDK, so an operator can put an ordinary HTTP service behind the network.","workstream":"Network","state":"shipped","owner":"Livepeer Inc","ownerSlug":"livepeer-inc","contributors":[{"name":"Rick Staa","slug":"rick-staa","avatar":"rick-staa.jpg","profile":"rickstaa"}],"lead":{"name":"Josh Allmann","slug":"josh-allmann","avatar":"$undefined","profile":"j0sh"},"target":"Q3 2026","targetPeriod":"Q3 2026","targetSort":2026070120260930,"targetEnd":"2026-09-30","shippedAt":"2026-09-25","related":[{"label":"doc/live-runner.md in go-livepeer","href":"https://github.com/livepeer/go-livepeer/blob/master/doc/live-runner.md"},{"label":"RFC: Agent framework — the five milestones","href":"https://forum.livepeer.org/t/rfc-agent-framework-the-five-milestones/3311"}],"funding":"Livepeer Inc + Network Engineering funding SPE","issued":"$undefined","lastUpdated":"2026-10-12","detail":"$23","standing":"$undefined","retro":false},{"slug":"network-engineering-spe-ii","cover":"https://cdn.sanity.io/images/l36s876e/production/0da3604900672d612f3b5fbd180c0feb2369ab5e-1456x816.png","title":"Network Engineering SPE II","outcome":"Building on, operating, delegating to and validating the Livepeer network gets easier, with one owner and one outcome per track by year end.","workstream":"Network","state":"building","owner":"Network Engineering SPE","ownerSlug":"network-engineering-spe","contributors":["$5:props:children:props:children:props:children:1:props:children:props:commitments:0:lead",{"name":"Mike Zupper","slug":"mike-zupper","avatar":"$undefined","profile":"MikeZupper"},{"name":"Elliott Conway","slug":"elliott-conway","avatar":"$undefined","profile":"ECWireless"},{"name":"Shane Burgett","slug":"shane-burgett","avatar":"$undefined","profile":"shane"}],"lead":{"name":"Rich O'Grady","slug":"rich-ogrady","avatar":"rich-ogrady.jpg","profile":"honestly_rich"},"target":"Q4 2026","targetPeriod":"Q4 2026","targetSort":2026100120261231,"targetEnd":"2026-12-31","shippedAt":"$undefined","related":[{"label":"Pre-Proposal: Network Engineering SPE II","href":"https://forum.livepeer.org/t/pre-proposal-network-engineering-spe-ii/3344"},{"label":"Treasury proposal: Network Engineering SPE II","href":"https://explorer.livepeer.org/treasury/111658503446228247572816112721456795758412212276052146357833354166930807009621"},{"label":"Build track milestones","href":"https://github.com/orgs/Cloud-SPE/projects/13/views/4"},{"label":"Operate track milestones","href":"https://github.com/livepeer/naap-ops/milestone/1"},{"label":"Validate track milestones","href":"https://github.com/users/moatus/projects/1"},{"label":"Delegate track milestones","href":"https://github.com/livepeer/explorer/milestones"},{"label":"Budget tracker","href":"https://docs.google.com/spreadsheets/d/1oSLD7hUeL6WY0d_IgXGiBPSSZ_hkOBJtavpAbTA0nb0/edit?gid=1436475940#gid=1436475940"}],"funding":"Livepeer Treasury: 177,500 LPT ($230,000 USD)","issued":"2026-09-13","lastUpdated":"2026-10-12","detail":"$24","standing":{"health":"on-track","latest":{"commitment":"network-engineering-spe-ii","date":"2026-10-06","summary":"Running budget and milestone trackers for all four tracks are now public, alongside the September track updates.","author":{"name":"Mehrdad Sadeghi","slug":"mehrdad-sadeghi","avatar":"mehrdad-sadeghi.jpg","profile":"Mehrdad"},"link":"https://forum.livepeer.org/t/pre-proposal-network-engineering-spe-ii/3344/21","draft":false,"kind":"update","health":"on-track","anchor":"update-2026-10-06-2"}},"retro":"$undefined"},{"slug":"network-readiness-for-livepeer-agent","cover":"https://cdn.sanity.io/images/l36s876e/production/c2628855a32836a85f90ba723cd2629f9a84c942-1456x816.png","title":"Network Readiness For Livepeer Agent","outcome":"A cohort of community orchestrators is live onchain running the new software, with capabilities standardised and performance observable.","workstream":"Network","state":"building","owner":"Livepeer Inc","ownerSlug":"livepeer-inc","contributors":["$5:props:children:props:children:props:children:1:props:children:props:commitments:0:contributors:0"],"lead":{"name":"Qiang Han","slug":"qiang-han","avatar":"$undefined","profile":"$undefined"},"target":"Q3 2026","targetPeriod":"Q3 2026","targetSort":2026070120260930,"targetEnd":"2026-09-30","shippedAt":"$undefined","related":[{"label":"Livepeer 2.0: The Initial Roadmap","href":"https://forum.livepeer.org/t/livepeer-2-0-the-initial-roadmap/3310"},{"label":"RFC: Agent framework — the five milestones","href":"https://forum.livepeer.org/t/rfc-agent-framework-the-five-milestones/3311"}],"funding":"Livepeer Foundation, Livepeer Inc + Network engineering funding SPE","issued":"2026-07-28","lastUpdated":"2026-10-12","detail":"$25","standing":{"health":"no-update"},"retro":"$undefined"},{"slug":"simplify-billing-payments-with-livepeer-clearinghouse","cover":"https://cdn.sanity.io/images/l36s876e/production/3210a93c58ad86eda9c081a5d8f5687c923c736f-1456x816.png","title":"Simplify Billing & Payments With Livepeer Clearinghouse","outcome":"Non-core developers can build and monetise on Livepeer through a shared payment, usage metering and authentication layer.","workstream":"Network","state":"building","owner":"Elite Code Solutions","ownerSlug":"elite-code-solutions","contributors":"$undefined","lead":{"name":"John Mull","slug":"john-mull","avatar":"$undefined","profile":"elitmik"},"target":"Q3 2026","targetPeriod":"Q3 2026","targetSort":2026070120260930,"targetEnd":"2026-09-30","shippedAt":"$undefined","related":[{"label":"Livepeer Payment Clearinghouse","href":"https://forum.livepeer.org/t/livepeer-payment-clearinghouse/3264"}],"funding":"Network Engineering SPE, Direct Grant #1 ($15k)","issued":"$undefined","lastUpdated":"2026-10-12","detail":"$26","standing":{"health":"no-update","latest":{"commitment":"simplify-billing-payments-with-livepeer-clearinghouse","date":"2026-08-20","summary":"Milestone 3 complete; Milestones 4 and 5 rescoped to documentation and a retrospective.","author":{"name":"John Mull","slug":"john-mull","avatar":"$undefined","profile":"elitmik"},"link":"https://forum.livepeer.org/t/livepeer-payment-clearinghouse/3264/13","draft":false,"kind":"update","health":"on-track","anchor":"update-2026-08-20"}},"retro":"$undefined"},{"slug":"agent-product-launch-gtm-exploration","cover":"https://cdn.sanity.io/images/l36s876e/production/284ddcce63e09dc485789f43254049e39f5a2e40-1456x816.png","title":"Agent Product Launch & GTM Exploration","outcome":"Livepeer Agent is in open beta with its first weeks of real market data to inform the direction of the GTM.","workstream":"Agent","state":"building","owner":"Livepeer Inc","ownerSlug":"livepeer-inc","contributors":"$undefined","lead":{"name":"Steph Alinsug","slug":"steph-alinsug","avatar":"$undefined","profile":"$undefined"},"target":"Q3 2026","targetPeriod":"Q3 2026","targetSort":2026070120260930,"targetEnd":"2026-09-30","shippedAt":"$undefined","related":[{"label":"Livepeer 2.0: The Initial Roadmap","href":"https://forum.livepeer.org/t/livepeer-2-0-the-initial-roadmap/3310"}],"funding":"Foundation & Inc funded + go-to-market funding proposal, informed by validation evidence","issued":"2026-07-28","lastUpdated":"2026-10-12","detail":"$27","standing":{"health":"no-update"},"retro":"$undefined"},{"slug":"validating-livepeer-2-0-upgrades-litepaper","cover":"https://cdn.sanity.io/images/l36s876e/production/4ec4de4b93bf8043d35851effec09f97abb8a2a5-1456x816.png","title":"Validating Livepeer 2.0 Upgrades & Litepaper","outcome":"The 2.0 design is specified, simulated and supported by the community before any upgrade vote.","workstream":"Protocol","state":"building","owner":"Livepeer Inc","ownerSlug":"livepeer-inc","contributors":"$undefined","lead":{"name":"Doug Petkanics","slug":"doug-petkanics","avatar":"doug-petkanics.jpg","profile":"dob"},"target":"Q3 2026","targetPeriod":"Q3 2026","targetSort":2026070120260930,"targetEnd":"2026-09-30","shippedAt":"$undefined","related":[{"label":"A Path to Livepeer 2.0","href":"https://forum.livepeer.org/t/a-path-to-livepeer-2-0/3291"},{"label":"Livepeer 2.0: The Initial Roadmap","href":"https://forum.livepeer.org/t/livepeer-2-0-the-initial-roadmap/3310"}],"funding":"Funding from Livepeer Inc / Foundation","issued":"2026-07-28","lastUpdated":"2026-10-12","detail":"$28","standing":{"health":"no-update"},"retro":"$undefined"}],"workstreams":["Protocol","Network","Agent"],"suggestionsHref":"/contribute"}]}]]}]}]}]