Completed
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
Rick Staa 4 months ago
Promoted To Roadmap
Live Projects
Completed
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
Rick Staa 4 months ago
Promoted To Roadmap
Live Projects
Completed
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
Rick Staa 4 months ago
Promoted To Roadmap
Live Projects
Completed
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
Rick Staa 4 months ago
Promoted To Roadmap
Live Projects
In Progress
Network Readiness For Livepeer Agent
Roadmap state: Now Opportunity Status: In progress Owned By: Qiang Han Funding Mechanisms: Livepeer Foundation, Livepeer Inc + Network engineering funding SPE 1. Purpose For the Agent to run at scale, the network has to be ready: orchestrator software, capability onboarding, quality of service, and payments clearing. This opportunity resources the five-milestone framework work that gets a cohort of community orchestrators live onchain on the new stack, opening future demand paths beyond the Agent. 2. Outcome Overview: A cohort of community orchestrators is live onchain running the new software, capabilities are adapted and standardised, performance is observable, and payments clearinghouse work is underway. Key Metrics To Measure The Outcome Against: Five to eight community orchestrators onboard capabilities end to end and report success Real traffic routed to onboarded orchestrators, with performance observable Payments clearinghouse work underway 3. Requirements Live Runner and Go SDK shipped as a production release No-code, config-based capability onboarding exposed to operators Real-world validation: real traffic and feedback from onboarded operators Quality-of-service monitoring with routing by measured performance Billing and metering that fits every pricing model, with the Daydream key requirement removed Community and in-house dashboards
Admin Team 16 days ago
In Progress
Live Projects
In Progress
Network Readiness For Livepeer Agent
Roadmap state: Now Opportunity Status: In progress Owned By: Qiang Han Funding Mechanisms: Livepeer Foundation, Livepeer Inc + Network engineering funding SPE 1. Purpose For the Agent to run at scale, the network has to be ready: orchestrator software, capability onboarding, quality of service, and payments clearing. This opportunity resources the five-milestone framework work that gets a cohort of community orchestrators live onchain on the new stack, opening future demand paths beyond the Agent. 2. Outcome Overview: A cohort of community orchestrators is live onchain running the new software, capabilities are adapted and standardised, performance is observable, and payments clearinghouse work is underway. Key Metrics To Measure The Outcome Against: Five to eight community orchestrators onboard capabilities end to end and report success Real traffic routed to onboarded orchestrators, with performance observable Payments clearinghouse work underway 3. Requirements Live Runner and Go SDK shipped as a production release No-code, config-based capability onboarding exposed to operators Real-world validation: real traffic and feedback from onboarded operators Quality-of-service monitoring with routing by measured performance Billing and metering that fits every pricing model, with the Daydream key requirement removed Community and in-house dashboards
Admin Team 16 days ago
In Progress
Live Projects
In Progress
Validating Livepeer 2.0 Upgrades & Litepaper
Roadmap state: Now Opportunity Status: In progress Owned By: Doug Petkanics, Livepeer Inc Funding Mechanism: Funding from Livepeer Inc / Foundation 1. Purpose Livepeer 2.0 has presented a series of key protocol changes: Burn-Mint Equilibrium, the stake-elected validator set, fixed node bonds, and extended unbonding. These now must be specified, simulated, and supported by the community before any upgrade vote. This opportunity resources the design and governance process that gets us there, carrying forward only upgrades with demonstrated support. 2. Outcome Overview: The 2.0 design is specified, simulated, and supported. The litepaper has been public for a month, the community process has worked through the open questions, and an economic simulation is completem. The completion will open the door to core protocol development and an audit before an LIP package is proposed. Key Metrics To Measure The Outcome Against: Litepaper published and public for at least four weeks, with open questions worked through Economic simulation completed and observable by the community Only upgrades with demonstrated community support carried into an LIP package 3. Requirements Opinionated litepaper specifying recommended mechanisms and initial parameters Structured community feedback period that resolves the open questions Protocol prototype simulation using agents to play network roles, observable by the community Security hardening and audit path defined for candidate production code Clear governance route from supported design to an LIP package Migration plan outline for moving the network fully onto 2.0
Admin Team 16 days ago
In Progress
Live Projects
In Progress
Validating Livepeer 2.0 Upgrades & Litepaper
Roadmap state: Now Opportunity Status: In progress Owned By: Doug Petkanics, Livepeer Inc Funding Mechanism: Funding from Livepeer Inc / Foundation 1. Purpose Livepeer 2.0 has presented a series of key protocol changes: Burn-Mint Equilibrium, the stake-elected validator set, fixed node bonds, and extended unbonding. These now must be specified, simulated, and supported by the community before any upgrade vote. This opportunity resources the design and governance process that gets us there, carrying forward only upgrades with demonstrated support. 2. Outcome Overview: The 2.0 design is specified, simulated, and supported. The litepaper has been public for a month, the community process has worked through the open questions, and an economic simulation is completem. The completion will open the door to core protocol development and an audit before an LIP package is proposed. Key Metrics To Measure The Outcome Against: Litepaper published and public for at least four weeks, with open questions worked through Economic simulation completed and observable by the community Only upgrades with demonstrated community support carried into an LIP package 3. Requirements Opinionated litepaper specifying recommended mechanisms and initial parameters Structured community feedback period that resolves the open questions Protocol prototype simulation using agents to play network roles, observable by the community Security hardening and audit path defined for candidate production code Clear governance route from supported design to an LIP package Migration plan outline for moving the network fully onto 2.0
Admin Team 16 days ago
In Progress
Live Projects
Livepeer 2.0 - Introducing Validators
1. General Proposed By: Doug Petkanics Proposed On: 30 July 2026 Based On: Validators 2.0 — forum thread 2. What Is The Problem? The proposal: Livepeer 2.0 splits today's orchestrator role in two. Node operators post a bond, run hardware, compete for work, and earn fees. Validators are elected by delegated stake, perform no work, and score node operators between 0 and 1.0. The median score sets each node's reward multiplier. Validators also carry governance and treasury votes. The problem: The yield cut runs on a fixed calendar. The fee growth meant to replace that yield does not. Validators and delegators are being asked to give up known income now against modelled income later, with nothing tying the two together. 3. Why Does It Matter To the Livepeer Ecosystem? What the validator set is for. Under BME, node rewards flow in proportion to fees generated. That creates a direct incentive to manufacture fake fee volume. Model inference has no cheap universal proof the way transcoding did, so someone has to exercise judgment. The validator set is that judgment. Delegated stake is what makes it expensive to capture. What the cut puts at risk. The proposal removes ~$4M/year of inflation, roughly 9% yield, before demand-driven value capture has shown up. LPT is at 52-week lows after a ~79% drawdown, and yield has been the main thing holding the delegator base through it. If fees do not scale on schedule: Delegators lose yield and get no appreciation in return. Node operators earn issuance worth more than the fees they generate. Bonded stake leaves the validator set. The third one is the real exposure. Cutting the yield lowers the cost of capturing the set, so the economics and the security budget move together. 4. What Does Success Look Like? Emissions decline is gated on the burn/mint ratio rather than a calendar. Set size and issuance share are modelled against a case where fees scale at half the expected rate. Bonded validator stake is flat or growing through the transition. A published sequencing plan shows yield changes tracking actual fee growth. 5. Open Questions How many validator slots should exist? Keeping today's top 100 is the cleanest migration and asks nothing of delegators. But we may not have 100 operators who want to actively score, and a large set spreads the issuance thin. A smaller set is easier to coordinate and cheaper to fund, and concentrates governance and scoring power. What size, or what mechanism for setting size, makes sense? How do we stop scoring becoming a popularity contest? Validators score independently by design, competing on judgment rather than copying each other. If the criteria stay opaque, delegators have no basis to choose between validators beyond reputation, and validators have every reason to converge on the median instead of scoring well. What happens to the existing orchestrator set at migration? The lean is continuity: orchestrators inherit validator slots, every node starts at 1.0, active scoring begins from there. A real election on day one is cleaner in principle but risks interrupting rewards for a delegator base that has never moved quickly. What penalties exist for poor validation? Today, none beyond losing the slot. The role is meant to be lucrative enough that keeping it is incentive enough, and de
Admin Team 16 days ago
Community Feedback
Suggest Ecosystem Projects
Livepeer 2.0 - Introducing Validators
1. General Proposed By: Doug Petkanics Proposed On: 30 July 2026 Based On: Validators 2.0 — forum thread 2. What Is The Problem? The proposal: Livepeer 2.0 splits today's orchestrator role in two. Node operators post a bond, run hardware, compete for work, and earn fees. Validators are elected by delegated stake, perform no work, and score node operators between 0 and 1.0. The median score sets each node's reward multiplier. Validators also carry governance and treasury votes. The problem: The yield cut runs on a fixed calendar. The fee growth meant to replace that yield does not. Validators and delegators are being asked to give up known income now against modelled income later, with nothing tying the two together. 3. Why Does It Matter To the Livepeer Ecosystem? What the validator set is for. Under BME, node rewards flow in proportion to fees generated. That creates a direct incentive to manufacture fake fee volume. Model inference has no cheap universal proof the way transcoding did, so someone has to exercise judgment. The validator set is that judgment. Delegated stake is what makes it expensive to capture. What the cut puts at risk. The proposal removes ~$4M/year of inflation, roughly 9% yield, before demand-driven value capture has shown up. LPT is at 52-week lows after a ~79% drawdown, and yield has been the main thing holding the delegator base through it. If fees do not scale on schedule: Delegators lose yield and get no appreciation in return. Node operators earn issuance worth more than the fees they generate. Bonded stake leaves the validator set. The third one is the real exposure. Cutting the yield lowers the cost of capturing the set, so the economics and the security budget move together. 4. What Does Success Look Like? Emissions decline is gated on the burn/mint ratio rather than a calendar. Set size and issuance share are modelled against a case where fees scale at half the expected rate. Bonded validator stake is flat or growing through the transition. A published sequencing plan shows yield changes tracking actual fee growth. 5. Open Questions How many validator slots should exist? Keeping today's top 100 is the cleanest migration and asks nothing of delegators. But we may not have 100 operators who want to actively score, and a large set spreads the issuance thin. A smaller set is easier to coordinate and cheaper to fund, and concentrates governance and scoring power. What size, or what mechanism for setting size, makes sense? How do we stop scoring becoming a popularity contest? Validators score independently by design, competing on judgment rather than copying each other. If the criteria stay opaque, delegators have no basis to choose between validators beyond reputation, and validators have every reason to converge on the median instead of scoring well. What happens to the existing orchestrator set at migration? The lean is continuity: orchestrators inherit validator slots, every node starts at 1.0, active scoring begins from there. A real election on day one is cleaner in principle but risks interrupting rewards for a delegator base that has never moved quickly. What penalties exist for poor validation? Today, none beyond losing the slot. The role is meant to be lucrative enough that keeping it is incentive enough, and de
Admin Team 16 days ago
Community Feedback
Suggest Ecosystem Projects
In Progress
Simplify Billing & Payments With Livepeer Clearinghouse
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 o
John Mull 5 months ago
Promoted To Roadmap
Live Projects
In Progress
Simplify Billing & Payments With Livepeer Clearinghouse
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 o
John Mull 5 months ago
Promoted To Roadmap
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 6 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 6 months ago
In Progress
Live Projects
Livepeer-backed LoRA Pilot: Creator GPU Workspaces for Training and Inference
1. General Proposed By: Michal Vavak Proposed On: August 4th, 2026 2. What Is The Problem? Creators who want to train and use LoRAs must currently assemble fragmented GPU infrastructure, storage, model-management tools, training environments, inference interfaces, and media workflows themselves. LoRA Pilot already provides an integrated, open-source workspace covering dataset preparation, model management, LoRA training, batch testing, inference, and media workflows, but creators still need to find and configure suitable GPU infrastructure independently. Livepeer does not yet offer a clear, creator-friendly path from GPU capacity to a complete persistent AI workspace. The missing layer is therefore not another isolated inference endpoint. It is a reliable way for creators to launch a complete LoRA Pilot workspace on Livepeer-connected GPU capacity. 3. Why Does It Matter To the Livepeer Ecosystem? This would give Livepeer an existing creator-facing application and workload rather than only another infrastructure component. LoRA Pilot has an established open-source project, more than 10,000 Docker Hub pulls, and support for almost 30 model families for training. It connects several workflows that creators need together: dataset creation, training, model testing, inference, and media management. A Livepeer-backed workspace could: create recurring demand for Livepeer GPU capacity; bring Stable Diffusion and LoRA creators into the Livepeer ecosystem; provide a practical test case for persistent GPU sessions, BYOC, storage, and model distribution; create reusable API foundations for multiple Stable Diffusion and video endpoints; reduce the time and technical knowledge required to use Livepeer for real creative work; provide evidence about which creator workloads, hardware profiles, and runtime patterns the network should support. This aligns with Livepeer’s current focus on reducing developer friction through the Five-Minute API, enabling custom containers through BYOC, and turning GPU infrastructure into usable real-time AI applications. It also complements the existing ComfyStream/LoRA direction, where Stable Diffusion and LoRA workflows are being tested as hosted network applications. Five-Minute API roadmap item, ComfyStream/LoRA experiment Without this layer, Livepeer risks having capable GPU infrastructure that remains difficult for creators to access and difficult for creator applications to adopt. 4. What Does Success Look Like? Success is a creator or operator being able to launch a documented, persistent LoRA Pilot workspace on Livepeer-backed GPU capacity and complete the full workflow from dataset to trained LoRA to generated media without manually rebuilding the environment. Initial success could be measured by: a versioned Livepeer-first LoRA Pi
Michal Vavak 15 days ago
Suggestion Proposed
Suggest Ecosystem Projects
Livepeer-backed LoRA Pilot: Creator GPU Workspaces for Training and Inference
1. General Proposed By: Michal Vavak Proposed On: August 4th, 2026 2. What Is The Problem? Creators who want to train and use LoRAs must currently assemble fragmented GPU infrastructure, storage, model-management tools, training environments, inference interfaces, and media workflows themselves. LoRA Pilot already provides an integrated, open-source workspace covering dataset preparation, model management, LoRA training, batch testing, inference, and media workflows, but creators still need to find and configure suitable GPU infrastructure independently. Livepeer does not yet offer a clear, creator-friendly path from GPU capacity to a complete persistent AI workspace. The missing layer is therefore not another isolated inference endpoint. It is a reliable way for creators to launch a complete LoRA Pilot workspace on Livepeer-connected GPU capacity. 3. Why Does It Matter To the Livepeer Ecosystem? This would give Livepeer an existing creator-facing application and workload rather than only another infrastructure component. LoRA Pilot has an established open-source project, more than 10,000 Docker Hub pulls, and support for almost 30 model families for training. It connects several workflows that creators need together: dataset creation, training, model testing, inference, and media management. A Livepeer-backed workspace could: create recurring demand for Livepeer GPU capacity; bring Stable Diffusion and LoRA creators into the Livepeer ecosystem; provide a practical test case for persistent GPU sessions, BYOC, storage, and model distribution; create reusable API foundations for multiple Stable Diffusion and video endpoints; reduce the time and technical knowledge required to use Livepeer for real creative work; provide evidence about which creator workloads, hardware profiles, and runtime patterns the network should support. This aligns with Livepeer’s current focus on reducing developer friction through the Five-Minute API, enabling custom containers through BYOC, and turning GPU infrastructure into usable real-time AI applications. It also complements the existing ComfyStream/LoRA direction, where Stable Diffusion and LoRA workflows are being tested as hosted network applications. Five-Minute API roadmap item, ComfyStream/LoRA experiment Without this layer, Livepeer risks having capable GPU infrastructure that remains difficult for creators to access and difficult for creator applications to adopt. 4. What Does Success Look Like? Success is a creator or operator being able to launch a documented, persistent LoRA Pilot workspace on Livepeer-backed GPU capacity and complete the full workflow from dataset to trained LoRA to generated media without manually rebuilding the environment. Initial success could be measured by: a versioned Livepeer-first LoRA Pi
Michal Vavak 15 days ago
Suggestion Proposed
Suggest Ecosystem Projects
In Progress
Agent Product Launch & GTM Exploration
Roadmap state: Now Opportunity Status: In progress Owned By: Steph Alinsug, Livepeer Foundation Funding Mechanism: Foundation & Inc funded + go-to-market funding proposal, informed by validation evidence 1. Purpose Livepeer Agent is a custom MCP connector for creators and marketers who need agents to generate, edit, and augment video affordably, across models, with high creative control. This opportunity validates it with real target users in public and drives it from closed alpha to open beta, so any go-to-market funding proposal is grounded in demand evidence rather than promises. 2. Outcome Overview: Target-user validation is explored in public and reflected in the product's core capabilities and user experience. Livepeer Agent is in open beta with its first weeks of real market data to inform the direction of the GTM. Key Metrics To Measure The Outcome Against: Successful install and repeated runs of the core loop: prompt → generate → output Closed beta cohort activated and converting into repeated use Open beta market data captured, or explicit launch gates defined 3. Requirements Demand-validation interviews with target creators and marketers, surfaced publicly One-click install paired with an automated onboarding funnel Closed beta launched at the in-person demo (NYC Creative AI Forum) Content and growth engine producing weekly market signal First weeks of open beta market data Go-to-market funding proposal informed by validation evidence
Admin Team 16 days ago
In Progress
Live Projects
In Progress
Agent Product Launch & GTM Exploration
Roadmap state: Now Opportunity Status: In progress Owned By: Steph Alinsug, Livepeer Foundation Funding Mechanism: Foundation & Inc funded + go-to-market funding proposal, informed by validation evidence 1. Purpose Livepeer Agent is a custom MCP connector for creators and marketers who need agents to generate, edit, and augment video affordably, across models, with high creative control. This opportunity validates it with real target users in public and drives it from closed alpha to open beta, so any go-to-market funding proposal is grounded in demand evidence rather than promises. 2. Outcome Overview: Target-user validation is explored in public and reflected in the product's core capabilities and user experience. Livepeer Agent is in open beta with its first weeks of real market data to inform the direction of the GTM. Key Metrics To Measure The Outcome Against: Successful install and repeated runs of the core loop: prompt → generate → output Closed beta cohort activated and converting into repeated use Open beta market data captured, or explicit launch gates defined 3. Requirements Demand-validation interviews with target creators and marketers, surfaced publicly One-click install paired with an automated onboarding funnel Closed beta launched at the in-person demo (NYC Creative AI Forum) Content and growth engine producing weekly market signal First weeks of open beta market data Go-to-market funding proposal informed by validation evidence
Admin Team 16 days ago
In Progress
Live Projects
Livepeer 2.0 - Impact On Node Operators
The Foundation would like to invite those interested to give direct feedback to Doug and the 2.0 vision during a roadmap session on Thursday. This particular session will discuss the impacts of Livepeer 2.0 on Node Operators, synthesizing and discussing the topics being discussed in the forum post: https://forum.livepeer.org/t/node-operator-2-0-topic-specific-thread/3309. Some of the open questions include: What’s the initial fixed bond amount for node operation? What’s the role of delegated stake in posting fixed node operator bonds? Does buying multiple node slots == more work and more LPT rewards? Should the node operator unbonding period by 90 rounds, or some other value? What are the incentives for node operators operating long tail services? What are the consequences of PM security with USD based pricing and a large # of nodes? Please share any structured thoughts or questions on the forum in advance, and we'll use this call to gain key community input.
Doug Petkanics 22 days ago
Community Feedback
Suggest Ecosystem Projects
Livepeer 2.0 - Impact On Node Operators
The Foundation would like to invite those interested to give direct feedback to Doug and the 2.0 vision during a roadmap session on Thursday. This particular session will discuss the impacts of Livepeer 2.0 on Node Operators, synthesizing and discussing the topics being discussed in the forum post: https://forum.livepeer.org/t/node-operator-2-0-topic-specific-thread/3309. Some of the open questions include: What’s the initial fixed bond amount for node operation? What’s the role of delegated stake in posting fixed node operator bonds? Does buying multiple node slots == more work and more LPT rewards? Should the node operator unbonding period by 90 rounds, or some other value? What are the incentives for node operators operating long tail services? What are the consequences of PM security with USD based pricing and a large # of nodes? Please share any structured thoughts or questions on the forum in advance, and we'll use this call to gain key community input.
Doug Petkanics 22 days ago
Community Feedback
Suggest Ecosystem Projects
Livepeer 2.0 - Impact On Delegators
The Foundation would like to invite those interested to give direct feedback to Doug and the 2.0 vision during a roadmap session on Thursday. This particular session call will discuss the impacts of Livepeer 2.0 on Delegators, synthesizing and discussing the topics being discussed in the forum post:t: https://forum.livepeer.org/t/delegators-2-0-topic-specific-thread/3300. These include: Mindset change amongst token holding delegators towards LPT being a value accruing token, with yield opportunities through validator delegation. Delegation towards node operators. Good idea or bad idea? Should existing stake during the migration to 2.0 be applied directly to the validator set? Please share any structured thoughts or questions on the forum in advance, and we'll use this call to gain key community input to inform the candidate protocol design as it impacts delegators.
Doug Petkanics 22 days ago
Community Feedback
Suggest Ecosystem Projects
Livepeer 2.0 - Impact On Delegators
The Foundation would like to invite those interested to give direct feedback to Doug and the 2.0 vision during a roadmap session on Thursday. This particular session call will discuss the impacts of Livepeer 2.0 on Delegators, synthesizing and discussing the topics being discussed in the forum post:t: https://forum.livepeer.org/t/delegators-2-0-topic-specific-thread/3300. These include: Mindset change amongst token holding delegators towards LPT being a value accruing token, with yield opportunities through validator delegation. Delegation towards node operators. Good idea or bad idea? Should existing stake during the migration to 2.0 be applied directly to the validator set? Please share any structured thoughts or questions on the forum in advance, and we'll use this call to gain key community input to inform the candidate protocol design as it impacts delegators.
Doug Petkanics 22 days ago
Community Feedback
Suggest Ecosystem Projects
Completed
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 analy
Rich O'Grady 3 months ago
Promoted To Roadmap
Suggest Ecosystem Projects
Completed
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 analy
Rich O'Grady 3 months 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
Doug Petkanics 3 months 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
Doug Petkanics 3 months ago
Discussion Closed
Suggest Ecosystem Projects
In Progress
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 5 months ago
In Progress
Live Projects
In Progress
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 5 months ago
In Progress
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 • c
Peter Schroedl 5 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 • c
Peter Schroedl 5 months ago
Discussion Closed
Suggest Ecosystem 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 t
Rich O'Grady 5 months ago
Promoted To Roadmap
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 t
Rich O'Grady 5 months ago
Promoted To Roadmap
Live 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 6 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 6 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 6 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 6 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 6 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 6 months ago
Coming Soon
NaaP
Setting Priorities For Network Engineering SPE II
1. General Proposed By: Rich O'Grady Proposed On: Tue 4 Aug 2026 2. What Is The Problem? As the funding for the pilot SPE has been allocated, we now need to retro the first months, gauge what needs to be funded, and what are the best mechanisms to fund the priorities. Before publishing a formal retro, the core SPE members wanted to give community contributors to raise feedback, concerns and ideas about the SPE’s operations and funding. By the end of the session, we hope to have a long list of priorities for the rest of the year and 3. Why Does It Matter To the Livepeer Ecosystem? The SPE plays a critical role in funding core network engineering and enabling demand bets on the network. It is the primary way to fund network engineering, particularly in smaller funding sizes (under $20k). It has a working track record to build the case on. With the first round of funding, it’s carried out work across agent experimentation, delegator experience, Explorer maintenance and network payments and billing as per the July update. A full retro will be published shortly. The primary questions is whether the SPE is pointed at the right targets. Livepeer 2.0 is a shift in direction towards an agent-first future. We want to ensure that the network adapts, while remaining relatively neutral to enable a variety of demand bets. 4. What Does Success Look Like? Livepeer agents run on the network with relative low-latency and observable performance data. Developers can build against the network without fighting the tooling or documentation. The supply side is adapted to the job types 2.0 introduces, not just the ones it inherited. New demand bets can be built on infrastructure that already exists, rather than waiting on it. Payments and billing run on standardised rates, not a bespoke integration per demand bet. 5. Open Questions What's actually worked about the Network Engineering SPE so far, and what hasn't? What should the SPE's priorities be for the rest of the year, given the shift to 2.0? What mechanisms (process, review, funding cadence) does that reprioritisation require?
Rich O'Grady 16 days ago
Community Feedback
Suggest Ecosystem Projects
Setting Priorities For Network Engineering SPE II
1. General Proposed By: Rich O'Grady Proposed On: Tue 4 Aug 2026 2. What Is The Problem? As the funding for the pilot SPE has been allocated, we now need to retro the first months, gauge what needs to be funded, and what are the best mechanisms to fund the priorities. Before publishing a formal retro, the core SPE members wanted to give community contributors to raise feedback, concerns and ideas about the SPE’s operations and funding. By the end of the session, we hope to have a long list of priorities for the rest of the year and 3. Why Does It Matter To the Livepeer Ecosystem? The SPE plays a critical role in funding core network engineering and enabling demand bets on the network. It is the primary way to fund network engineering, particularly in smaller funding sizes (under $20k). It has a working track record to build the case on. With the first round of funding, it’s carried out work across agent experimentation, delegator experience, Explorer maintenance and network payments and billing as per the July update. A full retro will be published shortly. The primary questions is whether the SPE is pointed at the right targets. Livepeer 2.0 is a shift in direction towards an agent-first future. We want to ensure that the network adapts, while remaining relatively neutral to enable a variety of demand bets. 4. What Does Success Look Like? Livepeer agents run on the network with relative low-latency and observable performance data. Developers can build against the network without fighting the tooling or documentation. The supply side is adapted to the job types 2.0 introduces, not just the ones it inherited. New demand bets can be built on infrastructure that already exists, rather than waiting on it. Payments and billing run on standardised rates, not a bespoke integration per demand bet. 5. Open Questions What's actually worked about the Network Engineering SPE so far, and what hasn't? What should the SPE's priorities be for the rest of the year, given the shift to 2.0? What mechanisms (process, review, funding cadence) does that reprioritisation require?
Rich O'Grady 16 days ago
Community Feedback
Suggest Ecosystem Projects