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 9 days ago

1

Suggestion Proposed

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 9 days ago

Suggestion Proposed

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 10 days ago

Suggestion Proposed

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 16 days ago

Community Feedback

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 16 days ago

Community Feedback

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

1. General Proposed By: Rick Staa Proposed On: 2026-05-11 Owner: Rick (Technical Director, Livepeer Foundation) Funding Mechanism: RFP, Network Engineering SPE 2. What Is The Problem? The BYOC work delivered under the AI SPE made it possible for the community to run custom containers on the Livepeer network for the first time. The gap that remains is the one above the protocol: packaging a new AI pipeline into a BYOC-compatible container is still core-developer work. A builder must either rebuild the orchestrator-side plumbing (trickle channels, healthcheck state machine, capability registration, etc.) from scratch, or merge pipeline-specific code into go-livepeer / ai-runner and wait for a core review. There is no abstraction layer in between, which prohibits the quick demand experiments the community wants to run, the kind much needed to gather real-world data and inform improvements to the core network stack. 3. Why It Matters To the Livepeer Ecosystem The Foundation's mission is to help the community build out Livepeer's vision: an open network the community itself extends. Any developer or community member should be able to ship demand-side experiments without being bottlenecked by core engineering reviews or having to write custom plumbing for every new pipeline. The end state we're aiming for: A developer, builder, or provider with no prior Livepeer experience makes their first Video AI API call in under 5 minutes from Claude, Cursor, or any MCP-compatible tool. Any orchestrator deploys new pipelines through a self-serve, well-documented BYOC interface. No Foundation in the loop at any step. Getting there requires several enablers: strong developer documentation, easy-to-use SDKs, payment abstractions, live network data, a performant runtime, and strong agent compatibility. Livepeer Cloud has improved the data landscape under their last proposal. Under the Transformation SPE, the community has already shipped a number of these on the demand side: the remote signer separated payments from the gateway, and the Python gateway SDK removed the need for gateway-specific code in go-livepeer. A builder can now send paid jobs to orchestrators without running the go-livepeer gateway — Scope is already using this path for onboarding their workflow. Further work on the gateway side of the SDK will be proposed under the new Developer SPE as its own opportunity, and payment abstractions will be addressed by John in a separate SPE proposal. Creating a new pipeline, however, still requires deep knowledge of the core stack and a fair bit of engineering work to get the plumbing right. The Pipeline SDK is the abstraction that closes that gap: an opinionated, class-based Python interface — similar to how

Rick Staa 3 months ago

Discussion Closed

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

Opportunity Issued: Q4 2025 (initial term through H1 2026) Roadmap State: Now Term: Initial up to six months · Six-Month Review & Renewal Assessment in Q2 2026 Owner: Foundation (program & treasury) · Security Committee (oversight) · Sidestream (Protocol Engineering & Security Partner) Funding: SPE 1. Purpose What specific problem does this solve? How does it align with and advance the vision? Why now? All network value depends on protocol security. The Livepeer protocol secures significant on-chain value that continues to grow as the network expands into real-time AI video inference — but the current security and protocol-engineering model relies on Livepeer Inc and places a heavy load on the Security Committee. That dependency constrains core feature development, slows protocol progress, and concentrates operational risk in a small group of people who already carry too much. The Protocol R&D SPE resolves this by establishing a professional, continuously staffed function responsible for vulnerability triage, safe upgrade preparation, and shipping additional protocol features — including a reliable public testnet for rigorous validation. It contracts a dedicated Protocol Engineering & Security Partner (Sidestream) under the joint governance of the Livepeer Foundation and the Security Committee. Why now: Immunefi has historically protected tens of millions in protocol value at $75–100k/year in payouts, but first-response and patch-implementation capacity remain bottlenecked. The SPE turns that bottleneck into a durable, accountable structure as the network decentralises. 2. Outcome What does overall success look like? What are the tangible key results? Mission: the most secure, resilient, and continuously improving protocol foundations possible for Livepeer, at the best possible price-to-value ratio. Overall success is when the Foundation and Security Committee can point to a single, accountable structure that (a) detects and resolves vulnerabilities on a known clock, (b) ships protocol upgrades from the existing backlog without further Security Committee overload, and (c) operates a public testnet that the rest of the ecosystem actively uses for validation. Key Results (H1 2026): Continuous Immunefi coverage — valid reports acknowledged within 24 hours, triaged within one week; critical issues resolved or escalated within agreed timelines. At least one backlog feature or patch deployed to mainnet per release cycle — drawn from the protocol R&D pipeline. Public testnet live with ≥99% uptime — faucet, CI integration, reproducible deployment tooling, actively used by developer and client teams. Foundation protocol engineer hired by end of Q1 2026 — supporting development and triage coordination. Six-Month Review — performance and financial review concluded by the SPE Board in Q2 2026; results published; renewal proposal prepared. 3. Requirements Must Have Protocol Engineering & Security Partner contracted and operational (Sidestream) — security and triage procedures aligned with the Security Committee. First-response capability for Immunefi reports — reproduce, validate, propose patches in coordination with the Foundation

Rich O'Grady 3 months ago

Jun 30

In Progress

Suggestion: I’d like to propose a structured Developer Community Activation Program aimed at driving adoption of tools like Daydream across emerging markets, starting with Nigeria and expanding across Africa. There is a rapidly growing base of developers and creators in these regions who are actively exploring video, AI, and onchain tools, but there is currently low awareness and limited onboarding support for platforms like Daydream. Proposed Approach: Launch grassroots initiatives led by local developer advocates Host webinars, bootcamps, and live demos focused on: Video creation workflows using Daydream API integrations into real-world applications Develop localized tutorials and starter projects Encourage community-led feedback loops to inform product direction Why This Matters: Unlocks a high-growth, under-tapped developer market Drives real usage of Daydream APIs beyond passive awareness Provides direct feedback from new user segments Strengthens Livepeer’s ecosystem positioning globally Execution Model (Lean): Start as a pilot in 1–2 regions (e.g., Nigeria) Community-led, low-cost experimentation Measure traction via: Developer onboarding API usage interest Event participation Scale based on validated engagement Additional Context: I’m currently engaging with developers in Nigeria and am willing to help initiate and document early traction from this region as part of a pilot. Outcome: If successful, this can evolve into a repeatable model for global community-driven growth and developer adoption.

Gideon Jones 4 months ago

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

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 5 months ago

Coming Soon

Establish norms, processes, and accountability mechanisms for how the onchain treasury is allocated — ensuring capital flows to highest-impact ecosystem activities. Problem Statement: Now that the treasury rate cut is back online we need a prioritization criteria for the deployment of funds, a formal framework for projects where resource allocation is the key decision point, and a broader accountability framework that alleviates previous community concerns about the ROI of deployed funds Scope Define what treasury funds should and shouldn't be used for - eg. align treasury allocation priorities to Roadmap items Establish norms and an evaluation framework for proposals (if needed) Establish a process for use of RFPs, such that funds can be secured before RFP teams are chosen Set performance, transparency and reporting norms for funded projects Key Questions to Answer How are Roadmap items suggested and determined? What are the real differences between "Roadmap-aligned" vs. speculative proposals? What should be used to evaluate proposals? How can an RFP process work in advance of deployed funding given the onchain execution of the treasury? What does performance, transparency and reporting look like post-funding? What group should be engaged to best answer and propose action on the items above? Out of Scope: Size of treasury reward cut rate itself (separate LIP can be further created if needed) Success Criteria: Community-ratified norms published; new treasury proposals evaluated as per norms, future funded projects deliver as per norms

Admin Team 5 months ago

1

Discussion Closed