Now
Explorer: Delegator UX Analysis
The problem The Explorer now sits on a stable, maintainable foundation following recent RFP work. However, it remains visually and functionally disconnected from the Foundation’s surfaces and limited in what it surfaces to operators and delegators. It was built for an earlier era of the network and has not yet been fully realigned with current needs. Delegators making stake decisions today have less information than they should. Operators don't have the observability they need. The surface does not reflect the current state of the network or the direction the Foundation is moving. For the largest cohort of existing Livepeer participants — the people who stake, delegate, and operate — the Explorer is the Foundation's front door. Leaving it in its current state is a visibility liability that undercuts the trust the rest of the quarter's work is trying to build. Operators with better observability can demonstrate performance; delegators with better data can reward it. Both sides of that loop are currently underserved. The direction Restore the Explorer as the permissionless participation portal. The canonical Foundation-owned surface for operators and delegators, aligned with the Foundation's design system and current network reality. Q2 scope: Tailwind restyle aligned with the Foundation's design system and the Developer Portal surface. Improved default network stats — the data delegators and operators actually need to make decisions, drawing on the subgraph upgrades and metrics framework developed through the NAAP metrics/SLA process. An AI-native interface for stakeholders to query network data, surface custom dashboards, and get answers grounded in live on-chain state — not generic context (#584). LIP voting transparency — surfacing proposal status, voting history, and participation rates directly in the Explorer (#482). A native notification system for delegators and operators — reward events, proposal activity, stake changes (#319). This list is a starting point — community members are invited to propose additions during the scoping window. Work sequences after design system consistency between the Developer Portal and Explorer is specified. The two surfaces share design tokens; they do not share information architecture. Why now The Explorer is the most visible artifact of the network for the audience with the largest standing investment in it. Every week the Explorer remains in its current state is a week the Foundation signals that existing participants are not the priority. That is not the signal the quarter's strategy warrants. Funding this through the Network Engineering SPE provides a path to a retainer-based team that owns the repository and delivers against a clear participation-portal vision — rather than treating the Explorer as spot work between other priorities. What the community helps scope The problem statement is settled. The direction is settled. The scoping work ahead is: Which features matter most to delegators vs. operators. Current state assumes one surface serves both audiences equally; that assumption deserves testing. How AI chat is grounded in real network data. What data sources, what refresh cadence, what accuracy bar. Which observability surfaces serve decision-making vs. which are vanity. Specifically: what does a delegator need that they don't have, and what would an operator check daily. How LIP voting transparency is designed — what proposal data is surfaced, what participation metrics matter, and how the interface lowers friction without reducing quality (#482). What retainer structure best fits the work — a single team, a rotating set of contributors, or a hybrid model. Funding path Network Engineering SPE, Priority 2 — Explorer — Participation & Observability. The SPE supports retainer-based contributor work where scope warrants it, in addition to the RFP-and-retroactive structure.
Rick Staa about 2 months ago
Promoted To Roadmap
Live Projects
Now
Explorer: Delegator UX Analysis
The problem The Explorer now sits on a stable, maintainable foundation following recent RFP work. However, it remains visually and functionally disconnected from the Foundation’s surfaces and limited in what it surfaces to operators and delegators. It was built for an earlier era of the network and has not yet been fully realigned with current needs. Delegators making stake decisions today have less information than they should. Operators don't have the observability they need. The surface does not reflect the current state of the network or the direction the Foundation is moving. For the largest cohort of existing Livepeer participants — the people who stake, delegate, and operate — the Explorer is the Foundation's front door. Leaving it in its current state is a visibility liability that undercuts the trust the rest of the quarter's work is trying to build. Operators with better observability can demonstrate performance; delegators with better data can reward it. Both sides of that loop are currently underserved. The direction Restore the Explorer as the permissionless participation portal. The canonical Foundation-owned surface for operators and delegators, aligned with the Foundation's design system and current network reality. Q2 scope: Tailwind restyle aligned with the Foundation's design system and the Developer Portal surface. Improved default network stats — the data delegators and operators actually need to make decisions, drawing on the subgraph upgrades and metrics framework developed through the NAAP metrics/SLA process. An AI-native interface for stakeholders to query network data, surface custom dashboards, and get answers grounded in live on-chain state — not generic context (#584). LIP voting transparency — surfacing proposal status, voting history, and participation rates directly in the Explorer (#482). A native notification system for delegators and operators — reward events, proposal activity, stake changes (#319). This list is a starting point — community members are invited to propose additions during the scoping window. Work sequences after design system consistency between the Developer Portal and Explorer is specified. The two surfaces share design tokens; they do not share information architecture. Why now The Explorer is the most visible artifact of the network for the audience with the largest standing investment in it. Every week the Explorer remains in its current state is a week the Foundation signals that existing participants are not the priority. That is not the signal the quarter's strategy warrants. Funding this through the Network Engineering SPE provides a path to a retainer-based team that owns the repository and delivers against a clear participation-portal vision — rather than treating the Explorer as spot work between other priorities. What the community helps scope The problem statement is settled. The direction is settled. The scoping work ahead is: Which features matter most to delegators vs. operators. Current state assumes one surface serves both audiences equally; that assumption deserves testing. How AI chat is grounded in real network data. What data sources, what refresh cadence, what accuracy bar. Which observability surfaces serve decision-making vs. which are vanity. Specifically: what does a delegator need that they don't have, and what would an operator check daily. How LIP voting transparency is designed — what proposal data is surfaced, what participation metrics matter, and how the interface lowers friction without reducing quality (#482). What retainer structure best fits the work — a single team, a rotating set of contributors, or a hybrid model. Funding path Network Engineering SPE, Priority 2 — Explorer — Participation & Observability. The SPE supports retainer-based contributor work where scope warrants it, in addition to the RFP-and-retroactive structure.
Rick Staa about 2 months ago
Promoted To Roadmap
Live Projects
Now
Developer Portal: 5-Minute API
Opportunity Issued: 2026-04-17 (Q2) Roadmap State: Now Launch Target: 30 June 2026 Owner: Steph (Narrative) · Rick (Technical) Funding Mechanism: Foundation Canon source: Five-Minute API— PRFAQ 1. Purpose What specific problem does this solve? How does it align with and advance the vision? Why now? Livepeer has had GPU supply, network economics, and nine years of production architecture — but the path from "I heard about Livepeer" to "I'm running a job on it" still takes 15–30 minutes of stitching docs, orchestrator choice, and tooling. For the "edges" audience — technically fluent, friction-tolerant builders working in real-time AI video — that friction is the single biggest barrier to adoption. The Five-Minute API closes that gap: a single authenticated interface that takes any developer from the Livepeer docs to their first inference call in under five minutes, from any MCP-compatible tool. It is the measurable claim the Developer Dashboard makes on 30 June 2026 — the public proof that "the open network for real-time AI video" is something a developer can reach in minutes, not a positioning slogan. Why now: it is the Foundation's Q2 narrative anchor. Cost is already strong, reliability is a longer arc, and ease of use is the lever the Foundation can move on its own timeline this quarter. 2. Outcome What does overall success look like? What are the tangible key results? Overall success is when an independent developer — with no prior Foundation contact — can go from the docs to a first inference call in under five minutes (measured on a clock, single take, fresh environment), and a BYOC orchestrator can deploy a custom container and serve paid work without Foundation humans in the loop. Launch-day key results (30 June 2026): Five-minute path live — docs → discovery → authentication → first inference call, end-to-end through the Developer Dashboard. MCP integration working from at least Cursor and Claude. Three external builders (not currently in the ecosystem) publicly confirm the claim from their own workstations. Two independent GPU providers deploy custom containers via self-serve BYOC and serve paid jobs with zero Foundation intervention. Reference Python SDK, MCP server, and public decision log all shipped. Single unedited demo — one take, time on the clock. 3. Requirements Must Have Discovery, authentication, and payment plumbing — protocol-level path that reaches the network with no enterprise contract and no vendor lock-in. MCP server — published and demonstrated from Cursor and Claude on launch day. Reference Python SDK — first-call path documented and reproducible from a fresh environment. BYOC self-serve interface — independent GPU providers deploy custom containers without Foundation humans. Live unedited demo — single take, fresh environment, wall-clock measurement. External validation set — three external builder confirmations + two BYOC orchestrator deployments, captured and reviewed before 20 June, published on launch day. Public decision log — SPE-funded work traceable from input to shipped output. Weekly critical-path check — sequencing ritual tracking the three engineering chains (BYOC path · Dashboard data surface · MCP server path) with pre-agreed escalation protocol from 21 May. Should Have Cost-claim technical validation — published benchmarks substantiating the 60–85% advantage vs. centralized providers before the figure appears in public assets. Quarterly comparative benchmarks — keeps the cost claim defensible over time. Post-launch Discord support capacity — humans responding to developers hitting friction on 1 July. Pre-drafted slip language — for all three escalation scenarios, so a timeline change does not trigger a scramble. Nice to Have Broader MCP tool coverage — beyond Cursor and Claude. Node.js SDK — alongside the Python reference client. Serialized builder profile series — features the three confirmation builders in the weeks after launch. BYOC provider spotlight series. Out of Scope (this launch) Enterprise-grade SLAs or uptime guarantees — the network operates at ~90–95% uptime; enterprise reliability is a separate, longer-arc programme. Production-grade security hardening — safe-to-try only; full hardening is Q3 work scoped separately. Bespoke or Foundation-mediated builder deployments — this is a self-serve path, not enterprise onboarding. Explorer surface features — the sibling surface for Extend / Invest audiences ships on its own Q2 timeline (see Roadmap Item: Restore Explorer as Permissionless Participation Portal). Advanced analytics / stakeholder dashboards. General LLM inference as the headline workload — real-time AI video is the headline; general LLM inference works via existing ecosystem solutions. 4. Risks & Open Questions External-builder recruitment — three on-record confirmations needed by 15 June; pipeline of 6–8 candidates being built now. If only two confirm, claim 3 narrows. BYOC self-serve readiness — two friendly dry-runs by 15 May; if the path is not self-serve by launch, claim 4 reshapes or slips to July. MCP protocol stability — Cursor / Claude breaking changes would narrow the "any MCP-compatible tool" claim to one tool plus terminal. Design / website production capacity — Adam departed, Myosin contract ended; the document assumes a design path that does not yet exist. Post-launch support — currently unfunded in the plan.
Rick Staa about 2 months ago
In Progress
Live Projects
Now
Developer Portal: 5-Minute API
Opportunity Issued: 2026-04-17 (Q2) Roadmap State: Now Launch Target: 30 June 2026 Owner: Steph (Narrative) · Rick (Technical) Funding Mechanism: Foundation Canon source: Five-Minute API— PRFAQ 1. Purpose What specific problem does this solve? How does it align with and advance the vision? Why now? Livepeer has had GPU supply, network economics, and nine years of production architecture — but the path from "I heard about Livepeer" to "I'm running a job on it" still takes 15–30 minutes of stitching docs, orchestrator choice, and tooling. For the "edges" audience — technically fluent, friction-tolerant builders working in real-time AI video — that friction is the single biggest barrier to adoption. The Five-Minute API closes that gap: a single authenticated interface that takes any developer from the Livepeer docs to their first inference call in under five minutes, from any MCP-compatible tool. It is the measurable claim the Developer Dashboard makes on 30 June 2026 — the public proof that "the open network for real-time AI video" is something a developer can reach in minutes, not a positioning slogan. Why now: it is the Foundation's Q2 narrative anchor. Cost is already strong, reliability is a longer arc, and ease of use is the lever the Foundation can move on its own timeline this quarter. 2. Outcome What does overall success look like? What are the tangible key results? Overall success is when an independent developer — with no prior Foundation contact — can go from the docs to a first inference call in under five minutes (measured on a clock, single take, fresh environment), and a BYOC orchestrator can deploy a custom container and serve paid work without Foundation humans in the loop. Launch-day key results (30 June 2026): Five-minute path live — docs → discovery → authentication → first inference call, end-to-end through the Developer Dashboard. MCP integration working from at least Cursor and Claude. Three external builders (not currently in the ecosystem) publicly confirm the claim from their own workstations. Two independent GPU providers deploy custom containers via self-serve BYOC and serve paid jobs with zero Foundation intervention. Reference Python SDK, MCP server, and public decision log all shipped. Single unedited demo — one take, time on the clock. 3. Requirements Must Have Discovery, authentication, and payment plumbing — protocol-level path that reaches the network with no enterprise contract and no vendor lock-in. MCP server — published and demonstrated from Cursor and Claude on launch day. Reference Python SDK — first-call path documented and reproducible from a fresh environment. BYOC self-serve interface — independent GPU providers deploy custom containers without Foundation humans. Live unedited demo — single take, fresh environment, wall-clock measurement. External validation set — three external builder confirmations + two BYOC orchestrator deployments, captured and reviewed before 20 June, published on launch day. Public decision log — SPE-funded work traceable from input to shipped output. Weekly critical-path check — sequencing ritual tracking the three engineering chains (BYOC path · Dashboard data surface · MCP server path) with pre-agreed escalation protocol from 21 May. Should Have Cost-claim technical validation — published benchmarks substantiating the 60–85% advantage vs. centralized providers before the figure appears in public assets. Quarterly comparative benchmarks — keeps the cost claim defensible over time. Post-launch Discord support capacity — humans responding to developers hitting friction on 1 July. Pre-drafted slip language — for all three escalation scenarios, so a timeline change does not trigger a scramble. Nice to Have Broader MCP tool coverage — beyond Cursor and Claude. Node.js SDK — alongside the Python reference client. Serialized builder profile series — features the three confirmation builders in the weeks after launch. BYOC provider spotlight series. Out of Scope (this launch) Enterprise-grade SLAs or uptime guarantees — the network operates at ~90–95% uptime; enterprise reliability is a separate, longer-arc programme. Production-grade security hardening — safe-to-try only; full hardening is Q3 work scoped separately. Bespoke or Foundation-mediated builder deployments — this is a self-serve path, not enterprise onboarding. Explorer surface features — the sibling surface for Extend / Invest audiences ships on its own Q2 timeline (see Roadmap Item: Restore Explorer as Permissionless Participation Portal). Advanced analytics / stakeholder dashboards. General LLM inference as the headline workload — real-time AI video is the headline; general LLM inference works via existing ecosystem solutions. 4. Risks & Open Questions External-builder recruitment — three on-record confirmations needed by 15 June; pipeline of 6–8 candidates being built now. If only two confirm, claim 3 narrows. BYOC self-serve readiness — two friendly dry-runs by 15 May; if the path is not self-serve by launch, claim 4 reshapes or slips to July. MCP protocol stability — Cursor / Claude breaking changes would narrow the "any MCP-compatible tool" claim to one tool plus terminal. Design / website production capacity — Adam departed, Myosin contract ended; the document assumes a design path that does not yet exist. Post-launch support — currently unfunded in the plan.
Rick Staa about 2 months ago
In Progress
Live Projects
Now
Operator: MVP Platform
(March → April) Output: An MVP of the NaaP platform to prove the Livepeer network can perform popular workflows, at low latency, with the needed scale, at market-best prices, without a large amount of technical overhead for app developers. To Ship: Shell App Foundation; ****dashboard overview; shared UI components; a staging and production infra that is open to community to build, test, and deploy Solutions to the NaaP; successful integration with design partner (Daydream). Enables: Live NaaP platform with Solutions Providers marketplace; community ability build and deploy custom solutions; hypothesis-driven development approach. Features & User Stories (1) Network Overview As a network user, I can see the network overall metrics using overview dashboard As a network user, I can get an overview of the pricing of different pipelines As a network user, I can track the usage of top pipelines As a network user, I can easily query network data to see more detailed performance metrics from the network (2) Developer API As an app developer, I can create an API key per billing provider. As an app developer, I can see my overall usage tracking from all signers As an app developer, I can see my usage tracking per signer (with breakdown of project, and api key) As an app developer, I can view and search list of models that supported by the network. As an app developer, I can see my usage tracking per model (with breakdown of signer, project, and api key) (3) Community Hub As a network user, I can get feedback on new community-built plugins or features As a network user, I can request new community-built features to the network product (4) Capacity Planner As a Service Provider or App Developer, I can request GPU capacity over an allotted time period at a given price. As an Orchestrator, I can soft commit and respond to a GPU capacity request.
Admin Team 3 months ago
In Progress
Live Projects
Now
Operator: MVP Platform
(March → April) Output: An MVP of the NaaP platform to prove the Livepeer network can perform popular workflows, at low latency, with the needed scale, at market-best prices, without a large amount of technical overhead for app developers. To Ship: Shell App Foundation; ****dashboard overview; shared UI components; a staging and production infra that is open to community to build, test, and deploy Solutions to the NaaP; successful integration with design partner (Daydream). Enables: Live NaaP platform with Solutions Providers marketplace; community ability build and deploy custom solutions; hypothesis-driven development approach. Features & User Stories (1) Network Overview As a network user, I can see the network overall metrics using overview dashboard As a network user, I can get an overview of the pricing of different pipelines As a network user, I can track the usage of top pipelines As a network user, I can easily query network data to see more detailed performance metrics from the network (2) Developer API As an app developer, I can create an API key per billing provider. As an app developer, I can see my overall usage tracking from all signers As an app developer, I can see my usage tracking per signer (with breakdown of project, and api key) As an app developer, I can view and search list of models that supported by the network. As an app developer, I can see my usage tracking per model (with breakdown of signer, project, and api key) (3) Community Hub As a network user, I can get feedback on new community-built plugins or features As a network user, I can request new community-built features to the network product (4) Capacity Planner As a Service Provider or App Developer, I can request GPU capacity over an allotted time period at a given price. As an Orchestrator, I can soft commit and respond to a GPU capacity request.
Admin Team 3 months ago
In Progress
Live Projects
Next
Agentic Workflows
1. General Proposed By: Shane Burgett Proposed On: 2026-05-28 2. What Is The Problem? One specific sentence. Not a theme — the actual friction or gap. Agents do not have a simple, reusable way to create and run Livepeer-powered video and media workflows without building a dedicated application for each task. 3. Why Does It Matter To the Livepeer Ecosystem? Several sentences on why solving this problem matters, including one sentence on the cost of not solving it or the current window. Livepeer Modules make it possible to expose paid media compute, GPU capacity, runners, discovery, and billing as reusable network capabilities, but those capabilities are still too low-level for agents to compose directly inside their workflows. Today, an agent that wants to do something practical like slide extraction on a live stream, meeting capture and summarization, or home-video indexing must stitch together ingest, storage, model execution, workflow logic, payment, events, artifacts, and search as a custom integration. If this gap remains, Livepeer risks being powerful infrastructure that agents cannot easily use at the moment when agentic workflows are becoming a primary interface for software automation. 4. What Does Success Look Like? Concrete and observable. "X goes from Y to Z" or "teams can now do X without Y." No aspirational language. Use bullet points for multiple outcomes. An agent can start a video or media workflow with one stable interface, such as input + workflow + session, instead of manually integrating Livepeer APIs, runners, payment, and storage. MVP workflow packs that enable some primary capabilies like live-stream slide extraction, meeting capture and summarization, realtime security alerts, or video search can be launched from reusable workflow packs rather than bespoke applications. Livepeer Modules remain the underlying compute, media, and billing layer, while agents interact with higher-level sessions, events, artifacts, and search results. Developers can add new model or media capabilities as Livepeer modules or workflow blocks without changing the agent-facing UX. The setup path for an agent goes from “build a custom media application” to “install a skill/CLI, choose a workflow, customize it provide an input, and follow results.” 5. Open Questions Unknowns, assumptions to test, or decisions still needed before this can move forward. One question per bullet. What is the smallest agent-facing interface that can cover live streams, uploaded assets, local files, browser capture, and model workflows without exposing Livepeer internals? What workflow representation should agents use to describe media jobs in a portable way, regardless of whether the execution engine is Roboflow, a custom Livepeer workflow runner, or another tool? Which compute-heavy model capabilities should Livepeer expose first so agents do not need to assemble their own GPU stack, such as object detection, OCR, transcription, embeddings, segmentation, or YOLO-style runners? Should workflow execution happen as one paid Livepeer session, as separate paid block/model calls, or as a hybrid of both? What parts can be built as a thin external layer today, and what would require new Livepeer modules, runner contracts, SDK changes, or workflow-engine integrations? How should agents receive durable outputs such as clips, transcripts, summaries, detections, embeddings, alerts, and searchable timelines? What default workflows should prove the concept first: security stream analysis, meeting capture and memory, home-video search, slide extraction, or another high-signal use case? What security, privacy, and consent requirements apply when agents capture browser tabs, meetings, cameras, or personal video libraries? How much should the agent own locally versus delegate to hosted or networked Livepeer infrastructure? What minimum developer experience would let an agent use Livepeer for a new media automation without creating a new vertical application or custom integration each time?
Rich O'Grady 16 days ago
Promoted To Roadmap
Suggest Ecosystem Projects
Next
Agentic Workflows
1. General Proposed By: Shane Burgett Proposed On: 2026-05-28 2. What Is The Problem? One specific sentence. Not a theme — the actual friction or gap. Agents do not have a simple, reusable way to create and run Livepeer-powered video and media workflows without building a dedicated application for each task. 3. Why Does It Matter To the Livepeer Ecosystem? Several sentences on why solving this problem matters, including one sentence on the cost of not solving it or the current window. Livepeer Modules make it possible to expose paid media compute, GPU capacity, runners, discovery, and billing as reusable network capabilities, but those capabilities are still too low-level for agents to compose directly inside their workflows. Today, an agent that wants to do something practical like slide extraction on a live stream, meeting capture and summarization, or home-video indexing must stitch together ingest, storage, model execution, workflow logic, payment, events, artifacts, and search as a custom integration. If this gap remains, Livepeer risks being powerful infrastructure that agents cannot easily use at the moment when agentic workflows are becoming a primary interface for software automation. 4. What Does Success Look Like? Concrete and observable. "X goes from Y to Z" or "teams can now do X without Y." No aspirational language. Use bullet points for multiple outcomes. An agent can start a video or media workflow with one stable interface, such as input + workflow + session, instead of manually integrating Livepeer APIs, runners, payment, and storage. MVP workflow packs that enable some primary capabilies like live-stream slide extraction, meeting capture and summarization, realtime security alerts, or video search can be launched from reusable workflow packs rather than bespoke applications. Livepeer Modules remain the underlying compute, media, and billing layer, while agents interact with higher-level sessions, events, artifacts, and search results. Developers can add new model or media capabilities as Livepeer modules or workflow blocks without changing the agent-facing UX. The setup path for an agent goes from “build a custom media application” to “install a skill/CLI, choose a workflow, customize it provide an input, and follow results.” 5. Open Questions Unknowns, assumptions to test, or decisions still needed before this can move forward. One question per bullet. What is the smallest agent-facing interface that can cover live streams, uploaded assets, local files, browser capture, and model workflows without exposing Livepeer internals? What workflow representation should agents use to describe media jobs in a portable way, regardless of whether the execution engine is Roboflow, a custom Livepeer workflow runner, or another tool? Which compute-heavy model capabilities should Livepeer expose first so agents do not need to assemble their own GPU stack, such as object detection, OCR, transcription, embeddings, segmentation, or YOLO-style runners? Should workflow execution happen as one paid Livepeer session, as separate paid block/model calls, or as a hybrid of both? What parts can be built as a thin external layer today, and what would require new Livepeer modules, runner contracts, SDK changes, or workflow-engine integrations? How should agents receive durable outputs such as clips, transcripts, summaries, detections, embeddings, alerts, and searchable timelines? What default workflows should prove the concept first: security stream analysis, meeting capture and memory, home-video search, slide extraction, or another high-signal use case? What security, privacy, and consent requirements apply when agents capture browser tabs, meetings, cameras, or personal video libraries? How much should the agent own locally versus delegate to hosted or networked Livepeer infrastructure? What minimum developer experience would let an agent use Livepeer for a new media automation without creating a new vertical application or custom integration each time?
Rich O'Grady 16 days ago
Promoted To Roadmap
Suggest Ecosystem Projects
The Shifting Role of the Orchestrator
1. General Proposed By: Doug Petkanics Proposed On: 2026-05-11 2. What Is The Problem? As the network shifts to a world of heterogeneous realtime AI centric job types, the "most useful work" on the network looks a little bit different than it has in the past. Yet yesterday’s Orchestrator playbook of dedicated local hardware locked to a single job type doesn't yet match it. 3. Why It Matters To the Livepeer Ecosystem Our network of Orchestrators are the beating heart of the Livepeer project, and the intention has always been that the greatest compensation flows to those contributing the most useful work. In the search for PMF during the realtime AI era, useful work means flexibly provisioning H100's for a model launch one week, hundreds of consumer grade 4090's for a social consumer experience the next, and pricing capacity in a variable fashion as market conditions and GPU requirements change over the course of the week. If Orchestrators stay locked to dedicated local hardware, and gateways treat price discovery as a one-way street rather than a negotiation, the network will over-invest in stranded capex, under-serve the demand-gen efforts hunting for PMF, and reward legacy behavior instead of the work the network actually needs at exactly the moment Livepeer is trying to become the infrastructure network that powers the future of realtime AI media. Dedicated hardware for a single job type works when that job type achieves scale, but flexibility and adaptiveness is more critical prior to finding PMF. 4. What Does Success Look Like? Capacity sourcing goes from "dedicated local hardware per job type" to a flexible mix of owned hardware, cloud, data center deals, decentralized services, and serverless passthrough APIs, sized to live demand. Demand visibility goes from "Discord rumors and folklore" to a NaaP Operator dashboard that shows, in realtime, the workflows on the network, fees flowing to each job type, GPU and compute requirements, average network pricing, and forecasts/requests for future capacity. Price discovery goes from "gateway-dictated, one job type, one price" to a job-by-job negotiation in which Orchestrators price variably to make sure they're only providing capacity that makes economic sense, and gateways pay enough to incentivize the capacity they need. Operator tooling goes from "manual, per-operator spreadsheets" to optimization modules that take market conditions, current job types in demand, LPT reward-cut incentives, and idle-time estimates as inputs to provisioning and pricing decisions. Stake flow goes from "agnostic to job mix" to LPT delegation flowing toward the nodes doing productive work at acceptable reward-cut levels, supported by improved staking-tool UX. 5. Open Questions Cloud margin paradox: How can the Livepeer Network be cheaper than just renting cloud capacity, if the node operators themselves need to access cloud capacity and then apply a margin? At scale, marketplace competition on idle hardware should still result in the lowest possible price; prior to scale, LPT incentives and the resourcefulness of a global operator base sourcing the most efficient capacity have to win out vs defaulting to the premium option. Negotiation protocol ownership: What does the minimum viable variable-pricing protocol at the gateway ↔ Orchestrator layer look like, and who is building and optimizing this? Staking UX: How do we evolve staking-tool UX so LPT delegation flows toward the nodes doing productive work at acceptable reward-cut levels, without disrupting existing delegators? Operator inclusivity: How do we keep smaller, hobbyist Orchestrators competitive when the new playbook rewards multi-cloud sourcing skill and API orchestration, and how do we surface and reward their broader contributions (community meetings, Discord support, dev entities) alongside flexible compute? Reward design: How prescriptive should the project be about "ideal" Orchestrator behavior versus letting the open marketplace settle it? This roadmap suggestion is the start of an early conversation so the community can take part in tackling these challenges. Looking forward to hosting discussions on this soon, before swinging into concrete build items and action.
Doug Petkanics about 1 month ago
Discussion Closed
Suggest Ecosystem Projects
The Shifting Role of the Orchestrator
1. General Proposed By: Doug Petkanics Proposed On: 2026-05-11 2. What Is The Problem? As the network shifts to a world of heterogeneous realtime AI centric job types, the "most useful work" on the network looks a little bit different than it has in the past. Yet yesterday’s Orchestrator playbook of dedicated local hardware locked to a single job type doesn't yet match it. 3. Why It Matters To the Livepeer Ecosystem Our network of Orchestrators are the beating heart of the Livepeer project, and the intention has always been that the greatest compensation flows to those contributing the most useful work. In the search for PMF during the realtime AI era, useful work means flexibly provisioning H100's for a model launch one week, hundreds of consumer grade 4090's for a social consumer experience the next, and pricing capacity in a variable fashion as market conditions and GPU requirements change over the course of the week. If Orchestrators stay locked to dedicated local hardware, and gateways treat price discovery as a one-way street rather than a negotiation, the network will over-invest in stranded capex, under-serve the demand-gen efforts hunting for PMF, and reward legacy behavior instead of the work the network actually needs at exactly the moment Livepeer is trying to become the infrastructure network that powers the future of realtime AI media. Dedicated hardware for a single job type works when that job type achieves scale, but flexibility and adaptiveness is more critical prior to finding PMF. 4. What Does Success Look Like? Capacity sourcing goes from "dedicated local hardware per job type" to a flexible mix of owned hardware, cloud, data center deals, decentralized services, and serverless passthrough APIs, sized to live demand. Demand visibility goes from "Discord rumors and folklore" to a NaaP Operator dashboard that shows, in realtime, the workflows on the network, fees flowing to each job type, GPU and compute requirements, average network pricing, and forecasts/requests for future capacity. Price discovery goes from "gateway-dictated, one job type, one price" to a job-by-job negotiation in which Orchestrators price variably to make sure they're only providing capacity that makes economic sense, and gateways pay enough to incentivize the capacity they need. Operator tooling goes from "manual, per-operator spreadsheets" to optimization modules that take market conditions, current job types in demand, LPT reward-cut incentives, and idle-time estimates as inputs to provisioning and pricing decisions. Stake flow goes from "agnostic to job mix" to LPT delegation flowing toward the nodes doing productive work at acceptable reward-cut levels, supported by improved staking-tool UX. 5. Open Questions Cloud margin paradox: How can the Livepeer Network be cheaper than just renting cloud capacity, if the node operators themselves need to access cloud capacity and then apply a margin? At scale, marketplace competition on idle hardware should still result in the lowest possible price; prior to scale, LPT incentives and the resourcefulness of a global operator base sourcing the most efficient capacity have to win out vs defaulting to the premium option. Negotiation protocol ownership: What does the minimum viable variable-pricing protocol at the gateway ↔ Orchestrator layer look like, and who is building and optimizing this? Staking UX: How do we evolve staking-tool UX so LPT delegation flows toward the nodes doing productive work at acceptable reward-cut levels, without disrupting existing delegators? Operator inclusivity: How do we keep smaller, hobbyist Orchestrators competitive when the new playbook rewards multi-cloud sourcing skill and API orchestration, and how do we surface and reward their broader contributions (community meetings, Discord support, dev entities) alongside flexible compute? Reward design: How prescriptive should the project be about "ideal" Orchestrator behavior versus letting the open marketplace settle it? This roadmap suggestion is the start of an early conversation so the community can take part in tackling these challenges. Looking forward to hosting discussions on this soon, before swinging into concrete build items and action.
Doug Petkanics about 1 month ago
Discussion Closed
Suggest Ecosystem Projects
Next
Payment, Identity, Usage & Billing Infra
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)?
John Mull 3 months ago
Promoted To Roadmap
Live Projects
Next
Payment, Identity, Usage & Billing Infra
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)?
John Mull 3 months ago
Promoted To Roadmap
Live Projects
ComfyStream Multi-Pipeline Experiment + ComfyMeme Demo
1. What is the problem? Today most AI pipelines on the network run using a one-container-per-pipeline setup. In practice this means: • Each pipeline type runs in its own container environment • Orchestrators must maintain multiple containers to support multiple pipelines • Most orchestrators end up specialising in one pipeline type • GPUs cannot easily pivot between different workloads without redeployment This creates two ecosystem issues: Limited flexibility Even if GPUs have available capacity, orchestrators cannot easily switch between different pipeline types. Operational complexity Running multiple containers increases configuration overhead, environment drift, and maintenance burden. As a result, orchestrators often choose a single pipeline to support rather than experimenting with multiple AI services. The constraint appears to be software orchestration, not GPU capability. 2. Why does this matter to the ecosystem? This primarily affects the supply side of the network. The ecosystem currently has roughly 100 AI-capable orchestrators, meaning supply growth is constrained. When supply is capped, the key growth lever becomes: revenue per GPU Multi-pipeline capability could improve: • revenue per GPU • revenue per orchestrator • supply flexibility across pipeline types • time-to-serve new AI workloads Without this flexibility, the network risks developing specialised supply that cannot adapt quickly to demand changes. 3. Proposed experiment This proposal tests whether ComfyStream can enable multi-pipeline orchestrators by dynamically loading workflows on a single GPU. Instead of running multiple containers, an orchestrator would run: one ComfyStream runtime capable of loading different workflows on demand. The experiment aims to determine whether this is technically viable and operationally useful. 4. Demonstration application: ComfyMeme To test this capability in practice, the experiment includes building a small demonstration application called ComfyMeme. ComfyMeme generates AI-remixed animated memes using short GIF / WebP clips from the Giphy API. Example pipeline: Giphy meme clip → frame extraction → Stable Diffusion + LoRA stylisation → animated meme output Memes are intentionally chosen because they are: • easy to understand • fast to generate • culturally shareable • capable of producing organic traffic The demo therefore acts as both: • a public application • a stress test for multi-pipeline orchestration 5. Relationship to ComfyStream Cloud The longer-term concept discussed in the AI SPE roadmap is ComfyStream Cloud — a platform where creators could deploy Comfy workflows as hosted AI applications. Instead of this model: creator → workflow JSON → user runs locally Workflows could become hosted services: creator → workflow → hosted endpoint → users ComfyMeme acts as a first proof-of-concept of this idea. If hosted workflows prove viable, future work could explore creator deployment tools and monetisation mechanisms. 6. Scope limitations This experiment intentionally avoids solving several large problems: • automatic model distribution • arbitrary workflow compatibility • creator monetisation infrastructure Instead, it assumes a curated model set preloaded on orchestrator nodes. The goal is simply to validate dynamic workflow execution on the network. 7. Success criteria Success should demonstrate both technical viability and economic potential. Technical signals: • one ComfyStream runtime successfully serving multiple workflows • acceptable workflow switching latency • stable execution across multiple requests Adoption signals: • at least three orchestrators running ComfyStream Economic signal: • at least one orchestrator earning revenue from two distinct pipeline types on a single GPU 8. Deliverables The experiment would produce: • ComfyMeme demonstration application • ComfyStream configuration enabling multi-pipeline loading • documentation for orchestrator setup • public demo endpoint • written findings on performance, latency, and operational challenges 9. Expected duration Estimated timeline: 4–6 weeks This includes: • building the demo application • orchestrator deployment testing • community demonstration • documentation of results 10. Summary This proposal tests whether dynamic workflow loading via ComfyStream can enable orchestrators to serve multiple AI pipelines from a single GPU. The experiment combines: • infrastructure validation • a public demonstration application • measurable economic outcomes The key outcome is simple: prove that a single orchestrator GPU can earn revenue from multiple pipelines. If successful, this would strengthen orchestrator incentives and lay the groundwork for future hosted workflow platforms such as ComfyStream Cloud.
Peter Schroedl 3 months ago
Discussion Closed
Suggest Ecosystem Projects
ComfyStream Multi-Pipeline Experiment + ComfyMeme Demo
1. What is the problem? Today most AI pipelines on the network run using a one-container-per-pipeline setup. In practice this means: • Each pipeline type runs in its own container environment • Orchestrators must maintain multiple containers to support multiple pipelines • Most orchestrators end up specialising in one pipeline type • GPUs cannot easily pivot between different workloads without redeployment This creates two ecosystem issues: Limited flexibility Even if GPUs have available capacity, orchestrators cannot easily switch between different pipeline types. Operational complexity Running multiple containers increases configuration overhead, environment drift, and maintenance burden. As a result, orchestrators often choose a single pipeline to support rather than experimenting with multiple AI services. The constraint appears to be software orchestration, not GPU capability. 2. Why does this matter to the ecosystem? This primarily affects the supply side of the network. The ecosystem currently has roughly 100 AI-capable orchestrators, meaning supply growth is constrained. When supply is capped, the key growth lever becomes: revenue per GPU Multi-pipeline capability could improve: • revenue per GPU • revenue per orchestrator • supply flexibility across pipeline types • time-to-serve new AI workloads Without this flexibility, the network risks developing specialised supply that cannot adapt quickly to demand changes. 3. Proposed experiment This proposal tests whether ComfyStream can enable multi-pipeline orchestrators by dynamically loading workflows on a single GPU. Instead of running multiple containers, an orchestrator would run: one ComfyStream runtime capable of loading different workflows on demand. The experiment aims to determine whether this is technically viable and operationally useful. 4. Demonstration application: ComfyMeme To test this capability in practice, the experiment includes building a small demonstration application called ComfyMeme. ComfyMeme generates AI-remixed animated memes using short GIF / WebP clips from the Giphy API. Example pipeline: Giphy meme clip → frame extraction → Stable Diffusion + LoRA stylisation → animated meme output Memes are intentionally chosen because they are: • easy to understand • fast to generate • culturally shareable • capable of producing organic traffic The demo therefore acts as both: • a public application • a stress test for multi-pipeline orchestration 5. Relationship to ComfyStream Cloud The longer-term concept discussed in the AI SPE roadmap is ComfyStream Cloud — a platform where creators could deploy Comfy workflows as hosted AI applications. Instead of this model: creator → workflow JSON → user runs locally Workflows could become hosted services: creator → workflow → hosted endpoint → users ComfyMeme acts as a first proof-of-concept of this idea. If hosted workflows prove viable, future work could explore creator deployment tools and monetisation mechanisms. 6. Scope limitations This experiment intentionally avoids solving several large problems: • automatic model distribution • arbitrary workflow compatibility • creator monetisation infrastructure Instead, it assumes a curated model set preloaded on orchestrator nodes. The goal is simply to validate dynamic workflow execution on the network. 7. Success criteria Success should demonstrate both technical viability and economic potential. Technical signals: • one ComfyStream runtime successfully serving multiple workflows • acceptable workflow switching latency • stable execution across multiple requests Adoption signals: • at least three orchestrators running ComfyStream Economic signal: • at least one orchestrator earning revenue from two distinct pipeline types on a single GPU 8. Deliverables The experiment would produce: • ComfyMeme demonstration application • ComfyStream configuration enabling multi-pipeline loading • documentation for orchestrator setup • public demo endpoint • written findings on performance, latency, and operational challenges 9. Expected duration Estimated timeline: 4–6 weeks This includes: • building the demo application • orchestrator deployment testing • community demonstration • documentation of results 10. Summary This proposal tests whether dynamic workflow loading via ComfyStream can enable orchestrators to serve multiple AI pipelines from a single GPU. The experiment combines: • infrastructure validation • a public demonstration application • measurable economic outcomes The key outcome is simple: prove that a single orchestrator GPU can earn revenue from multiple pipelines. If successful, this would strengthen orchestrator incentives and lay the groundwork for future hosted workflow platforms such as ComfyStream Cloud.
Peter Schroedl 3 months ago
Discussion Closed
Suggest Ecosystem Projects
Drive AI-centric Livepeer Brand
Purpose Livepeer needs a new meme (realtime? realtime AI?). With Livepeer’s new focus on realtime AI & video, the creation and focus of the Daydream community and product, and the development of new gateway services (Streamplace, Frameworks, Embody), each part of the Livepeer story needs to be coherently weaved together. The market for video is exploding as it merges with AI. This opportunity is to lead a team dedicated to advancing the Livepeer brand, connecting the network product, token and ecosystem. As both a compute network and specialised video infrastructure, Livepeer needs to communicate its value propositions to new customers and investors. Outcome By the end of this 6-month period, Livepeer will have formed its own category and positioned itself as a market leader in providing specialised infrastructure for real-time video and AI. It will have identified its market and have the foundations of a go to market, which can be taken forward in collaboration with other teams. Some key metrics include: Number of inbound, qualified developer leads Social followers and/or social engagement Discord members increase Discord member engagement
Admin Team 3 months ago
Coming Soon
Suggest Ecosystem Projects
Drive AI-centric Livepeer Brand
Purpose Livepeer needs a new meme (realtime? realtime AI?). With Livepeer’s new focus on realtime AI & video, the creation and focus of the Daydream community and product, and the development of new gateway services (Streamplace, Frameworks, Embody), each part of the Livepeer story needs to be coherently weaved together. The market for video is exploding as it merges with AI. This opportunity is to lead a team dedicated to advancing the Livepeer brand, connecting the network product, token and ecosystem. As both a compute network and specialised video infrastructure, Livepeer needs to communicate its value propositions to new customers and investors. Outcome By the end of this 6-month period, Livepeer will have formed its own category and positioned itself as a market leader in providing specialised infrastructure for real-time video and AI. It will have identified its market and have the foundations of a go to market, which can be taken forward in collaboration with other teams. Some key metrics include: Number of inbound, qualified developer leads Social followers and/or social engagement Discord members increase Discord member engagement
Admin Team 3 months ago
Coming Soon
Suggest Ecosystem Projects
In Progress
Foundation - Narrative Readiness
Understand the existing Livepeer system: map how decisions actually get made (vs. how stakeholders believe they're made), identify where power and narrative ownership currently sit, and surface the story across Foundation, Inc, Gateway and contributor touchpoints
Admin Team 3 months ago
Completed
Live Projects
In Progress
Foundation - Narrative Readiness
Understand the existing Livepeer system: map how decisions actually get made (vs. how stakeholders believe they're made), identify where power and narrative ownership currently sit, and surface the story across Foundation, Inc, Gateway and contributor touchpoints
Admin Team 3 months ago
Completed
Live Projects
Network-As-A-Product: First Solutions Onboarded
Epic 3: First Solutions Published on NaaP Platform (April → June) Outcome: A successful program to incentivise and integrate ~3 Solutions Providers and their APIs to the network, tested and owned by members of the Livepeer community. To Ship: Set up scalable way to integrate first solutions into the NaaP platform; work with 5 new Solutions Providers to scope needs; establish way to track usage on a public dashboard per Solution Provider. Enables: Developers can build applications directly from NaaP integrating with multiple Solutions Providers, validation of the concept of community-built plugins. [WORK IN PROGRESS] Features & User Stories Coming Soon
Admin Team 3 months ago
Coming Soon
NaaP
Network-As-A-Product: First Solutions Onboarded
Epic 3: First Solutions Published on NaaP Platform (April → June) Outcome: A successful program to incentivise and integrate ~3 Solutions Providers and their APIs to the network, tested and owned by members of the Livepeer community. To Ship: Set up scalable way to integrate first solutions into the NaaP platform; work with 5 new Solutions Providers to scope needs; establish way to track usage on a public dashboard per Solution Provider. Enables: Developers can build applications directly from NaaP integrating with multiple Solutions Providers, validation of the concept of community-built plugins. [WORK IN PROGRESS] Features & User Stories Coming Soon
Admin Team 3 months ago
Coming Soon
NaaP
Next
Subgraph Audit & Stake/Earnings Indexing
What Is The Problem? The Livepeer subgraph, the data layer that every Explorer view, governance surface, delegator tool, and tokenomics analysis depends on, has not had a structured audit in a long time, so we lack a current baseline of its performance, technical debt, and indexing gaps before building further on top of it. The concrete first gap: the subgraph cannot efficiently compute delegator or orchestrator stake and earnings per round, which holds back income and tax reporting and any time series view. Why Does It Matter To the Livepeer Ecosystem? The subgraph is shared infrastructure used by all downstream surfaces, so its performance and correctness affect every consumer. The work is two steps. First, audit the subgraph and add tooling to measure size and indexing performance, giving us a known baseline before adding more to it. Second, ship the per-round stake and earnings feature on that base. BuilderDAO already identified performance improvements while building two earlier features for us, so concrete issues already exist. Auditing first lets this feature and later additions be implemented and measured against a known baseline rather than added to an unmeasured one. Without it, we have no visibility into whether new features are implemented efficiently or are adding technical debt, since we cannot measure their impact. What Does Success Look Like? Repeatable tooling to measure subgraph size and indexing performance, runnable locally and in CI, with a baseline captured. The audit produces a named, prioritized list of indexing gaps, missing or mis-modelled events, and technical debt, so future work can build on a known foundation. Per-round delegator and orchestrator stake and earnings are indexed, accurate, and queryable, with a linked deployment and sample query. Explorer maintainers confirm the indexed data can power income and earnings views. Open Questions Does anyone see objections to doing the audit first to unlock quicker feature enablement on the subgraph, for the improvements listed above or others on the roadmap? Is BuilderDAO the right partner to do this work? Do people see value in per-round delegator stake and earnings tracking?
Rick Staa 9 days ago
Promoted To Roadmap
Suggest Ecosystem Projects
Next
Subgraph Audit & Stake/Earnings Indexing
What Is The Problem? The Livepeer subgraph, the data layer that every Explorer view, governance surface, delegator tool, and tokenomics analysis depends on, has not had a structured audit in a long time, so we lack a current baseline of its performance, technical debt, and indexing gaps before building further on top of it. The concrete first gap: the subgraph cannot efficiently compute delegator or orchestrator stake and earnings per round, which holds back income and tax reporting and any time series view. Why Does It Matter To the Livepeer Ecosystem? The subgraph is shared infrastructure used by all downstream surfaces, so its performance and correctness affect every consumer. The work is two steps. First, audit the subgraph and add tooling to measure size and indexing performance, giving us a known baseline before adding more to it. Second, ship the per-round stake and earnings feature on that base. BuilderDAO already identified performance improvements while building two earlier features for us, so concrete issues already exist. Auditing first lets this feature and later additions be implemented and measured against a known baseline rather than added to an unmeasured one. Without it, we have no visibility into whether new features are implemented efficiently or are adding technical debt, since we cannot measure their impact. What Does Success Look Like? Repeatable tooling to measure subgraph size and indexing performance, runnable locally and in CI, with a baseline captured. The audit produces a named, prioritized list of indexing gaps, missing or mis-modelled events, and technical debt, so future work can build on a known foundation. Per-round delegator and orchestrator stake and earnings are indexed, accurate, and queryable, with a linked deployment and sample query. Explorer maintainers confirm the indexed data can power income and earnings views. Open Questions Does anyone see objections to doing the audit first to unlock quicker feature enablement on the subgraph, for the improvements listed above or others on the roadmap? Is BuilderDAO the right partner to do this work? Do people see value in per-round delegator stake and earnings tracking?
Rick Staa 9 days ago
Promoted To Roadmap
Suggest Ecosystem Projects
Pipeline SDK
1. General Proposed By: Rick Staa Proposed On: 2026-05-11 Owner: Rick (Technical Director, Livepeer Foundation) Funding Mechanism: RFP, Network Engineering SPE 2. What Is The Problem? The BYOC work delivered under the AI SPE made it possible for the community to run custom containers on the Livepeer network for the first time. The gap that remains is the one above the protocol: packaging a new AI pipeline into a BYOC-compatible container is still core-developer work. A builder must either rebuild the orchestrator-side plumbing (trickle channels, healthcheck state machine, capability registration, etc.) from scratch, or merge pipeline-specific code into go-livepeer / ai-runner and wait for a core review. There is no abstraction layer in between, which prohibits the quick demand experiments the community wants to run, the kind much needed to gather real-world data and inform improvements to the core network stack. 3. Why It Matters To the Livepeer Ecosystem The Foundation's mission is to help the community build out Livepeer's vision: an open network the community itself extends. Any developer or community member should be able to ship demand-side experiments without being bottlenecked by core engineering reviews or having to write custom plumbing for every new pipeline. The end state we're aiming for: A developer, builder, or provider with no prior Livepeer experience makes their first Video AI API call in under 5 minutes from Claude, Cursor, or any MCP-compatible tool. Any orchestrator deploys new pipelines through a self-serve, well-documented BYOC interface. No Foundation in the loop at any step. Getting there requires several enablers: strong developer documentation, easy-to-use SDKs, payment abstractions, live network data, a performant runtime, and strong agent compatibility. Livepeer Cloud has improved the data landscape under their last proposal. Under the Transformation SPE, the community has already shipped a number of these on the demand side: the remote signer separated payments from the gateway, and the Python gateway SDK removed the need for gateway-specific code in go-livepeer. A builder can now send paid jobs to orchestrators without running the go-livepeer gateway — Scope is already using this path for onboarding their workflow. Further work on the gateway side of the SDK will be proposed under the new Developer SPE as its own opportunity, and payment abstractions will be addressed by John in a separate SPE proposal. Creating a new pipeline, however, still requires deep knowledge of the core stack and a fair bit of engineering work to get the plumbing right. The Pipeline SDK is the abstraction that closes that gap: an opinionated, class-based Python interface — similar to how Cog and comparable ecosystems handle this — that lets a builder produce a BYOC-compatible container an orchestrator can pull and run, with the communication schemas set by the core software and no plumbing to rebuild or core review to wait on. It is an opinionated path designed to speed up the developer journey on top of an unopinionated core — builders with more complex requirements can still target the BYOC communication schemas directly. A small tech spec on this approach lives here, and an initial prototype has been built to showcase it works. Before the SDK is ready to put in front of the wider developer community for real-world testing, gaps remain around documentation, stability, ease of use, and a CLI surface for benchmarking and publishing. Cost of waiting: without this SDK running in parallel with the runtime and core improvements, the demand experiments that would inform that work never happen — leaving the next wave of network changes to be designed without the real-world data they need. Out of scope for this opportunity: More complex pipelines beyond the opinionated SDK pattern — multi-endpoint routing, non-standard schemas, or anything requiring runtime-side support. Some can be built today using the SDK's lower-level communication packages inside a custom BYOC container; others depend on the orchestrator runtime improvements below. Client-side SDK and payment abstractions — both tracked under separate SPE proposals (see above). Orchestrator runtime improvements — auto-loading containers, hot-swapping between pipelines, capability-based routing. Tracked separately. This SDK uses the runtime's communication schemas to provide a higher-level abstraction; the runtime evolves independently. Live network data improvements — part of a separate opportunity. Broader developer-experience and agent enablement work beyond what is directly tied to the SDK and its containers — wider documentation overhauls, agent integrations outside the SDK surface, and tooling not part of the pipeline lifecycle. 4. What Does Success Look Like? A community builder can go from pip install to a Livepeer-compatible container that an orchestrator can pull and run in under five minutes, single take, fresh environment. A community-agreed, stable v1 of the developer interface is published and locked — the MVP every other deliverable builds against. Once locked, community builders can adopt the SDK without fearing breaking changes, and future runtime improvements stay backward-compatible with it. A new pipeline can be packaged without hand-written Dockerfiles or registration boilerplate, and the resulting container attaches to orchestrators automatically when pulled — no manual registration step. A livepeer CLI ships with the SDK that lets a builder (a) benchmark a pipeline container's performance locally against a synthetic workload before publishing, and (b) push the built image to Docker Hub in the format orchestrators can discover and pull — no hand-rolled Dockerfiles, no manual tagging conventions. The SDK is agent-native: a published AGENTS.md + LLMs.txt (or equivalent agent-readable convention files) describe the SDK to coding agents, and an optional local SDK server exposes the SDK to MCP-compatible tools so a developer can build, test, and publish a new pipeline using AI assistance in under five minutes. A dedicated example-pipelines repository carries a curated suite of reference pipelines (covering the current hello_world, live_tint, live_detect, live_transcribe, image_upscale, llm, sentiment cases plus broader workloads added over time). Every example builds and runs against a real orchestrator using only the SDK — no go-livepeer fork, no ai-runner change — and serves as the canonical "copy this to start" surface for new builders. Scope plus at least one additional external builder confirm the end-to-end path from their own workstation. 5. What Are The Open Questions? Does an opinionated SDK layer for pipeline authoring and packaging provide enough value over raw BYOC/custom containers to justify prioritizing developer ergonomics now, or should the ecosystem focus first on maximizing applications and usage on the network to better inform runtime evolution? Should “Client SDK” work be included in this scope (or handled as a separate opportunity)? Decision needed: include a minimal client-SDK delta that directly supports the five-minute path, or keep client SDK explicitly out of scope and track it as its own SPE-backed proposal with clear dependency mapping. What is the exact shape of the developer interface? What should the base classes and lifecycle hooks expose — method names, return contracts, parameter-update patterns, error handling, init/teardown surface? The current prototype is one shape; locking v1 means agreeing on the ergonomics, especially across builders with different pipeline patterns (streaming vs batch vs multi-modal). Should capability registration be auto-wrapped in the container? Two design options: (a) the wrapped container self-registers on start using env variables the orchestrator sets at runtime, or (b) registration stays an explicit orchestrator-side step. Affects how seamless the "attaches automatically when pulled" claim is in practice. Is heartbeat the right uptime signal? Today the SDK uses heartbeat-based reporting to let orchestrators know the container is alive and serving. Open whether that is the best mechanism — or whether pull-based health probes, event-driven status, or a hybrid would be more reliable and lower-overhead for orchestrators running many pipelines. How do we coordinate schema evolution with the core software? The SDK's communication schemas are set by go-livepeer / ai-runner, which will keep evolving under the orchestrator runtime opportunity. Need a coordination protocol between this opportunity and that one so v1 doesn't fracture when the runtime changes. Should v1 be designed with multi-language SDKs in mind? Python-only at v1. Whether the v1 contract should be designed for TypeScript / Go SDKs from the start, or stay Python-first and abstract later, is a design choice that affects how much portability the contract bakes in.
Rick Staa about 1 month ago
Community Feedback
Suggest Ecosystem Projects
Pipeline SDK
1. General Proposed By: Rick Staa Proposed On: 2026-05-11 Owner: Rick (Technical Director, Livepeer Foundation) Funding Mechanism: RFP, Network Engineering SPE 2. What Is The Problem? The BYOC work delivered under the AI SPE made it possible for the community to run custom containers on the Livepeer network for the first time. The gap that remains is the one above the protocol: packaging a new AI pipeline into a BYOC-compatible container is still core-developer work. A builder must either rebuild the orchestrator-side plumbing (trickle channels, healthcheck state machine, capability registration, etc.) from scratch, or merge pipeline-specific code into go-livepeer / ai-runner and wait for a core review. There is no abstraction layer in between, which prohibits the quick demand experiments the community wants to run, the kind much needed to gather real-world data and inform improvements to the core network stack. 3. Why It Matters To the Livepeer Ecosystem The Foundation's mission is to help the community build out Livepeer's vision: an open network the community itself extends. Any developer or community member should be able to ship demand-side experiments without being bottlenecked by core engineering reviews or having to write custom plumbing for every new pipeline. The end state we're aiming for: A developer, builder, or provider with no prior Livepeer experience makes their first Video AI API call in under 5 minutes from Claude, Cursor, or any MCP-compatible tool. Any orchestrator deploys new pipelines through a self-serve, well-documented BYOC interface. No Foundation in the loop at any step. Getting there requires several enablers: strong developer documentation, easy-to-use SDKs, payment abstractions, live network data, a performant runtime, and strong agent compatibility. Livepeer Cloud has improved the data landscape under their last proposal. Under the Transformation SPE, the community has already shipped a number of these on the demand side: the remote signer separated payments from the gateway, and the Python gateway SDK removed the need for gateway-specific code in go-livepeer. A builder can now send paid jobs to orchestrators without running the go-livepeer gateway — Scope is already using this path for onboarding their workflow. Further work on the gateway side of the SDK will be proposed under the new Developer SPE as its own opportunity, and payment abstractions will be addressed by John in a separate SPE proposal. Creating a new pipeline, however, still requires deep knowledge of the core stack and a fair bit of engineering work to get the plumbing right. The Pipeline SDK is the abstraction that closes that gap: an opinionated, class-based Python interface — similar to how Cog and comparable ecosystems handle this — that lets a builder produce a BYOC-compatible container an orchestrator can pull and run, with the communication schemas set by the core software and no plumbing to rebuild or core review to wait on. It is an opinionated path designed to speed up the developer journey on top of an unopinionated core — builders with more complex requirements can still target the BYOC communication schemas directly. A small tech spec on this approach lives here, and an initial prototype has been built to showcase it works. Before the SDK is ready to put in front of the wider developer community for real-world testing, gaps remain around documentation, stability, ease of use, and a CLI surface for benchmarking and publishing. Cost of waiting: without this SDK running in parallel with the runtime and core improvements, the demand experiments that would inform that work never happen — leaving the next wave of network changes to be designed without the real-world data they need. Out of scope for this opportunity: More complex pipelines beyond the opinionated SDK pattern — multi-endpoint routing, non-standard schemas, or anything requiring runtime-side support. Some can be built today using the SDK's lower-level communication packages inside a custom BYOC container; others depend on the orchestrator runtime improvements below. Client-side SDK and payment abstractions — both tracked under separate SPE proposals (see above). Orchestrator runtime improvements — auto-loading containers, hot-swapping between pipelines, capability-based routing. Tracked separately. This SDK uses the runtime's communication schemas to provide a higher-level abstraction; the runtime evolves independently. Live network data improvements — part of a separate opportunity. Broader developer-experience and agent enablement work beyond what is directly tied to the SDK and its containers — wider documentation overhauls, agent integrations outside the SDK surface, and tooling not part of the pipeline lifecycle. 4. What Does Success Look Like? A community builder can go from pip install to a Livepeer-compatible container that an orchestrator can pull and run in under five minutes, single take, fresh environment. A community-agreed, stable v1 of the developer interface is published and locked — the MVP every other deliverable builds against. Once locked, community builders can adopt the SDK without fearing breaking changes, and future runtime improvements stay backward-compatible with it. A new pipeline can be packaged without hand-written Dockerfiles or registration boilerplate, and the resulting container attaches to orchestrators automatically when pulled — no manual registration step. A livepeer CLI ships with the SDK that lets a builder (a) benchmark a pipeline container's performance locally against a synthetic workload before publishing, and (b) push the built image to Docker Hub in the format orchestrators can discover and pull — no hand-rolled Dockerfiles, no manual tagging conventions. The SDK is agent-native: a published AGENTS.md + LLMs.txt (or equivalent agent-readable convention files) describe the SDK to coding agents, and an optional local SDK server exposes the SDK to MCP-compatible tools so a developer can build, test, and publish a new pipeline using AI assistance in under five minutes. A dedicated example-pipelines repository carries a curated suite of reference pipelines (covering the current hello_world, live_tint, live_detect, live_transcribe, image_upscale, llm, sentiment cases plus broader workloads added over time). Every example builds and runs against a real orchestrator using only the SDK — no go-livepeer fork, no ai-runner change — and serves as the canonical "copy this to start" surface for new builders. Scope plus at least one additional external builder confirm the end-to-end path from their own workstation. 5. What Are The Open Questions? Does an opinionated SDK layer for pipeline authoring and packaging provide enough value over raw BYOC/custom containers to justify prioritizing developer ergonomics now, or should the ecosystem focus first on maximizing applications and usage on the network to better inform runtime evolution? Should “Client SDK” work be included in this scope (or handled as a separate opportunity)? Decision needed: include a minimal client-SDK delta that directly supports the five-minute path, or keep client SDK explicitly out of scope and track it as its own SPE-backed proposal with clear dependency mapping. What is the exact shape of the developer interface? What should the base classes and lifecycle hooks expose — method names, return contracts, parameter-update patterns, error handling, init/teardown surface? The current prototype is one shape; locking v1 means agreeing on the ergonomics, especially across builders with different pipeline patterns (streaming vs batch vs multi-modal). Should capability registration be auto-wrapped in the container? Two design options: (a) the wrapped container self-registers on start using env variables the orchestrator sets at runtime, or (b) registration stays an explicit orchestrator-side step. Affects how seamless the "attaches automatically when pulled" claim is in practice. Is heartbeat the right uptime signal? Today the SDK uses heartbeat-based reporting to let orchestrators know the container is alive and serving. Open whether that is the best mechanism — or whether pull-based health probes, event-driven status, or a hybrid would be more reliable and lower-overhead for orchestrators running many pipelines. How do we coordinate schema evolution with the core software? The SDK's communication schemas are set by go-livepeer / ai-runner, which will keep evolving under the orchestrator runtime opportunity. Need a coordination protocol between this opportunity and that one so v1 doesn't fracture when the runtime changes. Should v1 be designed with multi-language SDKs in mind? Python-only at v1. Whether the v1 contract should be designed for TypeScript / Go SDKs from the start, or stay Python-first and abstract later, is a design choice that affects how much portability the contract bakes in.
Rick Staa about 1 month ago
Community Feedback
Suggest Ecosystem Projects
Now
Improve Protocol Security Practices
Opportunity Issued: Q4 2025 (initial term through H1 2026) Roadmap State: Now Term: Initial up to six months · Six-Month Review & Renewal Assessment in Q2 2026 Owner: Foundation (program & treasury) · Security Committee (oversight) · Sidestream (Protocol Engineering & Security Partner) Funding: SPE 1. Purpose What specific problem does this solve? How does it align with and advance the vision? Why now? All network value depends on protocol security. The Livepeer protocol secures significant on-chain value that continues to grow as the network expands into real-time AI video inference — but the current security and protocol-engineering model relies on Livepeer Inc and places a heavy load on the Security Committee. That dependency constrains core feature development, slows protocol progress, and concentrates operational risk in a small group of people who already carry too much. The Protocol R&D SPE resolves this by establishing a professional, continuously staffed function responsible for vulnerability triage, safe upgrade preparation, and shipping additional protocol features — including a reliable public testnet for rigorous validation. It contracts a dedicated Protocol Engineering & Security Partner (Sidestream) under the joint governance of the Livepeer Foundation and the Security Committee. Why now: Immunefi has historically protected tens of millions in protocol value at $75–100k/year in payouts, but first-response and patch-implementation capacity remain bottlenecked. The SPE turns that bottleneck into a durable, accountable structure as the network decentralises. 2. Outcome What does overall success look like? What are the tangible key results? Mission: the most secure, resilient, and continuously improving protocol foundations possible for Livepeer, at the best possible price-to-value ratio. Overall success is when the Foundation and Security Committee can point to a single, accountable structure that (a) detects and resolves vulnerabilities on a known clock, (b) ships protocol upgrades from the existing backlog without further Security Committee overload, and (c) operates a public testnet that the rest of the ecosystem actively uses for validation. Key Results (H1 2026): Continuous Immunefi coverage — valid reports acknowledged within 24 hours, triaged within one week; critical issues resolved or escalated within agreed timelines. At least one backlog feature or patch deployed to mainnet per release cycle — drawn from the protocol R&D pipeline. Public testnet live with ≥99% uptime — faucet, CI integration, reproducible deployment tooling, actively used by developer and client teams. Foundation protocol engineer hired by end of Q1 2026 — supporting development and triage coordination. Six-Month Review — performance and financial review concluded by the SPE Board in Q2 2026; results published; renewal proposal prepared. 3. Requirements Must Have Protocol Engineering & Security Partner contracted and operational (Sidestream) — security and triage procedures aligned with the Security Committee. First-response capability for Immunefi reports — reproduce, validate, propose patches in coordination with the Foundation Technical Lead and the Security Committee. Lightweight triage pipeline — established and used to prioritise and sequence backlog work each release cycle. Backlog deployment — Reward Call Delegation, Ticket Distinction, inflation-bounds Minter upgrade, upgradable Minter proxy architecture, and stability patches shipped to mainnet on a release cadence. Public testnet — continuously available, with faucet, CI integration, and simulation tooling. Audits line item — significant protocol changes receive appropriate security review before deployment. Multisig SAFE — funds held with a threshold of trusted signers from the Foundation and Security Committee. Quarterly readiness reviews — strengthening detection, response time, and coordination. Quarterly public reporting — transparency on operations, milestones, and spend. Should Have Foundation protocol engineer onboarded by end of Q1 2026 — supports triage, coordination, and reduces single-partner dependency. Reproducible deployment + virtualised upgrade simulation tooling — extends governor-scripts work already delivered under prior grants. Devnet / private-net workflows — clear documentation so client and integration teams can test before mainnet. Foundation-managed Immunefi payouts in the short term — preserves treasury capital for other strategic initiatives. Nice to Have Ticket Distinction full implementation — pending ecosystem input on the existing spec + PoC. Payment Clearinghouse Distinction, Stablecoin Payments, Vote Delegation, TransferBond Recipient Approvals, anti-reward-farming mechanisms — candidate backlog items, subject to triage. Cross-chain liquidity / bridging improvements — explored only where security guarantees are preserved. Out of Scope (this SPE) Final upgrade authorisation and execution — retained by the Security Committee as the final security checkpoint. Operational details of security practices — not published; held within the Security Committee and Partner. Inflation parameter changes and other governance-driven protocol changes — surfaced via triage but executed under separate community / LIP processes. Already Shipped / In Flight (under prior Sidestream grants) Inflation-bounds Minter update implemented. Upgradable Minter proxy architecture designed and tested. Two independent implementations of Reward Call Delegation. Multiple Immunefi submissions reproduced, analysed, and mitigations proposed. governor-scripts tooling extended for reproducible deployments and upgrade simulations. Ticket Distinction preliminary spec + PoC complete. 4. Key Milestones Milestone Target Description Partner Onboarding Completed Q4 2025 Sidestream contracted and operational; security and triage procedures aligned with the Security Committee. Continuous Immunefi Vulnerability Response All of H1 2026 Full first-response capability: reproduce, propose fixes, coordinate Security Committee review, ensure continuous coverage. Public Testnet Live Q1 2026 Stable, persistent public testnet with faucet, CI integration, and reproducible deployment tooling. Triage Pipeline Established & First Upgrade Shipped Q1 2026 Lightweight triage process established and validated by at least one feature or protocol upgrade shipped to mainnet. Triage Pipeline Updated & Additional Upgrade Shipped Q2 2026 At least one additional upgrade triaged and deployed to mainnet. Six-Month Review & Renewal Assessment Q2 2026 Performance and financial review concluded by the SPE Board; results shared publicly; renewal proposal prepared. 6. Risks & Open Questions Single-partner dependency — Sidestream is the sole contracted Partner; Foundation protocol engineer hire (end of Q1 2026) is the primary mitigation. Security Committee load — the SPE reduces but does not eliminate it; quarterly readiness reviews track whether the load actually moves. Treasury exposure to Immunefi payouts — Foundation covers in the short term; long-term funding source for bounties is an open design question. Backlog sequencing — selecting which backlog features ship each cycle requires the lightweight triage process to land early; otherwise the SPE delivers without prioritisation rigour. Testnet adoption — ≥99% uptime is necessary but not sufficient; success requires developer and client teams to actually use it. Renewal decision — the six-month review must produce a clear go/no-go signal with public reasoning, not a default extension.
Rich O'Grady about 1 month ago
In Progress
Suggest Ecosystem Projects
Now
Improve Protocol Security Practices
Opportunity Issued: Q4 2025 (initial term through H1 2026) Roadmap State: Now Term: Initial up to six months · Six-Month Review & Renewal Assessment in Q2 2026 Owner: Foundation (program & treasury) · Security Committee (oversight) · Sidestream (Protocol Engineering & Security Partner) Funding: SPE 1. Purpose What specific problem does this solve? How does it align with and advance the vision? Why now? All network value depends on protocol security. The Livepeer protocol secures significant on-chain value that continues to grow as the network expands into real-time AI video inference — but the current security and protocol-engineering model relies on Livepeer Inc and places a heavy load on the Security Committee. That dependency constrains core feature development, slows protocol progress, and concentrates operational risk in a small group of people who already carry too much. The Protocol R&D SPE resolves this by establishing a professional, continuously staffed function responsible for vulnerability triage, safe upgrade preparation, and shipping additional protocol features — including a reliable public testnet for rigorous validation. It contracts a dedicated Protocol Engineering & Security Partner (Sidestream) under the joint governance of the Livepeer Foundation and the Security Committee. Why now: Immunefi has historically protected tens of millions in protocol value at $75–100k/year in payouts, but first-response and patch-implementation capacity remain bottlenecked. The SPE turns that bottleneck into a durable, accountable structure as the network decentralises. 2. Outcome What does overall success look like? What are the tangible key results? Mission: the most secure, resilient, and continuously improving protocol foundations possible for Livepeer, at the best possible price-to-value ratio. Overall success is when the Foundation and Security Committee can point to a single, accountable structure that (a) detects and resolves vulnerabilities on a known clock, (b) ships protocol upgrades from the existing backlog without further Security Committee overload, and (c) operates a public testnet that the rest of the ecosystem actively uses for validation. Key Results (H1 2026): Continuous Immunefi coverage — valid reports acknowledged within 24 hours, triaged within one week; critical issues resolved or escalated within agreed timelines. At least one backlog feature or patch deployed to mainnet per release cycle — drawn from the protocol R&D pipeline. Public testnet live with ≥99% uptime — faucet, CI integration, reproducible deployment tooling, actively used by developer and client teams. Foundation protocol engineer hired by end of Q1 2026 — supporting development and triage coordination. Six-Month Review — performance and financial review concluded by the SPE Board in Q2 2026; results published; renewal proposal prepared. 3. Requirements Must Have Protocol Engineering & Security Partner contracted and operational (Sidestream) — security and triage procedures aligned with the Security Committee. First-response capability for Immunefi reports — reproduce, validate, propose patches in coordination with the Foundation Technical Lead and the Security Committee. Lightweight triage pipeline — established and used to prioritise and sequence backlog work each release cycle. Backlog deployment — Reward Call Delegation, Ticket Distinction, inflation-bounds Minter upgrade, upgradable Minter proxy architecture, and stability patches shipped to mainnet on a release cadence. Public testnet — continuously available, with faucet, CI integration, and simulation tooling. Audits line item — significant protocol changes receive appropriate security review before deployment. Multisig SAFE — funds held with a threshold of trusted signers from the Foundation and Security Committee. Quarterly readiness reviews — strengthening detection, response time, and coordination. Quarterly public reporting — transparency on operations, milestones, and spend. Should Have Foundation protocol engineer onboarded by end of Q1 2026 — supports triage, coordination, and reduces single-partner dependency. Reproducible deployment + virtualised upgrade simulation tooling — extends governor-scripts work already delivered under prior grants. Devnet / private-net workflows — clear documentation so client and integration teams can test before mainnet. Foundation-managed Immunefi payouts in the short term — preserves treasury capital for other strategic initiatives. Nice to Have Ticket Distinction full implementation — pending ecosystem input on the existing spec + PoC. Payment Clearinghouse Distinction, Stablecoin Payments, Vote Delegation, TransferBond Recipient Approvals, anti-reward-farming mechanisms — candidate backlog items, subject to triage. Cross-chain liquidity / bridging improvements — explored only where security guarantees are preserved. Out of Scope (this SPE) Final upgrade authorisation and execution — retained by the Security Committee as the final security checkpoint. Operational details of security practices — not published; held within the Security Committee and Partner. Inflation parameter changes and other governance-driven protocol changes — surfaced via triage but executed under separate community / LIP processes. Already Shipped / In Flight (under prior Sidestream grants) Inflation-bounds Minter update implemented. Upgradable Minter proxy architecture designed and tested. Two independent implementations of Reward Call Delegation. Multiple Immunefi submissions reproduced, analysed, and mitigations proposed. governor-scripts tooling extended for reproducible deployments and upgrade simulations. Ticket Distinction preliminary spec + PoC complete. 4. Key Milestones Milestone Target Description Partner Onboarding Completed Q4 2025 Sidestream contracted and operational; security and triage procedures aligned with the Security Committee. Continuous Immunefi Vulnerability Response All of H1 2026 Full first-response capability: reproduce, propose fixes, coordinate Security Committee review, ensure continuous coverage. Public Testnet Live Q1 2026 Stable, persistent public testnet with faucet, CI integration, and reproducible deployment tooling. Triage Pipeline Established & First Upgrade Shipped Q1 2026 Lightweight triage process established and validated by at least one feature or protocol upgrade shipped to mainnet. Triage Pipeline Updated & Additional Upgrade Shipped Q2 2026 At least one additional upgrade triaged and deployed to mainnet. Six-Month Review & Renewal Assessment Q2 2026 Performance and financial review concluded by the SPE Board; results shared publicly; renewal proposal prepared. 6. Risks & Open Questions Single-partner dependency — Sidestream is the sole contracted Partner; Foundation protocol engineer hire (end of Q1 2026) is the primary mitigation. Security Committee load — the SPE reduces but does not eliminate it; quarterly readiness reviews track whether the load actually moves. Treasury exposure to Immunefi payouts — Foundation covers in the short term; long-term funding source for bounties is an open design question. Backlog sequencing — selecting which backlog features ship each cycle requires the lightweight triage process to land early; otherwise the SPE delivers without prioritisation rigour. Testnet adoption — ≥99% uptime is necessary but not sufficient; success requires developer and client teams to actually use it. Renewal decision — the six-month review must produce a clear go/no-go signal with public reasoning, not a default extension.
Rich O'Grady about 1 month ago
In Progress
Suggest Ecosystem Projects
Developer Community Activation Program (Emerging Markets Focus)
Suggestion: I’d like to propose a structured Developer Community Activation Program aimed at driving adoption of tools like Daydream across emerging markets, starting with Nigeria and expanding across Africa. There is a rapidly growing base of developers and creators in these regions who are actively exploring video, AI, and onchain tools, but there is currently low awareness and limited onboarding support for platforms like Daydream. Proposed Approach: Launch grassroots initiatives led by local developer advocates Host webinars, bootcamps, and live demos focused on: Video creation workflows using Daydream API integrations into real-world applications Develop localized tutorials and starter projects Encourage community-led feedback loops to inform product direction Why This Matters: Unlocks a high-growth, under-tapped developer market Drives real usage of Daydream APIs beyond passive awareness Provides direct feedback from new user segments Strengthens Livepeer’s ecosystem positioning globally Execution Model (Lean): Start as a pilot in 1–2 regions (e.g., Nigeria) Community-led, low-cost experimentation Measure traction via: Developer onboarding API usage interest Event participation Scale based on validated engagement Additional Context: I’m currently engaging with developers in Nigeria and am willing to help initiate and document early traction from this region as part of a pilot. Outcome: If successful, this can evolve into a repeatable model for global community-driven growth and developer adoption.
Gideon Jones 2 months ago
Suggest Ecosystem Projects
Developer Community Activation Program (Emerging Markets Focus)
Suggestion: I’d like to propose a structured Developer Community Activation Program aimed at driving adoption of tools like Daydream across emerging markets, starting with Nigeria and expanding across Africa. There is a rapidly growing base of developers and creators in these regions who are actively exploring video, AI, and onchain tools, but there is currently low awareness and limited onboarding support for platforms like Daydream. Proposed Approach: Launch grassroots initiatives led by local developer advocates Host webinars, bootcamps, and live demos focused on: Video creation workflows using Daydream API integrations into real-world applications Develop localized tutorials and starter projects Encourage community-led feedback loops to inform product direction Why This Matters: Unlocks a high-growth, under-tapped developer market Drives real usage of Daydream APIs beyond passive awareness Provides direct feedback from new user segments Strengthens Livepeer’s ecosystem positioning globally Execution Model (Lean): Start as a pilot in 1–2 regions (e.g., Nigeria) Community-led, low-cost experimentation Measure traction via: Developer onboarding API usage interest Event participation Scale based on validated engagement Additional Context: I’m currently engaging with developers in Nigeria and am willing to help initiate and document early traction from this region as part of a pilot. Outcome: If successful, this can evolve into a repeatable model for global community-driven growth and developer adoption.
Gideon Jones 2 months ago
Suggest Ecosystem Projects
Now
Website & Primer Refresh
Proposed By: Adam Soffer, Steph Alinsug Staging URL: https://livepeer-website.vercel.app 1. What Is The Problem? Livepeer's website is out of date, falls short of professional standards, and the embedded Primer only tells the transcoding story — failing to communicate what Livepeer actually is today (a real-time AI video infrastructure network) and leaving developers, ecosystem partners, and community members without a credible entry point that reflects the project's current direction and ambition. 2. Why It Matters To the Livepeer Ecosystem Livepeer is at an inflection point: the real-time AI video opportunity is real, Daydream is live, and the gateway platform is taking shape — but the primary public-facing surfaces tell a years-old story and don't reflect the quality of the work being done. Every week they stay up, they undermine trust with developers evaluating the network, partners doing due diligence, and community members trying to articulate what Livepeer is. The window matters because the AI video market is forming now, and first impressions with the right builders will compound. 3. What Does Success Look Like? Developers landing on livepeer.org understand within 60 seconds what Livepeer is today — a real-time AI video infrastructure network — who it's for, and how to get started The Primer functions as a standalone, shareable explainer covering the full scope of Livepeer's evolution, not just transcoding The Foundation has a live, professionally presented surface to iterate copy and positioning
Adam Soffer 3 months ago
In Progress
Live Projects
Now
Website & Primer Refresh
Proposed By: Adam Soffer, Steph Alinsug Staging URL: https://livepeer-website.vercel.app 1. What Is The Problem? Livepeer's website is out of date, falls short of professional standards, and the embedded Primer only tells the transcoding story — failing to communicate what Livepeer actually is today (a real-time AI video infrastructure network) and leaving developers, ecosystem partners, and community members without a credible entry point that reflects the project's current direction and ambition. 2. Why It Matters To the Livepeer Ecosystem Livepeer is at an inflection point: the real-time AI video opportunity is real, Daydream is live, and the gateway platform is taking shape — but the primary public-facing surfaces tell a years-old story and don't reflect the quality of the work being done. Every week they stay up, they undermine trust with developers evaluating the network, partners doing due diligence, and community members trying to articulate what Livepeer is. The window matters because the AI video market is forming now, and first impressions with the right builders will compound. 3. What Does Success Look Like? Developers landing on livepeer.org understand within 60 seconds what Livepeer is today — a real-time AI video infrastructure network — who it's for, and how to get started The Primer functions as a standalone, shareable explainer covering the full scope of Livepeer's evolution, not just transcoding The Foundation has a live, professionally presented surface to iterate copy and positioning
Adam Soffer 3 months ago
In Progress
Live Projects
In Progress
Network Engineering SPE: Funding Smaller Initiatives
This roadmap item was discussed during the latest Water Cooler. The overlap Onchain Treasury Allocation Improvements should be recognised, but potentially works alongside it as a short-term solution. 1. What is the problem to solve? The current SPE model creates significant friction for smaller, community-driven engineering contributions: Writing a full proposal requires a major time investment before any work begins The onchain vote cycle adds weeks or months of delay for work that could start quickly For scoped initiatives in the $2k–$20k range, the overhead-to-value ratio is simply too poor — community contributors won't run a full SPE process at that scale This friction has become more acute as AI tools now allow contributors to build and test MVPs far faster than before The result: genuinely useful, well-supported work doesn't happen — not because the community doesn't want it, but because there's no efficient path to fund it. 2. Why is solving this problem key to the Livepeer ecosystem? Smaller experimental initiatives and quick engineering wins are often where early, high-signal progress happens. If the only funding path available requires months of process overhead, contributors either work for free, deprioritize the work, or move on entirely. Losing active contributors — and the compounding value of their momentum — is a real cost to the ecosystem. A more frictionless path to funding smaller initiatives would align disbursement with the natural cadence of community proposals and keep contributors engaged and productive. 3. What could success look like? A delegated, standing funding pool for small-to-medium engineering initiatives, validated through the existing community roadmap process, where: Contributors can apply for funding for quick wins and experiments without the full weight of a standalone SPE Decisions are made transparently and without unnecessary bureaucracy Funding speed matches the speed at which good ideas can now be executed The above is just a potential solution and it is all open for discussion. 4. What are the outstanding questions to discuss? Does this problem resonate — are there contributors who've shelved ideas because the SPE path felt too heavy? What's the right pool size on a quarterly basis to be meaningful without being wasteful? Should the funding mechanism be proactive, retroactive, or some mix depending on the type of initiative? What governance structure makes sense — a multi-sig of trusted core contributors, or direct community votes on individual projects? How does this fit into broader discussions on the onchain treasury, and is a short-term experiment worthwhile regardless? Who should be eligible — public goods only, or should demand bets and other initiative types be in scope too? Note: this has been elaborated and proposed by Rich O’Grady based on prior Water Cooler discussions, but does not represent a Foundation priority.
Rich O'Grady 3 months ago
Coming Soon
Live Projects
In Progress
Network Engineering SPE: Funding Smaller Initiatives
This roadmap item was discussed during the latest Water Cooler. The overlap Onchain Treasury Allocation Improvements should be recognised, but potentially works alongside it as a short-term solution. 1. What is the problem to solve? The current SPE model creates significant friction for smaller, community-driven engineering contributions: Writing a full proposal requires a major time investment before any work begins The onchain vote cycle adds weeks or months of delay for work that could start quickly For scoped initiatives in the $2k–$20k range, the overhead-to-value ratio is simply too poor — community contributors won't run a full SPE process at that scale This friction has become more acute as AI tools now allow contributors to build and test MVPs far faster than before The result: genuinely useful, well-supported work doesn't happen — not because the community doesn't want it, but because there's no efficient path to fund it. 2. Why is solving this problem key to the Livepeer ecosystem? Smaller experimental initiatives and quick engineering wins are often where early, high-signal progress happens. If the only funding path available requires months of process overhead, contributors either work for free, deprioritize the work, or move on entirely. Losing active contributors — and the compounding value of their momentum — is a real cost to the ecosystem. A more frictionless path to funding smaller initiatives would align disbursement with the natural cadence of community proposals and keep contributors engaged and productive. 3. What could success look like? A delegated, standing funding pool for small-to-medium engineering initiatives, validated through the existing community roadmap process, where: Contributors can apply for funding for quick wins and experiments without the full weight of a standalone SPE Decisions are made transparently and without unnecessary bureaucracy Funding speed matches the speed at which good ideas can now be executed The above is just a potential solution and it is all open for discussion. 4. What are the outstanding questions to discuss? Does this problem resonate — are there contributors who've shelved ideas because the SPE path felt too heavy? What's the right pool size on a quarterly basis to be meaningful without being wasteful? Should the funding mechanism be proactive, retroactive, or some mix depending on the type of initiative? What governance structure makes sense — a multi-sig of trusted core contributors, or direct community votes on individual projects? How does this fit into broader discussions on the onchain treasury, and is a short-term experiment worthwhile regardless? Who should be eligible — public goods only, or should demand bets and other initiative types be in scope too? Note: this has been elaborated and proposed by Rich O’Grady based on prior Water Cooler discussions, but does not represent a Foundation priority.
Rich O'Grady 3 months ago
Coming Soon
Live Projects
Onchain Treasury Allocation Improvements
Establish norms, processes, and accountability mechanisms for how the onchain treasury is allocated — ensuring capital flows to highest-impact ecosystem activities. Problem Statement: Now that the treasury rate cut is back online we need a prioritization criteria for the deployment of funds, a formal framework for projects where resource allocation is the key decision point, and a broader accountability framework that alleviates previous community concerns about the ROI of deployed funds Scope Define what treasury funds should and shouldn't be used for - eg. align treasury allocation priorities to Roadmap items Establish norms and an evaluation framework for proposals (if needed) Establish a process for use of RFPs, such that funds can be secured before RFP teams are chosen Set performance, transparency and reporting norms for funded projects Key Questions to Answer How are Roadmap items suggested and determined? What are the real differences between "Roadmap-aligned" vs. speculative proposals? What should be used to evaluate proposals? How can an RFP process work in advance of deployed funding given the onchain execution of the treasury? What does performance, transparency and reporting look like post-funding? What group should be engaged to best answer and propose action on the items above? Out of Scope: Size of treasury reward cut rate itself (separate LIP can be further created if needed) Success Criteria: Community-ratified norms published; new treasury proposals evaluated as per norms, future funded projects deliver as per norms
Admin Team 3 months ago
Discussion Closed
Suggest Ecosystem Projects
Onchain Treasury Allocation Improvements
Establish norms, processes, and accountability mechanisms for how the onchain treasury is allocated — ensuring capital flows to highest-impact ecosystem activities. Problem Statement: Now that the treasury rate cut is back online we need a prioritization criteria for the deployment of funds, a formal framework for projects where resource allocation is the key decision point, and a broader accountability framework that alleviates previous community concerns about the ROI of deployed funds Scope Define what treasury funds should and shouldn't be used for - eg. align treasury allocation priorities to Roadmap items Establish norms and an evaluation framework for proposals (if needed) Establish a process for use of RFPs, such that funds can be secured before RFP teams are chosen Set performance, transparency and reporting norms for funded projects Key Questions to Answer How are Roadmap items suggested and determined? What are the real differences between "Roadmap-aligned" vs. speculative proposals? What should be used to evaluate proposals? How can an RFP process work in advance of deployed funding given the onchain execution of the treasury? What does performance, transparency and reporting look like post-funding? What group should be engaged to best answer and propose action on the items above? Out of Scope: Size of treasury reward cut rate itself (separate LIP can be further created if needed) Success Criteria: Community-ratified norms published; new treasury proposals evaluated as per norms, future funded projects deliver as per norms
Admin Team 3 months ago
Discussion Closed
Suggest Ecosystem Projects
In Progress
Foundation - Map Market Landscape
Purpose What is the specific business problem that this solves? How does this align with and advance the vision? And why should we be working on this now? Livepeer needs to define its core opportunity which can form the foundation of a GTM effort. Since its launch in 2017, Livepeer’s mission has been to offer the world’s open video infrastructure, building a respected and trusted brand rooted in decentralized video technology enabled by cryptoeconomic primitives. More recently, Livepeer has expanded into AI through multiple ecosystem initiatives, but without a dedicated GTM effort to unify them around a clear network value proposition. Defining the core opportunity now is necessary to align these efforts, focus resources, and prevent further fragmentation as the ecosystem grows. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Success means delivering a detailed market intelligence report which can be used for lead generation. Building on detailed interviews with prospective customers, the report should equip the Livepeer ecosystem with a clear overview of the market landscape and a breakdown of ideal customer profiles (ICPs) with clear value propositions for each. All of the work should tee up the core teams behind the Livepeer network’s GTM. For Network ProdEng, the report should provide direction for core requirements and competitor benchmarking. For Livepeer Marketing, it should give clear ICPs to target. For BD, it should provide a pipeline of potential customers and the basis for a sales deck. Key Metrics To Measure The Outcome Against: Engagement from content pieces published Number of new customer opportunities identified Total number of new customer interviews Leads generated by the report
Admin Team 3 months ago
In Progress
Live Projects
In Progress
Foundation - Map Market Landscape
Purpose What is the specific business problem that this solves? How does this align with and advance the vision? And why should we be working on this now? Livepeer needs to define its core opportunity which can form the foundation of a GTM effort. Since its launch in 2017, Livepeer’s mission has been to offer the world’s open video infrastructure, building a respected and trusted brand rooted in decentralized video technology enabled by cryptoeconomic primitives. More recently, Livepeer has expanded into AI through multiple ecosystem initiatives, but without a dedicated GTM effort to unify them around a clear network value proposition. Defining the core opportunity now is necessary to align these efforts, focus resources, and prevent further fragmentation as the ecosystem grows. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Success means delivering a detailed market intelligence report which can be used for lead generation. Building on detailed interviews with prospective customers, the report should equip the Livepeer ecosystem with a clear overview of the market landscape and a breakdown of ideal customer profiles (ICPs) with clear value propositions for each. All of the work should tee up the core teams behind the Livepeer network’s GTM. For Network ProdEng, the report should provide direction for core requirements and competitor benchmarking. For Livepeer Marketing, it should give clear ICPs to target. For BD, it should provide a pipeline of potential customers and the basis for a sales deck. Key Metrics To Measure The Outcome Against: Engagement from content pieces published Number of new customer opportunities identified Total number of new customer interviews Leads generated by the report
Admin Team 3 months ago
In Progress
Live Projects
In Progress
Network-As-A-Product: Foundational Metrics & Platform
(November → February) Output: A dashboard with an overview of core network data (aligned with Cloud SPE). To Ship: Gateway audit; automated network testing and visibility; metrics collector; network-wide orchestrator data dashboard. Enables: Dashboard overview with key network data; gateway manager dashboard with SLA configuration. Features & User Stories Network Data As a network user, I can see an overview of core metrics NaaP Platform As a network user, I can understand what the NaaP Platform is and how to get involved
Admin Team 3 months ago
In Progress
NaaP
In Progress
Network-As-A-Product: Foundational Metrics & Platform
(November → February) Output: A dashboard with an overview of core network data (aligned with Cloud SPE). To Ship: Gateway audit; automated network testing and visibility; metrics collector; network-wide orchestrator data dashboard. Enables: Dashboard overview with key network data; gateway manager dashboard with SLA configuration. Features & User Stories Network Data As a network user, I can see an overview of core metrics NaaP Platform As a network user, I can understand what the NaaP Platform is and how to get involved
Admin Team 3 months ago
In Progress
NaaP
Completed
Transformation SPE - Improve Capital Management
Purpose What is the specific business problem that this solves? How does this align with and advance the vision? And why should we be working on this now? Livepeer has acute pain points around current capital. On chain liquidity is low, leaking value of LPT holders through high slippage. Inflation is high against external benchmarks, which acts as a barrier to new participants. The treasury is not accumulating new LPT and the current treasury is not actively deployed and so does not generate any yield. We need to address all of this in a holistic way now, as actions in one area can have unintended second-order consequences if not managed carefully. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Overview: Overall success is creating a working group that collaborates to assess the ecosystem holistically, enabling clear decision-making and actively managing ecosystem capital through more strategic deployment. Key Metrics To Measure The Outcome Against: Improvements in liquidity depth and market efficiency. Reduction of treasury concentration risk and clearer capital allocation strategy. Measurable progress toward sustainable inflation and data-driven utility models.
Admin Team 3 months ago
Completed
Live Projects
Completed
Transformation SPE - Improve Capital Management
Purpose What is the specific business problem that this solves? How does this align with and advance the vision? And why should we be working on this now? Livepeer has acute pain points around current capital. On chain liquidity is low, leaking value of LPT holders through high slippage. Inflation is high against external benchmarks, which acts as a barrier to new participants. The treasury is not accumulating new LPT and the current treasury is not actively deployed and so does not generate any yield. We need to address all of this in a holistic way now, as actions in one area can have unintended second-order consequences if not managed carefully. Outcome What does overall success look like in one paragraph? And what are some of the tangible key results that the submissions should focus on? Overview: Overall success is creating a working group that collaborates to assess the ecosystem holistically, enabling clear decision-making and actively managing ecosystem capital through more strategic deployment. Key Metrics To Measure The Outcome Against: Improvements in liquidity depth and market efficiency. Reduction of treasury concentration risk and clearer capital allocation strategy. Measurable progress toward sustainable inflation and data-driven utility models.
Admin Team 3 months ago
Completed
Live Projects