This is an overview of Suggestions made by Livepeer contributors. To suggest a roadmap item, a contributor should answer 3 core questions: What is the problem? Why does it matter for the ecosystem? What does success look like? Once someone has submitted an Suggestion, the Foundation will facilitate the process of scoping it further with the community until it is finalised and added to the roadmap.

Suggestion Submitted

Community Feedback

Community Vote

Promoted To Roadmap

Suggestions Pipeline

This roadmap item was discussed during the latest Water Cooler. The overlap <a target="" rel="noopener noreferrer nofollow" class="link" href="https://roadmap.livepeer.org/p/onchain-treasury-allocation-improvements">Onchain Treasury Allocation Improvements</a> should be recognised, but potentially works alongside it as a short-term solution.<h2>Objectives</h2>Create a delegated, standing funding pool for small-to-medium engineering initiatives validated through the community roadmap process.The aim is to reduce the friction for individual contributors and small teams to access funding for smaller, experimental engineering initiatives, aligning funding disbursement with the cadence of the community proposal and review process, as well as maintaining transparency and accountability without unnecessary bureaucracy.<div data-type="horizontalRule"><hr></div><h2>Problem</h2>The current SPE model works well for larger programs, but creates significant friction for smaller, community-driven engineering contributions:<ul><li>Writing a full SPE proposal requires a major time investment before any work begins</li><li>The onchain vote cycle adds weeks / months of delay for work that could otherwise start quickly</li><li>Community contributors are unlikely to run a full SPE process for a $2k–$20k scoped piece of work</li><li>The overhead-to-value ratio is poor below a certain funding threshold</li></ul>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.<div data-type="horizontalRule"><hr></div><h2>Potential Solution</h2>A Network Engineering SPE — a standing, delegated pool of capital that finances a rolling portfolio of smaller engineering initiatives sourced from the Livepeer community roadmap process. An initial funding period could be ~3 months with around $80-100k budget.Initiatives range from $2,000 to $20,000 and must originate from <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="http://roadmap.livepeer.org">roadmap.livepeer.org</a>. Each initiative must include a clear impact hypothesis — a falsifiable statement of what should change in the network and why it matters — and a verifiable deliverable agreed upfront before work begins.<ul><li>What gets funded: Protocol improvements, gateway and orchestrator tooling, observability, developer SDKs, integrations, and technical documentation — scoped for 1–3 contributors to complete in roughly 1–4 weeks.</li><li>How payment works: Scope and pricing are agreed before work starts; Tranche 1 is disbursed on verified technical completion, and Tranche 2 after a review period confirms the initiative's impact hypothesis has been borne out.</li><li>Governance: A 5-member SPE Council (including Orchestrators, Foundation, Livepeer Inc) reviews applications and signs off on payments, with all decisions published publicly with written rationale.</li></ul><img data-width="100%" data-align="left" alt="" data-featurebase-content-key="6908e89ba49bec81d940e862/post/69b05a0e7291f76b76b796e7/019cd8c9-d4bc-755e-84b6-4935cc28496d/b64u-aW1hZ2UucG5n.png" src="https://6908e89ba49bec81d940e862.featurebase-attachments.com/c/post/69b05a0e7291f76b76b796e7/019cd8c9-d4bc-755e-84b6-4935cc28496d/b64u-aW1hZ2UucG5n.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260319T050000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260319%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=5d5db823e4e12936d9ed9d29f7dad127a55ad9b30a32c8843fdd24620f163a75" data-featurebase-content-filename="image.png">The above is just a potential solution and it is all open for discussion.<h2>Outside of Scope</h2><ul><li>Small proposals that have not gone through the community roadmap validation process.</li><li>Work that requires a dedicated team with ongoing work.</li><li>Large, sustained programs ($20k–$150k+) — these should have a standalone SPE.</li><li>Foundation strategic priorities — funded directly by the Foundation.</li></ul><div data-type="horizontalRule"><hr></div><h2>Questions To Answer</h2><ol><li>Does the problem resonate? Are there contributors with ideas they haven't pursued because the standalone SPE path felt too heavy?</li><li>What's the right budget size? What 3-monthly pool would be meaningful without being wasteful?</li><li>What governance works best? Should the community vote on individual disbursements, or is Foundation discretion within the SPE mandate sufficient?</li><li>How does this fit in with broader discussions on onchain treasury? Is it worth an experiment in the short run?</li></ol>Note: this has been elaborated and proposed by Rich O’Grady based on prior Water Cooler discussions, but does not represent a Foundation priority.

Under Review

Suggestion Proposed

Funding Smaller Network Engineering Initiatives

Rich O'Grady

Proposed By: Adam Soffer, Steph Alinsug Staging URL: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://livepeer-website.vercel.app">https://livepeer-website.vercel.app</a> <h2>1. What Is The Problem?</h2>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.<div data-type="horizontalRule"><hr></div><h2>2. Why It Matters To the Livepeer Ecosystem</h2>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.<div data-type="horizontalRule"><hr></div><h2>3. What Does Success Look Like?</h2><ul><li>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</li><li>The Primer functions as a standalone, shareable explainer covering the full scope of Livepeer's evolution, not just transcoding</li><li>The Foundation has a live, professionally presented surface to iterate copy and positioning</li></ul>

Suggestion - Website & Primer Refresh

Adam Soffer

<h1>1. What is the problem?</h1>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 redeploymentThis creates two ecosystem issues:Limited flexibilityEven if GPUs have available capacity, orchestrators cannot easily switch between different pipeline types.Operational complexityRunning 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.<div data-type="horizontalRule"><hr></div><h1>2. Why does this matter to the ecosystem?</h1>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 GPUMulti-pipeline capability could improve:• revenue per GPU • revenue per orchestrator • supply flexibility across pipeline types • time-to-serve new AI workloadsWithout this flexibility, the network risks developing specialised supply that cannot adapt quickly to demand changes.<div data-type="horizontalRule"><hr></div><h1>3. Proposed experiment</h1>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.<div data-type="horizontalRule"><hr></div><h1>4. Demonstration application: ComfyMeme</h1>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:<pre><code>Giphy meme clip
→ frame extraction
→ Stable Diffusion + LoRA stylisation
→ animated meme output</code></pre>Memes are intentionally chosen because they are:• easy to understand • fast to generate • culturally shareable • capable of producing organic trafficThe demo therefore acts as both:• a public application • a stress test for multi-pipeline orchestration<div data-type="horizontalRule"><hr></div><h1>5. Relationship to ComfyStream Cloud</h1>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:<pre><code>creator → workflow JSON → user runs locally</code></pre>Workflows could become hosted services:<pre><code>creator → workflow → hosted endpoint → users</code></pre>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.<div data-type="horizontalRule"><hr></div><h1>6. Scope limitations</h1>This experiment intentionally avoids solving several large problems:• automatic model distribution • arbitrary workflow compatibility • creator monetisation infrastructureInstead, it assumes a curated model set preloaded on orchestrator nodes.The goal is simply to validate dynamic workflow execution on the network.<div data-type="horizontalRule"><hr></div><h1>7. Success criteria</h1>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 requestsAdoption signals:• at least three orchestrators running ComfyStreamEconomic signal:• at least one orchestrator earning revenue from two distinct pipeline types on a single GPU<div data-type="horizontalRule"><hr></div><h1>8. Deliverables</h1>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<div data-type="horizontalRule"><hr></div><h1>9. Expected duration</h1>Estimated timeline: 4–6 weeksThis includes:• building the demo application • orchestrator deployment testing • community demonstration • documentation of results<div data-type="horizontalRule"><hr></div><h1>10. Summary</h1>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 outcomesThe 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.

ComfyStream Multi-Pipeline Experiment + ComfyMeme Demo

Peter Schroedl

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<ul><li>Define what treasury funds should and shouldn't be used for - eg. align treasury allocation priorities to Roadmap items</li><li>Establish norms and an evaluation framework for proposals (if needed)</li><li>Establish a process for use of RFPs, such that funds can be secured before RFP teams are chosen</li><li>Set performance, transparency and reporting norms for funded projects</li></ul> Key Questions to Answer<ul><li>How are Roadmap items suggested and determined?</li><li>What are the real differences between "Roadmap-aligned" vs. speculative proposals?</li><li>What should be used to evaluate proposals?</li><li>How can an RFP process work in advance of deployed funding given the onchain execution of the treasury?</li><li>What does performance, transparency and reporting look like post-funding?</li><li>What group should be engaged to best answer and propose action on the items above?</li></ul> 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