Watercooler Chat -
Other Updates
🟣 Muxion Labs
<@&1303105760661606450>'s <@488172209823678474> created a new Daydream Comfy Custom Node with an updated interface. If you want to see it in action - watch this week's Watercooler Chat here! The link goes directly to the demo timestamp.
🏛️ Livepeer Foundation
Livepeer Foundation has been making progress towards the Transformation SPE goals:
- <@781667568942841866> posted progress on updating our documentation here
- <@537817645140017153> digested the feedback from the Inflation Survey here
- Guild has made improvements to the Explorer
Watch the most recent Fireside here.
Last Fireside's agenda:
- <@515896144560128000> from Embody Network updating on progress
- <@389895972102209551> from Embody Network presenting Embody AI creator
If you miss any events, check out our Youtube here.
Asking again: What do we want for Livepeer in 2026? Please drop your opinions in <#426106677650128898> 🦃🪞
Tune into our weekly Watercooler Chat to discuss pressing topics from community members.
---
Connect with Livepeer on Socials:
Twitter: https://twitter.com/Livepeer
Discord: https://discord.gg/uaPhtyrWsF
Telegram: https://t.me/livepeerorg
Reddit: https://www.reddit.com/r/livepeer/
Blog: https://medium.com/livepeer-blog
Forum: https://forum...
![\"Watercooler](\"https://i.ytimg.com/vi/9rZh5d_wRlI/maxresdefault.jpg\")
Hello all! Thank you for welcoming me at today's Watercooler Chat [Slides here] where I provided a few key Documentation updates, which I'm also sharing below. Sharing the latest structured update on the Livepeer Documentation Restructure, aligned with the RFP goals outlined here: RFP - Documentation Restructure - #10 by honestly_rich...
![\"RFP](\"https://canada1.discourse-cdn.com/flex030/uploads/livepeer/original/2X/9/9cdb46d131c2f53e22bfd13cbc572e215b2b636e.png\")
Quick update on the survey: We have a good number (25) of results now, so I'll be closing the survey at midnight UTC on Thursday. That means that the last day to fill out the form is Wednesday (in the morning if you're in Argentina). I'll then synthesise the answers and share a summary here this Friday. Edit: The survey is now closed. ...
Join our weekly Fireside where we discuss the most important happenings within our ecosystem. The heavy hitters of the community present their updates. Tap in!
---
Connect with Livepeer on Socials:
Twitter: https://twitter.com/Livepeer
Discord: https://discord.gg/uaPhtyrWsF
Telegram: https://t.me/livepeerorg
Reddit: https://www.reddit.com/...
![\"Livepeer](\"https://i.ytimg.com/vi/Uw7cdZLx7kA/maxresdefault.jpg\")
The proposal funds Cloud SPE to build a focused MVP for standardized, publicly observable network performance, reliability, and demand metrics, making the network measurable and comparable while laying the groundwork for future SLA-aware routing and scaling.
Vote Yes ✅ or No ❌ here", author: "_alisonwonderland", timestamp: "2026-01-21T05:00:44.467Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1463397885272920138" }, { id: "1463397844890288351", content: "📣 Vote now on the Protocol R&D SPE 🗳️ 📣
All network value depends on protocol security. The proposal argues for a dedicated, continuously staffed function for protocol security, upgrades, and core improvements, replacing the current ad hoc model with a single accountable structure.
Vote Yes ✅ or No ❌ here", author: "_alisonwonderland", timestamp: "2026-01-21T05:00:34.839Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1463397844890288351" }, { id: "1463392024576266301", content: "Livepeer #🎙│announcements", author: "_alisonwonderland", timestamp: "2026-01-21T04:37:27.168Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1463392024576266301" }]; export const youtubeDataSeries = []; export const youtubeData = []; export const ghostData = [{ title: "AI X Open Media Forum: Building New Wave Creativity", href: "https://blog.livepeer.org/ai-x-open-media-forum-building-new-wave-creativity/", author: "By Livepeer", datePosted: "Dec 30, 2025", img: "https://storage.ghost.io/c/57/64/5764d422-4b83-4412-b15d-8a8899e73211/content/images/2025/12/Header.png", excerpt: "The AI x Open Media Forum, hosted by the Livepeer Foundation and Refraction during Devconnect Buenos Aires, brought together artists, technologists, curators, protocol designers, founders and researchers at a moment when media is being reshaped at its foundations. Real-time AI has moved from experimental edges into active use, influencing how" }, { title: "A Real-time Update to the Livepeer Network Vision", href: "https://blog.livepeer.org/a-real-time-update-to-the-livepeer-network-vision/", author: "By Livepeer", datePosted: "Nov 14, 2025", img: "https://storage.ghost.io/c/57/64/5764d422-4b83-4412-b15d-8a8899e73211/content/images/2025/11/LP_Blog-Header_Nov25_01_moshed-1.png", excerpt: "For the past year, the Livepeer Ecosystem has been guided by the Cascade vision: a path to transition from a pure streaming and transcoding infrastructure, to an infrastructure that could succeed at providing compute for the future of real-time AI video. The latest Livepeer quarterly report from Messari highlights" }, { title: "Livepeer Onchain Builders - Streamplace: Building the Video Backbone of Decentralized Social", href: "https://blog.livepeer.org/livepeer-onchain-builders-streamplace-building-the-video-backbone-of-decentralized-social/", author: "By Livepeer", datePosted: "Aug 15, 2025", img: "https://storage.ghost.io/c/57/64/5764d422-4b83-4412-b15d-8a8899e73211/content/images/2025/08/Onchain-Builders-Streamplace.jpg", excerpt: "Welcome to Livepeer Onchain Builders, a new content series spotlighting the Special Purpose Entities (SPEs) funded by the Livepeer onchain treasury. SPEs are working groups funded by the community treasury to work on specific tasks and are accountable to the community for their delivery. These deep dives will explore how" }, { title: "Builder Story: dotsimulate x Daydream", href: "https://blog.livepeer.org/builder-story-dotsimulate-x-daydream/", author: "By Livepeer", datePosted: "Aug 6, 2025", img: "https://storage.ghost.io/c/57/64/5764d422-4b83-4412-b15d-8a8899e73211/content/images/2025/08/DD_Builder-Story_dotsimulate_01.png", excerpt: "Building StreamDiffusionTD Operator - a Real-Time Generative Video Operator for TouchDesigner, Powered by the Daydream APICreator: Lyell Hintz (@dotsimulate)Operator: StreamDiffusionTDBackends Supported: Local + Daydream (Livepeer) 0:00 /0:34 1 OverviewStreamDiffusionTD is a TouchDesigner operator that connects real-time inputs like audio, sensors, and camera feeds to" }]; export const forumByReplies = [{ title: "Streamplace 2.0: Solving Video for Everybody Forever", href: "https://forum.livepeer.org/t/2847", author: "By Eli Mallon (@iameli)", content: "
EDIT: Updated proposal later in the thread.
Hey everyone. I’ve been tinkering with this draft all week but just wanted to get it out there ASAP to kick off the process. For more context, check out my presentation to the treasury last Monday - Part 1 and Part 2.
STREAMPLACE 2.0: SOLVING VIDEO FOR EVERYBODY FOREVER
Summary
We’re requesting 250,000 LPT to continue building the video layer for the next generation of decentralized social. In less than a year, Streamplace (née Aquareum) has evolved from a concept to a functional platform powering thousands of hours of livestreaming, securing partnership with Skylight (a TikTok alternative that reached #1 in entertainment on the App Store), and establishing itself as the go-to solution for live video on the AT Protocol.
The Livepeer treasury made all of that happen, and we’re thrilled to be continuing to fund the project as a shared public good. With your support, we’ll expand our infrastructure, hire specialized talent, enhance moderation capabilities, deepen AT Protocol integration, develop VOD functionality, and explore monetization options—all while maintaining our commitment to open-source development and building public infrastructure.
What We’ve Accomplished
Technical Achievements
- The Protocol: Streamplace has invented a novel form of decentralized livestreaming. Our technique, utilizing C2PA-powered Ethereum signatures over one-second MP4 files, is both cryptographically secure and easy to work with.
- The Node: The Streamplace node runs on all major platforms — Windows, macOS, and Linux, and supports AMD and ARM64 architectures. The node is a single file - deployment is the easiest thing in the world. It’s available for download at Stream.place!
- The App: We shipped the Streamplace mobile app to the App Store and Play Store; Streamplace Desktop is also available for download on Windows, Mac, and Linux. Grab it at https://app.stream.place!
- Implemented WHIP and WHEP protocols The Streamplace node utilizes WebRTC for the entire stack — this makes it super easy to support streaming from browsers and phones while delivering low-latency video playback for viewers.
- Libraries: We shipped c2pa-go, the first library for using C2PA primitives in Go. We implemented Ethereum key support in c2pa-rs and shipped the first library for AT Protocol Oauth using React Native, which is in production in multiple atproto applications.
- Livepeer transcoding: All streams through stream.place are transcoded on the Livepeer network, establishing LIvepeer as a key component in the next generation of decentralized social.
Community & Market Traction
- Sponsored ATmosphereConf livestreaming - Streamplace sponsored the first ATmosphereConf; we both operated the livestream and produced the stream on-site. It went really, really well!
- As a direct consequence, we were featured in TechCrunch as a part of a roundup of next-generation apps building on atproto — we were all by ourselves in the livestreaming category!
- Skylight Social partnership - Also as a direct consequence of the conference, we’re bringing livestreaming to Skylight Social, a Mark Cuban-backed TikTok alternative that recently reached #1 in entertainment and #7 overall on the iOS App Store. Skylight surpassed 150,000 users in the first three days after launch and users are consistently pinging their team asking to go live. As soon as this feature ships, all of this livestreaming will be going through the Livepeer network!
- Established ownership of the live video niche on the AT Protocol. Not only that, but Streamplace will be one of the earliest projects to launch significant video content outside of Bluesky’s infrastructure, contributing to the decentralization of the protocol.
All of this has been achieved while keeping every single line of code open-source and freely licensed.
The Opportunity
We’re at a critical inflection point. We’ve proven the concept works, secured key partnerships, and demonstrated clear product-market fit. Rather than pursuing venture capital with its inherent pressure toward extractive business models, we’re seeking continued support from the Livepeer treasury to pioneer a new public goods funding model—one focused on solving hard technical problems for the benefit of an entire ecosystem.
Funding Allocation (250,000 LPT)
Team Expansion
We need to bring on more people full-time to actually deliver on this dream; to start off we’ll be hiring a designer/front-end engineer and a video expert for hardening the node. Additionally, we’re planning on contracting out bounties and collaborating with other projects in the ATProto and Livepeer ecosystems on projects like code generation and SDK development to start to make Streamplace technology as accessible as possible.
Infrastructure Enhancement
- Servers and Scaling: It’s imperative that we deliver a great first impression to this community, and that means scaling up to handle demand and expanding our server infrastructure.
- Performance Hardening: Veterans of Livepeer Studio know there’s a huge gulf between something that mostly works and a battle-hardened piece of video infrastructure. It’s imperative that we deliver a great first impression; decentralized social needs to work at least as well as existing.
- Reliability Testing: Ensure consistent performance under varying network conditions
Core Technology Development
- AT Protocol Integration: Develop deeper, more native integration with AT Protocol. Currently the integration is relatively shallow; a signing key on a users’ PDS links the two accounts. We’re aiming to assist in the development of the protocol.
- NPM Packages: Streamplace has been architected from the ground up to be embeddable in other apps but we haven’t yet actually shipped this capability. With the Skylight partnership we’ll be building out the capabilities to embed broadcast and playback within other apps and websites; other atproto apps have also expressed interest.
- Clipping and VOD: Build decentralized video-on-demand capabilities (beyond Bluesky’s current 3-minute limit)
- Transcoding Infrastructure: Support increased transcoding demand from Skylight users via Livepeer Network
Trust & Safety
- Moderation Systems: As part of the Skylight launch, we will be building out a full content moderation infrastructure, utilizing AI models backed with human moderators. This kind of thing isn’t always emphasized in the Web3 space, but it’s essential to comply with mass market adoption.
- Community Standards: We plan on developing transparent guidelines aligned with decentralized values.
Growth & Sustainability
- Stream Incentives: Programs to encourage creators to use the platform
- Monetization Framework: Explore micropayment systems and creator revenue models in collaboration with others in the atproto space.
- Custom App Development: Our pitch to big Twitch streamers isn’t “switch from Twitch to Streamplace,” it’s “switch from Twitch to your own app, powered by Streamplace infrastructure.” This facilitates a direct relationship between creators and their fans, while the Streamplace layer still enables all the social features of a rich livestreaming platform - chat, hosting, and such.
Vision
We’re not just building a livestreaming platform—we’re establishing the infrastructure and primitives for an entire generation of video applications on decentralized social networks. Our ultimate goal remains unchanged: solving video for everybody, forever.
With your continued support, we can create something truly revolutionary: a creator-sovereign, open-source video layer that enables experiences on par with centralized platforms but aligned with the values of decentralization.
Thank you for considering this proposal. Let’s continue building the future of decentralized video together.
", replyCount: 28, views: 1472, likeCount: 77, datePosted: "Apr 12, 2025", lastActivity: "Apr 28, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "RFP — Explorer Maintenance", href: "https://forum.livepeer.org/t/3072", author: "By Rick (@rickstaa)", content: "Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rick Staa
1. Objective
Restore the Livepeer Explorer to a secure, maintainable, and high-performance state while laying the groundwork for new network-wide data and governance dashboards.
2. Problem Statement
The Explorer is the primary entry point for orchestrators, delegators, developers, and gateways. However, since December 2023 lack of ownership has accumulated significant technical debt:
- Outdated dependencies in the Explorer and design system, fragile under Node 20, break on updates and could lead to security risks, undermining long-term maintainability.
- Duplicated/obsolete code and missing contribution infrastructure (guidelines, CI/tests, stubs), making contributions slow and error-prone.
- Inefficient data fetching (e.g. Infura/Graph duplication), creating performance issues.
- A backlog of unmerged PRs and unresolved bugs (e.g., broken migration widget, UI inconsistencies, incorrectly displayed data).
A future roadmap for expanded network data and richer Explorer stakeholder experiences depends on first restoring a stable, secure, and maintainable Explorer. This RFP focuses on that critical first step.
3. Desired Outcome
Success means that within four months the Explorer is:
- Clean, well tested, with automated tests and continuous integration pipelines, providing a healthy, maintainable codebase.
- Free of critical bugs and stale pull requests, with a clearly organized issue backlog.
- Running on up-to-date, secure dependencies (Explorer and design system) fully compatible with the current Node.js LTS.
- Improved in performance, with faster page loads and a simplified, well-documented data layer for developers
- Equipped with a new voting-transparency feature integrated with the voting-tally subgraph.
- Backed by a clear 6-month roadmap and a dedicated maintainer team providing ongoing maintenance and timely support.
In short, the Explorer will be trusted infrastructure and ready to power further iteration of capabilities.
4. Deliverables
Within four months (target completion by February 1, 2026), the selected team will deliver the following milestone-based outcomes.
Each deliverable must be demonstrated in a Livepeer community call, and the team must provide public progress updates at least every two weeks (e.g., forum posts) throughout the project.
Payments are released only after each demo is accepted by the RFP owner.
(i) Establish Healthy Explorer Codebase
Goal: Deliver a clean, maintainable, and well-tested Explorer foundation to enable ongoing community contributions.
Requirements:
- Remove unused and duplicate code.
- Reorganize folder and module structure, where needed, to improve navigation and long-term maintainability.
- Add comprehensive unit and integration tests covering all critical user flows (e.g., staking, delegating, governance), with measurable coverage targets proposed by the vendor.
- Implement CI pipelines for reliable builds and automated checks.
- Ensure all components are fully typed (TypeScript) and all ESLint/TypeScript errors resolved.
- Provide clear contributor documentation and review workflow, with local-development stubs/mocks so the codebase can run without production environment variables.
Outcome: A clean, healthy, well-tested codebase with CI pipelines and local stubs that contributors can run with minimal setup, forming a solid foundation for future improvements.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the cleaned codebase, CI, tests, and contributor docs.
(II) Improve Data-Fetching Efficiency
Goal: Enhance the Explorer’s data layer to reduce latency, eliminate redundant calls, and ensure responsive, reliable performance for end users and contributors.
Requirements:
- Optimize subgraph and RPC data fetching to reduce latency, avoid duplication, and improve responsiveness.
Outcome: A faster, more efficient Explorer with reduced redundant calls and a simplified, well-documented data layer for easier future contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, showcasing faster data fetching and improved data-layer developer documentation.
(III) Resolve Critical UI Issues & Backlog
Goal: Eliminate high-impact bugs and stale pull requests to ensure a stable, accurate, user-friendly Explorer.
Requirements:
- Resolve all current critical UI bugs (GitHub bug list), including the delegator migration widget, data inaccuracies, and major UX defects, and triage/fix any new critical issues during the engagement.
- Review and merge, close, or supersede all open pull requests (GitHub pull requests) other than the voting-transparency feature (covered in Deliverable 5).
- Work with the Foundation and Advisory Boards to prioritize any other high-impact feature requests from the backlog that fit within the agreed budget and timeline.
Outcome: A more stable, accurate, and user-friendly Explorer with all critical issues resolved and a significantly reduced bug backlog, ready for ongoing community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting a detailed report of resolved bugs and key fixes, along with the cleaned and updated issue board.
(IV) Deliver Voting-Transparency Feature & Subgraph Integration
Goal: Provide clear, real-time visibility into on-chain governance participation.
Requirements:
- Finalize and deploy the voting-transparency feature, incorporating requested UI refinements and migrating data fetching to the voting-tally subgraph for improved performance, using feedback from the Foundation and Advisory Boards.
Outcome: A fully deployed voting-transparency feature integrated with the voting-tally subgraph and refined UI, offering accurate, real-time governance data.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the live voting-transparency feature.
(V) Establish Maintainability & Roadmap
Goal: Ensure the Explorer remains easy to maintain with a clear 6-month plan.
Requirements:
- Publish a 6-month feature/bug roadmap aligned with the Foundation’s Data Gap Analysis and community feedback.
- Provide contributor docs, maintenance practices, and an issue-tracking process (including a clean, well-labeled issue board).
Outcome: A documented maintenance framework and forward roadmap enabling smooth ongoing development and community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting the final roadmap and contributor maintenance guide.
(VI) Provide Ongoing Support & Post-Delivery Responsibility
Goal: Ensure professional post-launch support and continuity of maintenance, whether the same team continues or future maintainers take over.
Requirements:
- During the project, acknowledge critical bugs within 24–48 hours and resolve or mitigate them within a few business days (or faster per the proposer’s SLA).
- After delivery, provide at least a 60-day support window for critical fixes, security incidents, and knowledge transfer, meeting the proposer’s SLA.
Outcome: Stable post-launch operations with timely critical-issue resolution and clear processes for continued maintenance, regardless of who maintains the Explorer.
Payment: The team must present a support-readiness plan with defined SLA commitments, to be agreed with the RFP owner. Ninety percent of each milestone payment is released after acceptance of that milestone’s demo. The remaining ten percent of the total contract is held until the 60-day support period concludes and SLA commitments and resolution targets are met.
Out of Scope
To avoid confusion, the following items are not part of this RFP:
- A full UI/UX redesign or new visual styling of the Explorer.
- Major new product features beyond the initial voting-transparency integration.
- Broader data-gap mapping (handled by separate workstreams).
- Protocol/client changes or on-chain improvements to surface new data (managed through separate RFPs within the same workstream).
5 Capabilities required
Skills
- Strong front-end engineering in modern JavaScript/TypeScript (React/Next.js), including implementing and refining accessible UI components within an existing component library or design system.
- Proven experience with codebase modernization and maintainability—refactoring, setting up CI/CD pipelines, adding automated unit and integration tests, and enforcing TypeScript and ESLint standards.
- Ability to update and manage complex dependency stacks, including Node.js and modern package managers, while resolving breaking changes and configuring automated update tooling (e.g., Dependabot or Renovate).
- Proficiency in performance optimization and efficient data-fetching techniques, particularly with GraphQL/subgraph and RPC endpoints.
- Experience reviewing, triaging, and merging open-source pull requests and managing a clean, well-labeled issue backlog.
- Familiarity with monitoring and incident-response tools (e.g., Sentry, Bugsnag) to ensure production reliability.
Knowledge
- Understanding of the Ethereum/Web3 stack, including wallet flows, transactions, RPC providers, and common front-end pitfalls.
- Awareness of accessibility (a11y) best practices and secure front-end patterns such as dependency risk management and safe secret handling.
- Experience with open-source project governance, including contributor guidelines, code review workflows, semantic versioning, and changelogs.
- Familiarity with The Graph/subgraph architecture and GraphQL schemas (nice to have).
- Familiarity with the Livepeer protocol and current Explorer repository (nice to have).
Attitude
- Community-oriented and collaborative, engaging proactively with contributors, Advisory Boards, and Foundation stakeholders.
- Accountable and responsive, acknowledging critical bugs within 24–48 hours and working toward mitigation or resolution within a few business days.
- Documentation-first mindset, maintaining clear READMEs, runbooks, and migration notes to enable future contributors.
- Quality-driven and pragmatic, balancing rigorous testing, CI, and security with on-time delivery.
- Long-term stewardship, treating the Explorer as trusted infrastructure and designing for multi-year maintainability.
- Supportive and open, encouraging new contributors and fostering an inclusive contributor community.
- Mission-aligned, motivated to strengthen the Explorer as a cornerstone of the Livepeer ecosystem.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience – examples of large front-end refactors, dependency upgrades, CI/CD setup, performance optimization, or open-source project maintenance.
- Milestone Breakdown – a plan aligned with Section 2 deliverables, with proposer-set milestone dates and demo day schedules, each including clear outputs and payment tied to demo acceptance.
- Support & Maintenance Plan – proposed SLA commitments (e.g., response and resolution times), 60-day post-delivery support approach, and handover/knowledge-transfer strategy.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template.
7. RFP Timeline
Proposal Deadline: Wednesday 24th September 2025
Decision Announced: Friday 26th September 2025
Project Start: Wednesday 1 October 2025
Project Completion: Sunday 1 Feb 2026
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
@rickstaaon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
Pre-proposal v5: WEAVE
Authors: DeFine (Strategy & Engineering), Dane (Virtual Worlds & Avatars)Date: March 15, 2026
1. Abstract
The Embody SPE is an entity dedicated to bringing embodied avatar workloads into the Livepeer ecosystem. Since our inception, we have continuously evolved our technology to meet the needs of the network. Our core drive is to deliver sustained fee growth for Livepeer orchestrators.
Along our journey, we have developed solutions and frameworks that address Livepeer’s core bottleneck: the workload lifecycle. Embody seeks funding to develop and prove these solutions, and to expand them into an open-source public-good toolset fit for every existing and upcoming workload deployed on Livepeer.
2. The Problem
To understand the problem, one must recognize three fundamental actors within the Livepeer ecosystem:
-
Orchestrators, who provide compute for workloads.
-
Workload Facilitators, who engineer and maintain the workloads that orchestrators run.
-
Consumers, who utilize these workloads and generate demand.
The Livepeer network provides adequate tokenomic incentives for orchestrators. However, workload facilitator and consumer incentives are currently funded in a non-standardized way by the Livepeer treasury, with limited success so far. In supply and demand terms, compute suppliers vastly outnumber both demand seekers and demand creators.
Workload facilitators generally fall into two subcategories: startups seeking capital to pay for compute and build a consumer base, and established organizations that already possess compute capital and consumers. Livepeer is attractive to both because orchestrators are incentivized through token inflation to offer compute below standard market costs. Theoretically, workload facilitators should be able to offer better prices to their consumers by selecting Livepeer orchestrators.
Despite this advantage, creating workloads within the Livepeer ecosystem remains exceedingly difficult due to the following barriers:
The Technical and Conceptual Barrier Workload facilitators must deeply understand the Livepeer ecosystem technically and conceptually. Furthermore, manually executing every step of a workload’s lifecycle and managing the handoff to the next stage requires an immense amount of time and effort. This creates an exceptionally high barrier to entry, practically excluding non-technical participants from the creation process.
The Economic and Incentive Barrier Economic incentives for workload creation are virtually non-existent by default. Startups rely on the treasury to incentivize their work. Even if a team possesses the technical capability to deliver workloads, they must invest significant time navigating the community and preparing proposals, hoping for treasury approval. For established organizations, there is no incentive to risk service downtime and consumer dissatisfaction by migrating from centralized providers to Livepeer. To date, there are zero documented successful cases of such organizations making the swap.
The Distribution and Interface Barrier Once a workload is live, startups without established consumer bases face the monumental task of building consumer interfaces and executing outreach. Such organizations typically have low headcounts. The added overhead of maintaining Livepeer-specific infrastructure, building interfaces, and distributing workloads is enough to make Livepeer unattractive, especially given the generous inference subsidies offered by centralized providers.
This culmination of friction leads to a critical question: How can we radically reduce the time it takes to convert intent into workload creation and distribution?
3. The Solution
To resolve this bottleneck, we propose WEAVE; an open-source, semi-autonomous agentic orchestration tool with a human-in-the-loop design. WEAVE is designed to turn stakeholder intent into researched, engineered, tested, maintained, and distributed workloads, compressing the lifecycle from months to mere hours.
WEAVE will be accessible to everyone, resolving lifecycle bottlenecks from initial research to consumer distribution. It allows workload facilitators to create new GPU-powered workloads and rapidly deploy them to orchestrators and consumers.
The human operator’s role is simplified: they prompt the initial intent, review the output at the end of each lifecycle stage, and authorize the agent to proceed to the next step. Embody will develop and provide the first WEAVE workloads, managing consumer and orchestrator incentives to power our own and future WEAVE users.
How WEAVE Solves Each Stage
WEAVE directly addresses each stage of the workload lifecycle:
Research Lifecycle agents help identify promising workloads, synthesize demand, evaluate tooling and feasibility signals, and prepare proposals for Livepeer stakeholder review.
Engineering and Maintenance Lifecycle agents turn approved intent into implemented workloads, updates, fixes, and ongoing maintenance work inside bounded environments.
QA Lifecycle agents validate workloads, catch regressions, and prepare them for release through a repeatable testing path.
Consumer Interface The public entry point is a published SKILL.md—a markdown contract that instructs consumers on how to start, control, and end the workload through a mediated public control surface.
Orchestrator Release Lifecycle agents package workloads, document release requirements, and move them through a clear operator onboarding and rollout path.
Consumer Distribution Lifecycle agents support the distribution work needed to reach consumers, drive adoption, and keep the workload legible as a public interface rather than an obscure private implementation.
From Intent to Live Workload
WEAVE provides a clear path from initial intent to live network execution:
-
Intent Submission: A user submits a workload intent. This can propose a new workload, request an improvement, or point the pipeline toward a concrete opportunity (e.g., real-time camera tracking).
-
Lifecycle Execution: Agents pick up the intent and move it through research, engineering, QA, release preparation, and distribution.
-
Stage Review and Authorization: At the end of each stage, agents publish artifacts and request human review. Agents carry the workflow forward, but human authorization is strictly required to complete a stage.
-
Runtime Release and Distribution: When release-ready, WEAVE distributes the workload to the orchestrator registry. Operators can adopt it through a bounded action. The system simultaneously publishes the consumer-facing
SKILL.mdand begins distribution outreach.
For orchestrators, this creates a faster path to new fee-generating workloads and lowers integration friction.
Economic Incentives
WEAVE resolves the time constraints and technical barriers, but this only solves part of the problem. The other half is the absence of economic incentives for workload facilitators and consumers. Similarly, orchestrators typically do not run workloads for free out of goodwill; there must be clear incentives for them to support WEAVE workloads. To address this, we propose three perpetual financial packets:
1. Workload Facilitator Hackathon Packet A perpetual hackathon powered by an LPT economic packet, where a portion of the accrued inflation value is used to incentivize the weekly creation of new workloads. The remaining value is fed back into the principal, allowing it to compound continuously so that token rewards grow over time. The shape of the hackathon and its economic parameters will be subject to ongoing refinement by the multisig participants. Participants will engage through a SKILL.md contract, and funding will be distributed retroactively upon the completion of intended targets. This creates an asymmetric upside: participants are incentivized with an initial allocation, and upon delivering a high-demand workload, they receive retroactive funding along with the ability to deploy applications on top of the workload.
2. Consumer Incentive PacketThis perpetual financial packet operates similarly to the facilitator packet, utilizing weekly accrued inflation to incentivize consumers of WEAVE workloads to take specific actions. For example, SKILL.md consumer agents holding a blockchain wallet could be eligible for rewards if they deliver a working open-source companion application that reaches five concurrent daily users. Like the facilitator packet, this is designed with an asymmetric risk/reward model: the consumer uses the workload without charge and receives a small initial incentive (subject to terms), while the upside includes retroactive rewards and the ability to profit from an application built on WEAVE’s incentive layer.
3. Orchestrator Incentive PacketAn economic packet dedicated to providing weekly rewards for orchestrators who run WEAVE workloads on their hardware systems, ensuring consistent compute availability and sustained network participation.
4. Where We Are Today
WEAVE is being proposed on top of assets the Embody team already operates: a mature Embody workload, an orchestrator rollout lane, and a working consumer entry point.
-
embody-skill: The published skill-contract path for the workload interface, providing a working consumer-distribution surface.
-
livepeer-ops: The control-plane layer for sessions, policy, and orchestrator allocation.
-
Unreal_Vtuber: The runtime environment for the embodied avatar workload.
-
Registered Orchestrators: 13+ orchestrators have registered to the pipeline and received workloads; seven are currently active, and prior participants can reenter.
-
Rollout Capability: The active lane can already receive auto-updates through the Unreal_Vtuber path.
Together, these assets provide the execution base for the proposal: a mature workload, an existing operator lane, and functioning distribution tooling on which WEAVE can be built, tested, and released.
5. What We Are Delivering (4-Month Scope)
The roadmap advances in three stages: first, deploy Embody as the inaugural workload on WEAVE; second, extend WEAVE to host daydream/scope; third, generalize WEAVE beyond both to support any realtime application, establishing it as a true open-source public good for the Livepeer ecosystem.
The perpetual financial packets are foundational to this progression. All three launch alongside the Embody workload in Month 1, ensuring that workload facilitator and consumer incentives are active from the start and that orchestrator expenses are covered from day one.
Month 1 — Embody Workload, Lifecycle Automation & Incentives Launch
DeFine
Deliverables
-
Establish the first bounded lifecycle-agent runtime.
-
Automate research, engineering, maintenance, and QA flows on the Embody (non game-dependent) proving lane.
-
Release Embody as the first working WEAVE workload, accessible via
SKILL.mdand processing sessions on at least one active orchestrator. -
Deploy all three perpetual incentive packets (Workload Facilitator Hackathon, Consumer, and Orchestrator).
Success Criteria
-
Lifecycle agent runtime operational and processing intents end-to-end on the Embody lane.
-
Embody workload live and accessible via
SKILL.md, processing sessions on at least one active orchestrator. -
All three incentive packets deployed and accepting participants.
-
At least 3 orchestrators enrolled in the WEAVE lane.
Dane
Deliverables
- Automate the Embody/Unreal Engine workload engineering pipeline through DeFine’s agent runtime: plugin automation, adding and removing code and features, and game packaging — covering ≥80% of the engineering workflow end-to-end.
Success Criteria
- Agent runtime can execute Unreal Engine engineering tasks end-to-end (plugin add/remove, code changes, game packaging) with ≥80% workflow coverage.
Month 2 — Daydream/Scope Workload Path
DeFine
Deliverables
-
Adapt WEAVE end to end to accept daydream/scope workloads.
-
Bring the orchestrator rollout path online for daydream/scope workloads.
-
Support the first new community workload generated from the Month 1 Hackathon.
Success Criteria
-
WEAVE adapted end to end for daydream/scope workloads.
-
Orchestrator rollout path operational for daydream/scope workloads.
-
First community hackathon workload supported end-to-end.
Dane
Deliverables
- Deliver a functional prototype of the alternative (non-Unreal Engine) embodied avatar workload demonstrating core session flow.
Success Criteria
- Alternative avatar workload prototype operational and demonstrating end-to-end session handling.
Month 3 — Generalized Path & Alternative Avatar Pipeline
DeFine
Deliverables
-
Expand WEAVE from scope and daydream to support custom-lane workloads built on any framework or technology stack, including those outside the Embody and daydream/scope ecosystem.
-
Package Dane’s alternative embodied avatar workload into WEAVE.
-
Open WEAVE to public orchestrator onboarding.
-
Publish the supported workflow for releasing and maintaining additional workloads through WEAVE.
Success Criteria
-
WEAVE custom lane operational and accepting at least one workload built on a framework outside Embody and daydream/scope.
-
Dane’s alternative workload packaged and accessible through WEAVE.
-
At least one external orchestrator onboarded through the public path.
-
Supported workflow for releasing additional workloads documented and tested.
Dane
Deliverables
-
Deliver the alternative (non-Unreal Engine) avatar pipeline, fully operational and documented, ready for DeFine to integrate and automate.
-
Deploy the ability to add and edit new avatars and game environments in both the Unreal Engine and the alternative avatar pipeline.
Success Criteria
-
Alternative avatar pipeline operational, documented, and handed off to DeFine for WEAVE integration.
-
Avatar and environment creation and editing operational in both pipelines, with at least one new avatar or environment demonstrably added through the system on each pipeline.
Month 4 — Governance and Handover
DeFine
Deliverables
-
Facilitate a public governance discussion with multisig participants and the community on how the incentive packets and lifecycle-agent runtime should be managed post-grant.
-
Strategize and document the operating model for the three perpetual incentive packets going forward — how they will run, who will manage them, and what community input shapes their parameters. This decision passes through the community.
-
Document the agreed governance path: multisig participants may elect to transition to a decentralized on-chain layer, continue multisig management until a decentralized solution is ready, or confirm another path agreed upon by the group.
-
Resolve all pending bugs submitted against WEAVE during the grant period.
-
Publish handover documentation and a residual-risk list regardless of the governance decision.
Success Criteria
-
Governance discussion held and outcome documented publicly.
-
Incentive operating model documented and ratified by community input.
-
One of the following governance paths confirmed and recorded: (a) decentralized governance contracts deployed and management transitioned, or (b) a clear continuation plan agreed upon by multisig participants with an explicit path toward eventual decentralization.
-
All flagged WEAVE bugs resolved or, where blocked by external dependency, documented with root cause and mitigation plan.
-
Handover documentation and residual-risk list published.
Dane
Deliverables
- Resolve all bugs flagged across both pipelines during the grant period (Months 1–3).
Success Criteria
- All flagged bugs resolved or, where resolution is blocked by external dependency, documented with root cause and mitigation plan.
Each monthly tranche is released independently via 3/5 multisig upon confirmation of that month’s criteria — DeFine: $4,000 per month, Dane: $6,000 per month. Month 4 payments for both tracks are advanced upon Month 3 confirmation, with final deliverables confirming grant completion. A delay or gap in one track does not block the other.
6. Budget & Financial Governance
The total amount requested from the on-chain treasury is $100,000 USD, equal to 43,478 LPT at an LPT reference price of $2.30 on March 15, 2026.
Budget Breakdown
-
Team Compensation: 17,391 LPT / $40,000 total.
-
DeFine: $16,000 total ($4,000/month). Strategy, control plane, WEAVE engineering, and governance/runtime delivery.
-
Dane: $24,000 total ($6,000/month). Embodied avatar workload engineering across Unreal Engine and non-Unreal runtime paths.
-
Release mechanism: Each monthly tranche is held in the multisig and released only after the month’s work is complete and its success criteria have been met. Release requires 3/5 multisig confirmation. Each track is independently verified and independently released — a delay in one does not block the other.
-
-
Operational Costs: 4,348 LPT / $10,000. Infrastructure, runtime, measurement, and support costs for the proving workload during the grant window.
- Release mechanism: Funds are released against submitted receipts as expenses are incurred. No advance disbursement; each release requires documentation of the corresponding expense.
-
Network Incentives: 13,043 LPT / $30,000. Principal for the Orchestrator Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participating orchestrators according to the published incentive rules.
-
Workload Facilitator Incentives: 4,348 LPT / $10,000. Principal for the Workload Facilitator Hackathon Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participants who meet the published hackathon criteria.
-
Consumer Hackathon: 4,348 LPT / $10,000. Principal for the Consumer Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to consumers who meet the published incentive terms.
Total: 43,478 LPT / $100,000.
The grant will be managed on Arbitrum through a proposal-facing multisig, incorporating comprehensive receipt spend tracking and structured spending categories.
Multisig Composition
-
Orchestrator Tiebreaker: One signer - Pon.
-
Embody Team: Two signers.
-
Foundation: Two signers, including Rick, the Foundation’s head engineer.
Treasury actions will proceed through a 3/5 signature scheme path. If funds need to be returned, the remaining balance can be converted to LPT and sent back to the Livepeer treasury through the governance process described in the separate wallet governance packet.
7. Addressing Past Feedback
We want to thank the Livepeer stakeholders who gave feedback on earlier versions of this pre-proposal. That feedback improved the proposal materially by surfacing three important issues: the security boundary needed to be clearer, the scope was too abstract, and the budget needed to match the size of the work more credibly.
This revision responds directly to those points. It narrows the first workload claim, explicitly defines the system as an open-source tool rather than a decentralized protocol, makes the public consumer path and governance shape more legible, and ties the four-month ask to reviewable milestone outputs. During the core engineering period, the team will remain responsive to ongoing feedback and incorporate useful improvements.
8. FAQ
1. Who is WEAVE for? WEAVE is designed for both the creation of entirely new workloads and the implementation of changes to existing ones.
2. How much automation exists in WEAVE? A WEAVE user can select their preferred level of automation. They can choose to manually review each stage, leave the review to the agent for auto-authorization, or take a highly hands-on approach in the creation process. The lifecycle agents are capable of automating the entire workload lifecycle, including scanning for novel opportunities.
3. How will WEAVE workloads be deployed to orchestrators? The Embody team will maintain a registry where the lifecycle agents of every WEAVE user can post their workloads. Livepeer orchestrators can then browse this registry and select to deploy these workloads through a single command.
4.How are you sure that workloads will be secure? The security evaluation process naturally sits outside the domain of individual WEAVE users. All workloads will be automatically inspected by centralized lifecycle agents operated by the Embody team. Furthermore, every workload will require a manual review before it is approved for deployment to the registry.
5. Will WEAVE use existing Livepeer components for the workload lifecycle and orchestrator payments? Yes. WEAVE will use Bring Your Own Compute (BYOC) for workload deployment, alongside Livepeer gateways and the clearinghouse for workload delivery and payments. The custom Embody parts that previously fulfilled these functions will be replaced with their mapped Livepeer-specific components.
6. What happens if you aren’t finished in the provided timeframe? All provided funds managed by the multisig will be converted to LPT and sent back to the treasury.
9. References & Technical Appendix
This appendix serves as the deeper review bundle behind the shorter forum post. The post stays high-level; the linked docs carry the architecture, roadmap, budget, and governance detail.
Repositories
-
embody-skill: https://github.com/its-DeFine/embody-skill
-
livepeer-ops: https://github.com/its-DeFine/livepeer-ops
-
Unreal_Vtuber: https://github.com/its-DeFine/Unreal_Vtuber
Packet Docs
note: packet docs are being actively updated for the new version
", replyCount: 21, views: 423, likeCount: 39, datePosted: "Feb 17, 2026", lastActivity: "Apr 1, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Continuing discussions on Inflation", href: "https://forum.livepeer.org/t/3139", author: "By b3nnn (@b3nnn)", content: "Hey everyone, I wanted to use this post to reinvigorate the inflation discussion led by @dob in this thread earlier this year.
As a member of the Foundation, and as chair of the Capital Markets Advisory board, I think it’s important to keep us moving forward on this as it part of broader perceptions of the Livepeer project, is part of the broader industry focus on ‘fundamentals’, and is a key component of how capital is allocated within our ecosystem.
From previous discussions (and some new ones), it seems there is broad consensus on the need for small and incremental action. I see my role as helping give a little nudge so we take that small but important first step.
The previous draft from Dob got us to the starting line of what a proposal could look like. My personal tldr of the thread was that:
-
There was general alignment that we should start taking some action
-
There’s alignment on using existing parameters, which avoids risks or delays from new protocol or smart contract work
-
But.. the sticking point was whether to do that using
targetBondingRateorinflationChange, or both, and how to do it in a principled, risk aware way rather than using something that might feel a bit arbitrary
Reinforcing all of this, during the Livepeer summit Doug and Arunas /@Jonas_Pixelfield completed a hackathon project that both modeled parameter changes and surveyed a sizeable set of Orchestrators and Delegators on their perceptions. A short summary is that:
-
Simple modeling shows small parameter changes lead to effects over a fairly long time horizon (in the range of 12+ months to reach something that might be considered major change). This gives ample time to start, observe, and learn and adapt as necessary as we go
-
The survey and interviews further reinforced the consensus from Orchestrators and Delegators that they see the need for action, but sometimes struggle to find confidence with any given approach
With all this in mind, I want to share what we plan to do to help the community move forward:
-
Firstly, we want to keep discussing the Inflation topic with Orchestrators and Delegators. Two ways to do this include:
-
Completing a short survey to expand on your thoughts about the topic
-
Book a meeting where we can discuss or asnwer any questions in real time
-
-
Secondly, we intend to try to quantify the risks involved with some additional modeling. I’ve asked Andrew from Shtuka Research (who is a member of the Capital Markets Advisory board) to take the lead on this. Andrew is a mathematician with a long career in academic and applied research, who will help quantify the risks of different change scenarios. He’ll also be helping us build out a framework for continual risk monitoring and adjustment in the future, so that we can all have confidence to move forward to voting on any proposed changes.
Hopefully you agree that these goals are a relatively simple way to make that last important push and build on the broad consensus reached so far. This is not a one-and-done topic so we will share a bit more about what the path ahead could look like as we get more information.
I’m going to sign off here so that Andrew can share a bit more about the survey and modeling, and I’d encourage anyone who wants to chat on this topic to reach out to me direct via DM on Discord or by using my calendar link share above.
", replyCount: 20, views: 1045, likeCount: 50, datePosted: "Nov 5, 2025", lastActivity: "Mar 2, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Pre-proposal: Livepeer FrameWorks SPE Pilot phase", href: "https://forum.livepeer.org/t/2773", author: "By Marco van Dijk (@stronk)", content: "Livepeer FrameWorks SPE: Pilot phase
Author(s): The MistServer Team
Contact: developers@mistserver.org
Abstract
The FrameWorks SPE proposes to strengthen the Livepeer protocol by bridging the gap between transcoding infrastructure and real-world media applications.
This includes:
- Providing dedicated engineering resources to ensure stability, feature enhancements, automated testing and a clear & complete documentation.
- Providing onboarding and infrastructure support for teams building on Livepeer.
- Operating an independent, Livepeer-powered E2E media pipeline that validates new transcoding features in real-world deployments.
By focusing on low operating costs, easy integration and strategic partnerships, FrameWorks aims to provide a viable, scalable alternative to traditional full-service video providers.
This first phase serves as a pilot to build trust and credibility within the Livepeer ecosystem while keeping the initial funding request modest.
Mission
The media industry is highly complex. Building reliable, scalable streaming applications requires complex deployments and industry expertise.
Livepeer Inc has laid a robust foundation for decentralized video infrastructure. However, there remains a gap between what the network offers versus what video applications need.
This proposal builds on their achievements by addressing key areas where we can contribute with our expertise.
The MistServer team proposes a Special Purpose Entity to take ownership of maintaining and enhancing the transcoding pipeline, ensuring that node operators have the support, documentation, and features they need.
FrameWorks will also bridge the DevOps gap by offering an E2E media pipeline that businesses can directly integrate or self-host, rather than relying on Livepeer Studio for infrastructure, support or custom features.
Instead of replicating Studios’ high-complexity, full-service model, FrameWorks aims to build a scalable, low-overhead alternative aimed at easy integration with external business logic.
Result: A more stable, performant, and accessible transcoding pipeline for node operators and Livepeer-powered media applications.
Terminology
Some of these terms are not present in this pre-proposal, but can be helpful when browsing through the feature board.
- E2E media pipeline: Provides the core infrastructure for a full media pipeline. Including but not limited to: ingesting, processing, storing, and delivering video.
- Transcoding: The process of decoding a video stream, transforming it (resolution, bitrate, etc.), and encoding it for delivery or storage.
- Segmented Workflow: A process of breaking video streams into discrete segments for transcoding. A full segment is required before it can be transcoded by the network.
- Streaming Workflow: A continuous processing method where the video stream is sent in small chunks and immediately transcoded.
- Intel QSV: Intel’s “Quick Sync Video” hardware for video encoding/decoding, allowing efficient transcoding on Intel CPUs and GPUs.
- AV1: A royalty-free, high-efficiency video coding format which is gaining in popularity.
- Latency: In the context of Livepeer we consider the delay between the stream ingest at a Gateway node and receiving the transcoded frames back.
- Netint: Specialized hardware device for video transcoding.
- LPMS: Livepeer Media Server, the core transcoding library used within the Livepeer stack.
- FTE: Full Time Equivalent, indicates the amount of hours dedicated to a project. 1 FTE equals one fulltime employee, but could also be two people each contributing 0.5 FTEs worth of effort.
Structure
The MistServer Team leads the SPE, with Marco (stronk-tech.eth) acting as the primary decision-maker and point of contact.
The SPE is open to expand the core SPE team with additional applications from outside the MistServer team.
Structure
- Lead: Marco, long-time Orchestrator and MistServer maintainer.
- Core Team: MistServer maintainers with expertise in transcoding and live streaming.
- Open-Source Contributors: Developers in the Livepeer community who take on bounties.
- Advisors:
- Rick (
transcode.eth): AI SPE Lead. - Brad (
ad-astra-video.eth): AI SPE Engineer, also familiar with the transcoding codebase. - Josh: Livepeer Inc engineer with extensive experience with relevant code repositories (
LPMSandgo-livepeer). - Rich: Livepeer Ecosystem Growth Team
- Rick (
Responsibilities
- Core Team: Scoping out tasks, assigning bounties, conducting code reviews, and core development of the transcoding pipeline.
- DDVTech: The business entity of the MistServer team, responsible for hiring, team coordination, and administrative processes.
- Advisors: Provide strategic & operational guidance and brainstorming about potential solutions.
About the MistServer Team
The MistServer team is composed of experts in live streaming and media server technology. Our journey began in 2009 when we set out to build a better media server following the failure of a media-related project due to unreliable software. Since then, MistServer has become our core business, and we’ve dedicated our professional lives to advancing live streaming technology.
We bring over half a century of combined hands-on experience in live streaming and media server development, including experience managing streaming infrastructure (like Picarto).
This hands-on expertise positions us uniquely to lead the FrameWorks SPE and contribute meaningfully to the ecosystem.
Scope
The core responsibilities of this SPE include:
- Making the Livepeer transcoding pipeline more robust and competitive.
Adding codecs, adding device support, reducing latency and enhancing transcoding jobs with more parameters.
- Supporting node operators.
Identifying & addressing common pain points, like replacing the static session limit with smarter GPU load balancing and improving Gateway Documentation.
- Ongoing core maintenance
This is a task which also sees ownership from existing core contributors. The Transcoding SPE intends to jump in (wherever required) to assist with tasks like keeping the build pipelines up-to-date, rebasing the LPMS FFMPEG patches and fixing bugs or crashes.
- Research & integrations
The media industry landscape changes over time (slowly evolving). WebRTC and SRT are now common methods to transport media, but are unsupported by Gateway nodes.
These kind of features could also be supported by siderunning applications, like how WebRTC has limited support through go-livepeer’s MediaMTX integration.
This topic covers exploring enhancements to the Gateway with additional protocols or improving integrations with external applications.
- Expanding testing & QA practices
Implementing automated testing to ensure network stability and prevent regressions.
This includes writing feature-specific tests for each change we make, while also expanding coverage with additional regression or benchmark tests.
- Bridging the DevOps gap for media applications
Providing support to entities looking to build on the network as well as setting up an E2E media pipeline, making it easier for applications to integrate Livepeer-powered streaming without reliance on Livepeer Studio.
Any development work will of course be published open-source and under the Unlicense.
Phase 1: Pilot
Goals
- Gather pain points from Gateway and Orchestrator operators.
- Prioritize roadmap items to address critical gaps in the transcoding pipeline.
- Set up a transcoding bounty program.
- Scope out the E2E media pipeline.
- Cross off the first few items from the roadmap.
Timeline
March 2025:
- Set up operations and governance structure.
- Identify and re-prioritize key tasks for this quarter.
- Launch a bounty board for community contributions.
- Initial discussions on FrameWorks infrastructure.
April – July 2025:
- Engineering work on Q2 key tasks, explained in the roadmap below.
- Next phase planning: Identifying FTE needs and define the FrameWorks infrastructure roadmap.
Roadmap
We have published a feature board where anyone can request items, vote on priorities, and comment on issues.
The roadmap will be prioritized based on continuous conversations with node operators, as well as the needs of inbound opportunities for our E2E media pipeline.
Initial Q2 goals are:
- Improve documentation for Gateway operators.
- Pull Netint integration over the finish line.
- Pull AV1 codec support over the finish line.
- Add Intel QSV support.
- Smarter session limits & load balancing for transcoders.
This roadmap indicates our short-term goals. Not all of these features might see completion in Q2.
Future Phases
If the pilot phase succeeds future requests may include:
- Expanding the core SPE team to increase engineering capacity.
- Addressing long-term goals and more complex tasks, including transitioning to a streaming workflow or expanding the Transcoding job type with more parameters (for example: allowing non-realtime, high quality transcodes for VoD processing).
- Further development & deployment of the FrameWorks E2E media pipeline.
Budget Breakdown
Funding Period: March – June 2025
Total Ask: 15,000 LPT
Breakdown:
| Item | Amount | Explanation |
|---|---|---|
| March: SPE Kickoff & onboarding | Free | Structuring the SPE, setting up communication channels, onboarding contributors, gathering feedback from Gateway & Orchestrator operators, initial design work on the E2E media pipeline. |
| April – June: Core Development | 12000 LPT | Managing bounties, active community participation, feature development, testing, and infrastructure work. |
| Community Incentives | 3000 LPT | Open-source contributor incentives to drive external contributions. |
Rate Justification
For 4,000 LPT per month, the MistServer team operates the SPE while providing 1 FTE of dedicated engineering work. At $5 per LPT, this equates to $20,000 a month (~$115/hr), which is a reduced bulk rate for long-term commitments. This ensures that developers assigned to the SPE remain fully committed, without being pulled into other commercial projects.
If future proposals require additional engineers, we can use the DDVTech entity to hire freelancers or full-timers. This approach allows us to:
- Offer security & guarantees to SPE hires through an established legal entity, of course with access to our office and team’s expertise for onboarding.
- Provide additional engineering capacity at a lower cost, ensuring efficient use of treasury funds.
We are open to adjusting the LPT request or FTE commitment based on community feedback, but believe the amounts are fair given the technical expertise required and in comparison with common rates in the media industry.
Success Metrics:
Defining success metrics for a broad core-development SPE like this is difficult. We encourage feedback on what we can do to measure impact and ensure accountability.
-
Core Contributions:
- Completed bounties.
- PRs submitted and merged into the Livepeer codebase.
- Increase in test coverage.
-
Feedback & Adoption:
- Positive feedback from Gateway & Orchestrator operators.
- Growth in the number of Gateway operators on the network, onboarded through the FrameWorks SPE.
- Transcoded minutes on the E2E media pipeline.
Transparency and Accountability
Engagement with protocol participants is an important part of this SPE. We will work closely with Gateway & Orchestrator operators to collect issues or requests to put on the feature board. We gather community input through multiple channels:
- Discord threads & forum discussions.
- a Canny task board to track development progress, request items or discuss tasks.
- Titan’s weekly water cooler sessions.
Leftover LPT will roll over into future proposals or return to the treasury if the SPE disbands for any reason.
Reporting:
- Quarterly progress reports will include:
- Amount of LPT spent, staked, or held.
- Progress on any of the success metrics.
", replyCount: 18, views: 842, likeCount: 52, datePosted: "Feb 22, 2025", lastActivity: "Mar 17, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Telegram Bot: Transcoder-Watcher", href: "https://forum.livepeer.org/t/609", author: "By vires-in-numeris (@vires-in-numeris)", content: "
Over the past few days, I’ve been further developing the Transcoder Watcher Bot running in my 0x525 Transcoder Telegram Channel. It was my goal to create a tool that everyone can use to get notified about transcoder events and here it is:
The Telegram Transcoder-Watcher Bot!
You can find the bot here: https://t.me/TranscoderWatcher_bot
What does it do?
By writing “/start”, the bot will give you an introduction and informs about the available commands:
- subscribe
- remove
- subscriptions
- history
details here: Telegram Bot: Transcoder-Watcher
If you subscribe to a transcoder (or multiple, there is no limit), you will get notified about the following events:
- reward calls
- missing reward calls
- reward cut changes
- transcoder becomes inactive
Whenever possible, I include the transaction link so you can be sure that no incorrect information is sent. However, please note that the bot is still in the testing phase and of course it’s always possible that the script crashes and the bot stops working.
How does it look like?
Here are some screenshots for the various events.
- Reward Calls:
- Missing Reward Calls:
- Reward Cut changes:
- Transcoder becomes inactive:
If you discover any error or have feature requests, you can reply here or send me a message on discord!
", replyCount: 16, views: 5777, likeCount: 16, datePosted: "Mar 21, 2019", lastActivity: "Mar 8, 2026", categoryId: 7, categoryName: "Transcoders", categoryColor: "#25AAE2" }, { title: "RFP — Documentation Restructure", href: "https://forum.livepeer.org/t/3071", author: "By honestly_rich (@honestly_rich)", content: "Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rich O’Grady
1. Objective
Restructure, refresh, and modernize Livepeer’s documentation so that it is stakeholder-focused, AI-first, and future-proofed. It should cater to the core personas of the Livepeer project: developers, delegators, gateway operators and orchestrators.
2. Problem Statement
Current Livepeer docs suffer from:
- Complicated onboarding: User journeys (node operators, app builders, delegators, gateway providers) are hidden behind toggles instead of clear entry points.
- Outdated or inconsistent content: Deprecated APIs, stale references, incomplete AI coverage, and fragmented changelogs.
- Brand & duplication: Studio-specific guidance is mixed into core docs; AI SDKs and APIs are duplicated across gateways.
- Weak site integration: Poor linkage between website, explorer, governance portal, and docs. Too many Studio dashboard references.
3. Desired Outcome
Success is a single-source-of-truth documentation system that:
- Leads with clear stakeholder-focused onboarding and goal-oriented entry points.
- Cleanly separates AI Jobs vs Transcoding Jobs while still surfacing cross-cutting resources (SDKs, APIs, CLI, on-chain/network).
- Fully deprecates Studio content with redirects and zero broken links.
- Provides AI-first documentation: semantically structured, LLM-readable, with embedded natural language search/assistant.
- Consolidates changelogs and introduces versioning / deprecation tracking.
- Establishes a style guide, contribution model, and ownership playbook for consistency.
- Integrates seamlessly with the broader Livepeer ecosystem (website, explorer, governance, dashboards).
4. Deliverables
(i) Present New Documentation Strategy
Goal: Create a new outline for Livepeer documentation, including full map of current documentation, a clear information architecture and timeline for writing new documents.
Requirements:
- Identify core stakeholder groups (Livepeer Foundation, Livepeer Inc, AI SPE, Cloud SPE, Streamplace, Frameworks and more)
- Conduct of all docs pages with status recommendations across the 4 categories (Developers, Delegators, Orchestrators, Gateway Operators)
- Developers: clean up deprecated sections and plan integrations with new gateway products (Streamplace, Frameworks, Daydream and more)
- Orchestrators: simplify documentation to easy onboarding with plan for support in Discord.
- Delegators: integrate new video content to make it easy to delegate.
- Gateways: streamline documentation and workflows with support from the Foundation.
- Create plan for an updated sidebar, taxonomy, and breadcrumb structure.
- Consolidation of multiple changelogs into a single canonical feed.
- Onboard stakeholders to project management process
Outcome: A forum post detailing the new documentation to the community with a 1-week window RFC.
Demo Due Date: Friday 17th October
(ii) Re-Write Documentation
Goal: Systematically edit and rewrite new content to meet stakeholder needs with consistent accuracy and depth.
Requirements:
- Work with core stakeholders to rewrite documentation
- Make the documentation easily consumable by AI systems and empower users with an embedded assistant ( semantic headings, structured metadata, and machine-readable references (OpenAPI specs, JSON examples).
- Integrate embedded natural-language search or AI assistant (leveraging Mintlify features) and ensure clear explanations and concise summaries for LLM parsing.
- Rewrite quickstarts for both AI Jobs and Transcoding Jobs.
- Migration guides for Studio users.
- Integrate goal-based tutorials for each stakeholder type where possible.
- Work with existing groups to incorporate starter repos, examples, and copy-paste snippets and full API/SDK/CLI references with updated coverage (including realtime + BYOC APIs).
- Conduct review with core stakeholders with a clear RFC.
Outcome: First written draft of clear, accurate, and goal-oriented documentation that accelerates adoption and reduces support overhead.
Demo Due Date: Friday 7th November
(iii) V1 Documentation Live
Goal: Deliver a technically sound and reliable documentation site.
Requirements:
- Implement redesigned IA and content in the current docs stack (Mintlify/Docusaurus).
- Set up redirects, SEO and AEO optimization, and accessibility compliance (WCAG).
- Integrate multilingual readiness and analytics tracking.
- Integrate the documentation into the website.
Outcome: A responsive and performant documentation site with zero broken links, measurable engagement, and improved accessibility.
Demo Due Date: Friday 14th November
(iv) Public Workflow For Maintenance & Community Contributions
Goal: Create a consistent tone and a scalable contribution process.
Requirements:
- Work with the Livepeer Foundation’s Technical Director to establish a unified voice and style guide (tone, terminology, formatting, accessibility).
- Create contribution guidelines and PR workflow for community involvement.
- Define and handover ownership and review process for maintaining quality.
- Integrate multilingual readiness and analytics tracking.
- Provide a clear ticketing system for reporting problems and patching fixes.
Outcome: A sustainable documentation process with consistent voice, tone, and governance.
Demo Due Date: Friday 5th December
5. Capabilities Required
Skills
- Developer documentation strategy, IA design, technical writing.
- Static site tooling, redirect management, docs CI pipelines.
- SEO, accessibility, multilingual documentation workflows.
Knowledge
- 1+ years experience with Livepeer ecosystem
- Streaming/transcoding basics (FFmpeg, GPU workloads).
- AI inference workflows basics, particularly working with APIs.
- Open-source contribution models and GitHub-based workflows.
- Comparative familiarity with best-in-class docs (e.g., Chainlink, Base, Solana).
Attitude
- Community-first, collaborative, pragmatic.
- Strong eye for clarity, consistency, and long-term maintainability.
- Willingness to challenge outdated patterns and propose future-proof solutions.
- Enjoyment in distilling complex technical concepts into minimal, user-focused documentation.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience - examples of docs restructures, especially for developer platforms.
- Milestone Breakdown - giving a week-by-week breakdown of the project in line with the due dates and requirements above.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template
7. RFP Timeline
- Proposal Deadline: Wednesday 24th September 2025
- Decision Announced: Friday 26th September 2025
- Project Start: Monday 29th September 2025
- Project Completion: Friday 5th December 2025
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
Rich | Livepeer Foundationon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
- Payments: when thinking through your total budget, be mindful that payments will be paid out on milestone completion.
Abstract
All network value depends on protocol security.
Protocol security requires dedicated capacity to detect issues early, resolve them quickly and deploy upgrades with confidence. The current model depends on limited, distributed resources that cannot consistently support these demands. The Protocol R&D Special Purpose Entity (SPE) resolves this by establishing a professional, continuously staffed function responsible for vulnerability triage, safe upgrade preparation, and shipping additional protocol features like a reliable testnet for rigorous validation and development.
This proposal funds the SPE for an initial six-month term. It brings together a contracted security and engineering partner, under the governance of Livepeer Foundation and Livepeer Inc. The SPE creates a single, accountable structure that protects the protocol, reduces operational risk and enables faster, safer delivery of protocol improvements as the network continues to scale.
Mision
The mission of the Protocol R&D SPE is to provide the most secure, resilient and continuously improving protocol foundations possible for Livepeer, at the best possible price-to-value ratio.
Rationale
The protocol supports significant on-chain value which continues to grow through the expansion of services to real-time video AI inference. Protecting this requires consistent access to security and engineering expertise. The current model, while effective at securing the protocol since inception, relies on Livepeer Inc and places a significant load on the security committee. This constrains core feature development and protocol progress. Having a dedicated security partner reduces the load on the security committee and frees them for other obligations, while increasing the speed at which we can improve network security.
Core to this SPE is the engagement of a Protocol Engineering & Security Partner (Sidestream) to provide a dedicated, multi-disciplinary team. They provide first‑response to Immunefi-identified vulnerabilities and implement audited on‑chain patches and upgrades. Immunefi has been a massive success in terms of the mission, keeping the protocol safe at modest cost—historically about $75–100k per year in bounty payouts—while helping protect tens of millions in protocol value. The Partner works in close coordination with the Security Committee, which retains review and execution authority for upgrades and emergency patches.
The steps reduce our reliance on more constrained support, and moves toward a stable, accountable model for protocol security. The SPE creates a durable, well defined structure for protocol stewardship as the network decentralizes. It gives the community a clear point of accountability for security and core maintenance, which reduces operational risk and supports the reliable functioning of the protocol over the long term.
Deliverables
The Protocol R&D SPE improves operational responsibilities, fast and continuous response, ships already‑built but not‑yet‑deployed features in the protocol R&D pipeline, and launches and maintains a public testnet and DevEx toolkit to speed up future development.
(1) Core Protocol Security Operations
Goal: Maintain continuous protocol security coverage and rapid incident response through the Immunefi bounty program and close coordination with the Security Committee.
Outputs: The SPE will manage the Immunefi process as first responder for vulnerability reports. The Partner will reproduce, validate, and propose patches within defined response windows, in coordination with the Foundation Technical Lead and the Security Committee for review and deployment. Quarterly readiness reviews will strengthen detection, response time, and coordination.
Success Indicators: Continuous Immunefi coverage with valid reports acknowledged within 24 hours and triaged within one week. Critical issues are resolved or escalated for deployment within agreed timelines. The SPE operates the response process independently while the Security Committee maintains oversight.
(2) Ship Backlog Features and Build the R&D Pipeline
Goal: Deliver the high-priority protocol upgrades from the existing backlog while building the foundation for a sustainable and iterative R&D process.
Outputs: The SPE will complete and deploy existing features nearing readiness for mainnet release—such as the Reward Call Delegate, Ticket Distinction, and stability patches. The specific upgrades shipped each release cycle will be selected through a lightweight triage process established by the SPE, supported by the Foundation protocol engineer as the role comes online.
Success Indicators: At least one backlog feature or patch deployed to mainnet per release cycle. Lightweight triage and delivery process is established and used to prioritize and ship work. The Foundation protocol engineer is hired and supporting development and coordination by the end of Q1 2026.
(3) Public Testnet and Developer Infrastructure
Goal: Deliver and maintain the testnet and tooling needed for reliable validation, audits, and developer experimentation, supporting both protocol and client development.
Outputs: The SPE will operate a continuously available public testnet with faucet access, CI integration, and simulation tooling. Clear developer documentation and workflows will make it easier to run local or private devnets and test upgrades or integrations before mainnet deployment.
Success Indicators: Public testnet operational with ≥99% uptime and integrated into CI and simulation workflows. Developer and client teams actively use the infrastructure for validation and testing.
Key Milestones
| Milestone | Target Completion | Description |
|---|---|---|
| Partner Onboarding Completed | Q4 2025 | Protocol Engineering & Security Partner contracted and operational, and security and triage procedures aligned with the Security Committee. |
| Continuous Immunefi Vulnerability Response | All of H1 2026 | Maintain full first-response capability for Immunefi reports: reproduce issues, propose fixes, coordinate Security Committee review, and ensure continuous coverage. |
| Public Testnet Live | Q1 2026 | Launch a stable, persistent public testnet with faucet, CI integration, and reproducible deployment tooling. |
| Triage Pipeline Established & First Upgrade Shipped | Q1 2026 | Lightweight triage process established and validated through at least one feature or protocol upgrade shipped to mainnet. |
| Triage Pipeline Updated & Additional Upgrade Shipped | Q2 2026 | Triage pipeline updated, with at least one additional upgrade triaged and deployed to mainnet. |
| Six-Month Review & Renewal Assessment | Q2 2026 | Performance and financial review concluded by the SPE Board,; results shared publicly and renewal proposal prepared. |
SPE Governance Structure
The Protocol R&D SPE is managed and governed by the Livepeer Foundation and Livepeer Security Committee. Through their collaboration, they enable the work of the Protocol Engineering & Security Partner.
The exact operations of security practices are not shared here.
SPE funds are held in a secure multisig SAFE with a threshold of known, trusted signers from the Foundation and the Security Committee, following standard security practices.
The SPE will operate transparently through quarterly public reporting, open development and open access to non-sensitive work.
Roles & Responsibilities
| Body / Role | Responsibilities | Scope | Funding Source |
|---|---|---|---|
| Security Committee | Review and execute upgrades and patches a final security checkpoint | Security oversight; upgrade authorization & execution. | Livepeer Inc. |
| Foundation | Coordinate roadmap and delivery, manage funds and payouts for Immunefi, audits and security partner milestones | Program and roadmap management, coordination and treasury/ops. | Foundation |
| Protocol Engineering & Security Partner | First responder for patches, implementator of new protocol features, audited upgrades, and patches, and build/maintenance of testnet and tooling components | On-chain development, security response, contract CI/tooling, on-chain testnet components. | SPE |
Budget
The Protocol R&D SPE seeks $360,000 equivalent amount. This ensures 24/7 responsiveness from the team in addition to their core security deveopment work.
The budget includes a line item for audits to ensure that significant protocol changes and new implementations receive appropriate security review before deployment. Other necessary costs for executing this SPE, such as the Foundation’s protocol engineer, infrastructure, and operations, are covered separately by the Foundation.
A core responsibility of the SPE is managing the Immunefi bounty program. The Livepeer Foundation will cover Immunefi payouts in the short term to avoid withdrawing capital from the treasury until necessary. This approach allows treasury capital to continue supporting other strategic initiatives across the ecosystem. As part of the Foundation, I can share that we are glad to support this active capital management to advance Livepeer’s collective goals.
Projected Spending:
| Category | LPT | USD | Description |
|---|---|---|---|
| Protocol Engineering & Security Partner (team) | N | $300,000 | Six-month engagement focused on security response, prioritized backlog features, and on-chain testnet ops. |
| Audits & External Reviews | N | $60,000 | Third-party security reviews (reserve-based) |
| Total Initial Request | N | $360,000 |
Key Terms
| Term | Definition |
|---|---|
| Protocol R&D SPE | A Special Purpose Entity funded by the Livepeer Treasury to manage protocol research, development, and security operations. |
| Protocol Engineering & Security Partner | The contracted team responsible for hands-on protocol development, audits, and vulnerability response under the SPE framework. |
| Security Committee | Oversight body responsible for reviewing protocol upgrades, validating critical patches, and guiding decentralization of security responsibilities. |
| Immunefi Program | Livepeer’s bug-bounty initiative that incentivizes whitehat researchers to identify and responsibly disclose vulnerabilities in the protocol. Managed under the SPE to ensure continuous coverage and rapid triage. |
| Triage Pipeline | The structured process for evaluating, prioritizing, and implementing protocol work, including community proposals (LIPs) and vulnerability reports, through coordinated specification, review, and deployment stages. |
| Public Testnet | A continuously maintained network environment mirroring mainnet, used for protocol validation, client testing, and developer experimentation before production deployments. |
| DevEx Tooling | Developer-experience infrastructure, including CI pipelines, simulations, and documentation, enabling contributors to test and validate protocol upgrades efficiently and safely. |
| SPE Board | The governance body composed of representatives from the Foundation, Security Committee, and Livepeer Inc., responsible for approvals, budget oversight, and performance reviews. |
| Audits | Independent security reviews performed by external experts to assess the safety, correctness, and performance of protocol changes before deployment. |
| Multisig SAFE | A secure multi-signature wallet used for custody and management of SPE funds, requiring approval from designated Foundation and Security Committee signers. |
Thank you to everyone who reviewed the earlier pre-proposal and shared detailed feedback in the forum and during the Watercooler. The concerns raised around scope, cost, architectural risk, and MVP clarity were well-founded and directly informed this revision.
This updated pre-proposal reflects a deliberate reset toward a smaller, clearer Network-as-a-Product MVP. The scope has been significantly narrowed, the budget reduced, and the architecture simplified to prioritize time-to-value, reuse of existing Livepeer infrastructure, and immediate usefulness to gateways, orchestrators, and ecosystem teams.
Below is the revised pre-proposal. We welcome the community’s review and feedback on the updated scope, design, and framing. We will be present on this coming Monday’s Water Cooler for discussion.
Cloud SPE Pre-Proposal: Network-as-a-Product (NaaP) MVP – SLA Metrics, Analytics, and Public Infrastructure
Abstract
This pre-proposal seeks treasury funding for the Livepeer Cloud Special Purpose Entity (SPE) to design, build, and operate a focused Network-as-a-Product (NaaP) MVP for SLA metrics, analytics, and public visibility.
The objective of this work is to make the Livepeer network measurable, comparable, and trustworthy at a network level by delivering a small but complete set of standardized performance, reliability, and demand metrics. These metrics will be publicly observable and designed to support gateway providers, orchestrators, and ecosystem builders evaluating Livepeer as production infrastructure.
This MVP intentionally prioritizes time-to-value, architectural simplicity, and reuse of existing Livepeer infrastructure, while establishing a durable foundation for future SLA-aware routing, scaling, and productization efforts led by Livepeer Inc, the Livepeer Foundation, and the community.
Rationale
As Livepeer advances toward the Network-as-a-Product vision, predictable service characteristics and transparent performance signals become essential. While the network supports real workloads today, participants lack a shared, network-wide view of performance, reliability, and demand that can be used to assess suitability for production use.
Community discussions around earlier drafts of this initiative strongly aligned on the problem, while raising important concerns around scope, cost, architectural risk, and MVP clarity. This pre-proposal reflects that feedback by narrowing focus to a practical MVP that:
- Demonstrates clear value with minimal complexity
- Leverages existing data sources and pipelines wherever possible
- Avoids protocol changes, enforcement mechanisms, or premature decentralization
- Produces immediately usable outputs for real network participants
Key challenges addressed by this proposal include:
- Fragmented metrics: Existing performance and reliability data is dispersed across systems and difficult for non-core teams to consume.
- Limited network-level visibility: Gateway providers and orchestrators cannot easily compare performance across regions, workloads, or peers.
- Adoption friction: Without transparent, shared metrics, external developers and partners struggle to evaluate Livepeer for serious workloads.
- Missing foundation for NaaP evolution: Future SLA-aware routing, scaling, and automation require a trusted measurement layer first.
The Cloud SPE is well positioned to deliver this work as neutral, public infrastructure, building on its prior experience operating gateways, test tooling, dashboards, and analytics for the Livepeer network.
Importantly, this proposal does not attempt to enforce SLAs, modify protocol incentives, or introduce new routing logic. Its purpose is to establish shared measurement and learning infrastructure as a prerequisite for those future decisions.
Deliverables
The NaaP MVP will deliver a constrained, end-to-end metrics system focused on observability and learning inspired by the NaaP product MVP and Foundation roadmap.
1. Core SLA Metrics (MVP Scope)
- A standardized set of network, performance, and reliability metrics sufficient to evaluate orchestrator and GPU behavior across workflows.
- Metrics sourced primarily from job tester gateway and orchestrator-emitted telemetry, with targeted additions only when other Gateways opt-in.
2. Network Test & Verification Signals
- Operation of one or more reference load-test gateways to generate consistent, reproducible performance signals for live AI video pipelines.
- Public test scenarios (aka test datasets) designed to reflect real workloads while remaining transparent and community-verifiable. These will be captured in Github.
- Test results contributed into the same analytics layer as organic network traffic to enable comparison (when other Gateways participate).
3. Analytics & Aggregation Layer
- Lightweight ETL and aggregation pipelines to transform raw metrics into network-level views.
- Computation of a small number of derived indicators as outlined in the Metrics Catalog
- Data structured for efficient querying without requiring dashboards to load raw job data.
4. Public Dashboard & APIs
- A standalone public dashboard presenting live and historical metrics.
- Public, read-only APIs for aggregate SLA scores and hardware.
- Clear paths for gateways and ecosystem teams to consume the data directly or mirror it into their own analytics systems.
5. Operations & Stewardship
- Ongoing operation of testing, analytics, and dashboard infrastructure.
- Maintenance, monitoring, and community support for the MVP for 1 year.
Any scope not outlined here is not part of the Deliverables and out of the scope of this proposal.
Key Milestones
Milestone 1 – Metrics Collection & Aggregation
- Define and implement the minimal metrics set
- Aggregate existing telemetry into a unified analytics layer
- A basic dashboard showing sample data flowing end to end
Milestone 2 – Test Signals & Derived Analytics
- Deploy reference load-test gateways
- Launch a public dashboard with core views
- APIs for ecosystem consumption
Milestone 3 – Stabilization & Review
- Harden infrastructure for reliability and cost efficiency
- Document metrics, assumptions, and known gaps
- Review outcomes with the community to determine next steps
Timeline
Delivery is anticipated to take approximately six months (and already underway as of November 2025). This is dependent on the team’s development velocity and subject to change. Preliminary design and validation work has begun to reduce delivery risk.
- November 2025 - Works began on original proposal and discovery process
- February 2026 – Milestone 1: Metrics Collection & Aggregation
- March 2026 – Milestone 2 – Test Signals & Derived Analytics
- April 2026 – Milestone 3 – Stabilization & Review
Budget
Total Requested Budget: $90,000
This budget supports:
- Engineering work to aggregate, validate, and expose SLA-relevant metrics
- Development of Load Testing Gateway (AI Job Tester + Gateway enhancements) and Network Data Scraper
- Development of minimal analytics and public-facing dashboards
- Development of DevOps infrastructure and automation
- Operation of testing, analytics, and storage infrastructure for approximately one year
- Ongoing maintenance, documentation, and community support
The budget is intentionally sized for a thin but complete MVP, designed to validate assumptions, inform future investment, and avoid long-term commitments before value is demonstrated.
Closing Note
This pre-proposal reflects extensive community and Livepeer Inc feedback and represents a deliberate step toward a simpler, clearer, and more actionable NaaP MVP.
By focusing on shared measurement rather than enforcement or protocol change, this work aims to give the Livepeer ecosystem a common understanding of network behavior today — and a solid foundation for deciding what to build next.
", replyCount: 12, views: 331, likeCount: 48, datePosted: "Jan 10, 2026", lastActivity: "Apr 14, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Transcoder Campaign: lpt-gzp-node.eth", href: "https://forum.livepeer.org/t/2931", author: "By lpt-gzp-node.eth (@tryingout)", content: "Hi everyone! I’m running a Livepeer transcoder based in Slovenia since 2022, focused on reliability, sustainability, and geographical diversity in the network. I truly believe Livepeer has huge room to grow, and I’m in it for the long run.
Hardware setup:
- 2× NVIDIA GTX 1070 GPUs for rock-solid transcoding
- 1× NVIDIA RTX 3090 dedicated to the AI network
- Solar-powered when available
Current fee structure:
- Reward cut: 8%
- Fee cut: 49%
Cuts may lower as more LPT is staked — early delegators are rewarded!
If you’re looking to support a trustworthy, green, and diverse node, consider staking with me:
Delegate here
Got questions or just want to connect? Join me on Discord: @gasper5466
", replyCount: 12, views: 482, likeCount: 6, datePosted: "May 30, 2025", lastActivity: "Mar 4, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "Lisar SPE Release Notes", href: "https://forum.livepeer.org/t/3159", author: "By serial_winner (@serial_winner)", content: "As part of our monthly accountability updates, the Lisar SPE is happy to share our second monthly progress update covering—what we’ve completed, what’s currently in motion, and what’s coming next.
Quick note: This release notes will serve as a way to share what work is going on with Lisar. All future reports will be added under this thread so anyone can easily track progress without hunting for older updates. Dive in to explore what’s happening and please reach out or reply if you have any questions.
October - Status Update
We previously published our first update sharing details of what work was done, if you missed it please find link to the report here
November – Status Update
The Lisar SPE is actively working toward our core deliverable:
unlocking delegation access for everyone globally by enabling fiat-based delegations (USD, NGN, GBP, KES, and more).
Here’s what was completed in November
- Completed a closed beta with users and internal testers
- Switched the transparency dashboard to live mode, enabling real-time community visibility
- Public launch after beta validation
Closed Beta Testing
We kicked off a closed beta in early November with a group of early users. This allowed us to test the entire lifecycle—depositing fiat, converting to LPT, delegating, tracking rewards, and withdrawing back to fiat—with real users.
The beta surfaced minor UX improvements, but overall validation was strong, and all core flows performed as expected.
Live Transparency Dashboard
Our public transparency dashboard is now live.
This means the community can monitor Lisar’s progress in real time—delegators onboarded, total fiat converted, total delegations and more.
Dashboard link: https://lisarstake.com/dashboard
Community transparency is one of our commitments, so getting this live was a major step.
Gearing Up for Public Launch
With beta successfully completed, we’ve shifted into launch mode.
Announcements are ready and will be going out shortly. We’re now entering the final stage outlined in the original four-month proposal with the remaining months focusing on driving adoption and scaling the platform responsibly.
Milestones & Timeline (As Outlined on the proposal)
Check out full proposal on the forum
Build the Core Platform — Completed
- Full fiat → LPT → delegation flow implemented
- Secure fiat on/offramp integrations for multiple currencies
- Gas sponsorship enabled (users never need ETH)
- Delegation + reward tracking in fiat equivalents
- Seamless withdrawals back to fiat
The core platform is stable and production-ready.
Transparency Dashboard — Completed
The dashboard now tracks and displays real-time metrics:
- Number of delegators onboarded
- Total fiat converted
- Total LPT delegated through Lisar
- Delegations per orchestrator
Launch & Scale — In Progress
Up Next
- Launch & Scale - we’re opening access for anyone to delegate on Livepeer through Lisar, with announcements going out across all channels soon. Our next phase focuses on bringing delegators onboard responsibly marking the transition from building → testing → growth.
Find below all relevant links on Lisar, we look forward to sharing more updates soon
Links
-
Begin staking on the Lisar app
-
Track live progress on the dashboard
-
Learn about Lisar, Livepeer, and staking through Lisar Academy
-
Guides on how to stake on livepeer through lisar are up on youtube
-
Follow development on Github
Proposed by: Rich O’Grady (Co-Director, Livepeer Foundation) and Rick Staa (Technical Director, Livepeer Foundation)
Abstract
The Network Engineering SPE is a delegated pool of capital that funds scoped engineering RFPs and retroactive contributor grants, without requiring a standalone on-chain proposal for each initiative. The mission of the SPE is to fund smaller engineering initiatives to make the Livepeer network more observable, performant, and developer-centric. It targets the $2k–$20k range of work that the current SPE process makes too slow to fund. We’ve seen this model work: the Explorer upgrade proved what a vetted contributor with a clear scope and accountable oversight can deliver. This SPE scales that, while exploring a more retroactive model.
Requested duration: 3 month (pilot program) + 2 weeks (retro)
Requested budget: $95,000 USD-equivalent in LPT
The Problem
The Livepeer project needs the ability to execute fast and targeted actions to support users, operators and builders on the network. The current SPE model works well for large, multi-month programmes. It doesn’t work for the $2k–$20k engineering work the network often needs.
The friction is structural:
- A full SPE proposal requires significant time before any work begins
- On-chain vote cycles add weeks of delay — often longer than the work itself
- As AI tooling compresses build cycles, this gap is getting worse, not better
The result: well-supported, clearly-needed work goes unfunded — not because the community doesn’t want it, but because there’s no efficient path to fund it.
This was validated by three public community discussions (March–April 2026) with strong consensus. The Water Cooler on 13 April returned a clear signal: move forward.
The Solution
The aim of this SPE is to build a delegated funding pool with a fast, accountable process which funds critical engineering work fast. This would sit alongside the formal SPE process, which primarily focuses on longer-term (3+ months) initiatives.
This SPE replicates and scales that model across two funding tracks: RFPs dividing up known work and distributing it amongst the community; and retroactive grants funding for work that has already been completed.
Note: Retroactive Grants don’t necessarily go through the Roadmap process.
Eligibility Areas
For the first round of SPE funding, there will be 3 primary focus areas, which are focused on Livepeer’s core stakeholder groups, each with different needs:
Priority 1: [Developers] Developer Portal — The 5-Minute API — Work on the Developer Portal’s critical path: the engineering that takes a developer from docs to first inference call in under five minutes, from any MCP-compatible tool. This includes the Python SDK, BYOC container tooling, payment and auth infrastructure, agentic harness tooling, and any library or scaffolding that removes onboarding friction.
Priority 2: [Delegators] Explorer — Participation & Observability — Work that makes the Explorer a better permissionless participation portal for operators and delegators. This includes staking interfaces, governance participation features, network observability dashboards, and tooling that surfaces real network behaviour to support informed decision-making.
Priority 3: [Orchestrators] Tooling & Infrastructure — Work that helps orchestrators run more reliably, scale capacity, and integrate with the evolving SDK-first architecture. This includes containerisation, orchestration tooling, runtime improvements, go-livepeer contributions, and infrastructure that affects network reliability and operational experience. Note: that this area requires particularly strong community validation before an RFP is promoted
Funding Track 1 — RFPs (~$5k–$20k, 2–8 weeks)
Full proposed process: RFP Process - Network Engineering SPE
Community members post Roadmap Suggestions on the forum, where the suggester drafts initial requirements and deliverables with the community - facilitated by the Livepeer Foundation. After an initial community validation via Discord, the Foundation then publishes a finalised RFP for contributors to apply to, and assigns it to a selected team or contributor within 7 days.
All decisions and disbursements are published with written rationale. Payment is split across three tranches: 25% on signing; 50% on delivery and verification by Review team; and 25% on impact paid at the end of the pilot (in August). Any incomplete work or assessments at the end of the pilot triggers a brief remediation window.
Three Suggestions have already been initially identified and will be scoped with community contributors and then validated by the community to become (or not become) RFPs:
- Roadmap Suggestion 1: Developer Portal & Discoverability platform
- Roadmap Suggestion 2: Improved Explorer as Participation Portal
- Roadmap Suggestion 3: Payment Clearinghouse & Remote Signer
Funding Track 2 — Retroactive Grants (<$5k, retroactive)
Full proposed process: Retro Grants Funding Process - Network Engineering SPE
Build first, then apply. Contributors post a public application on the forum after the work has shipped. The Review Team reviews on a monthly cycle and publishes an approve, partial approve, or decline decision with written rationale. Approved grants are paid in full in a single disbursement.
The primary bar is impact, not completion. Each application must name the problem, who had it, and who is already using the solution. Describe what was built, link to the work, and state the amount requested. Projected usage does not count.
Examples of eligible work and impact:
- OpenRouter integration — 5 developers discovered and integrated with Livepeer via OpenRouter.
- Live video-to-video / BYOC full-stack runner — 3 community members running live video-to-video with BYOC end-to-end — a workflow the network had no viable path for before this.
- Agentic harness tooling — 3 Livepeer solutions cutting time-to-working-agent-loop from days to hours using standardised scripts, tool definitions, and prompts.
Quantifying Impact
Impact means the network becomes more observable, more reliable, or more easy-to-use for Developers, Delegators or Orchestrators. The concrete impact signals that the Review team will look at are all about usage and adoption:
- Named adopter — a specific person or team outside the author is using it in their own work.
- Downstream dependency — another project or contributor is building on top of it.
- Capability confirmed in the wild — someone who wasn’t involved in the build has run it successfully.
It is also expected that the work is maintained and still live by the end of the program. What impact is not: download counts, repo stars, or the builder using their own tool.
What This SPE Isn’t
Not a demand generation fund (coming soon). The Network Engineering SPE funds the engineering substrate: the infrastructure that makes demand solutions like Daydream, Frameworks, Blueclaw, Streamplace possible. Go-to-market, marketing, and end-user services are out of scope.
Not an open-ended bounty pool. Every disbursement requires a verified definition of done. Work must be complete, reviewable, address a recognised need and have verifiable impact.
Replacing the SPE Process. For larger pieces of work network engineering (e.g. 2+ months with multiple contributors), the onchain treasury process will still be used.
SPE Governance Structure
Custody: Funds held by the Livepeer Foundation.
Decision process: All decisions made live in weekly Review Team meetings via a simple 2-of-3 vote, with a written decision log published after each meeting. Any Review Team member with a direct financial interest in a decision must recuse.
| Role | Who | Responsibilities | Paid by SPE? |
|---|---|---|---|
| Review Team Lead & Technical Director | Rick Starr (Livepeer Foundation) | Refines scope of RFPs with Suggester; leads RFP team selection; signs off on technical quality for all RFP Track 1 work - sole gate on technical delivery, no broader Review Team vote required; produces pilot evaluation report | No |
| Reviewer, RFPs | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Reviews and scores RFP applications against evaluation criteria; represents community interests in first-pass scoping; casts an independent vote on Tranche 2 and Tranche 3 payouts; publishes written rationale for any dissent or recusal | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Reviewer, Retro Grants | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Owns first-pass review of retroactive grant applications against the published rubric (supported by AI pre-screening); triages and quality-screens incoming applications; compiles monthly review shortlist; proactively surfaces strong unsubmitted community work; casts an independent vote on retroactive grant approvals | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Roadmap Manager | Rich O’Grady (Livepeer Foundation) | Facilitates community Suggestion sessions; manages the Suggestions pipeline; promotes validated ideas to the roadmap; signals funding path per item | No |
| Program Manager | Mehrdad (Livepeer Foundation) | Runs and records weekly Review Team meetings; maintains the public decision log; tracks milestone status; manages remediation windows | No |
| Contributors | Community | Deliver scoped outputs with full ownership and accountability | Yes |
This SPE will have AI-native workflows embedded from day one, reducing Review Team overhead, keeping the public record current, and ensuring consistent quality control without manual lift.
AI-led tasks include: retro grant pre-screening; automating meeting notes and updates; decision log drafting; application triaging.
Timeline
15 May 2026 — Funding Programs Live
Review Team seated. Weekly cadence established. First 3 RFPs posted publicly. Retroactive grants open. Public tracker live. Key assessment: did we launch on time with the right scope?
30 Jun 2026 — First Deliveries Verified
At least 1 RFP delivered. At least 1 retroactive grant awarded. Key assessment: is the quality bar holding? Is the 14-day selection target being met?
30 Aug 2026 — Pilot Complete
Minimum 3 RFPs delivered, with aspirational goal of 5. All impact assessments done. All spend published. Evaluation report out with a clear recommendation: continue, modify, or stop.
Budget Breakdown
Total requested: $95,000 USD-equivalent (4-month pilot)
| Budget line | Assumption | Amount (USD-equiv.) |
|---|---|---|
| Review Team Member compensation (×2) | 2 × $7,500 / 3 months (~10 hrs/week) | $15,000 |
| Track 1 — RFP pool | Aim: 3 RFPs over pilot at ~$15k average | $45,000 |
| Track 2 — Retroactive Grants pool | Aim: 5 retroactive grants at ~$3k average | $15,000 |
| Funding Buffer — for additional grants or RFP | To either be allocated, returned to the onchain treasury or carried over to future SPE | $20,000 |
| Total | $95,000 (in LPT) |
If uptake for RFPs and/or retroactive grants are lower than expected at the 30 June checkpoint, the Review Team has the opportunity to reallocate between pools based on where community activity is strongest.
Any unspent funds or incomplete RFPs at pilot end are returned to treasury (with a small undefined, remediation window if work near completion).
All amounts sized using the 30-day moving average LPT price at the time of RFP approval.
Deliverables
Pilot success criteria (3 months):
1. Minimum 3 RFPs reach verified impact - At least 3 scoped engineering RFPs complete with a confirmed definition of done, verified by the Technical Director and community Review Team Members. Each delivery is published publicly with a written rationale and outcome assessment.
2. Minimum 5 retroactive grants funded - At least 5 retroactive grant applications reviewed and awarded, covering work that has already shipped and meets the published rubric. Each award is published publicly with written rationale, the amount approved, and the impact evidence submitted by the contributor.
3. Three public SPE updates published during pilot - One per month (June, July, August). Each update covers: RFPs active and delivered, retroactive grants reviewed and awarded, funds disbursed to date, and Review Team decisions with written rationale. Published within 7 days of the monthly Review Team meeting. Zero black-box decisions.
4. Pilot evaluation & impact report published by 30 Aug 2026 - A concise report covering: RFPs funded and delivered, retroactive grants awarded, total spend vs. budget, community signal on delivered work, and a clear recommendation: continue, modify, or stop. Written for a community audience, not an internal one.
Transparency and Accountability
- Every RFP and retroactive grant decision published publicly with written rationale.
- Public tracker RFPs: all RFPs, status, funds allocated and disbursed, Review Team decisions
- Public tracker grants: all retro grant applications, decisions, amounts awarded, and impact evidence
- Review Team Members publish justification for any overrule or recusal
- Monthly written reporting to the community (per SPE norms) plus update at Water Cooler
- All conflicts of interest disclosed and recused
Budget Envelope: Up to $10,000 USD equivalent
Date Issued: 2026-05-14
Issued By: Rick Staa
1. Purpose
Objective
Analyse the Explorer’s delegation UX against the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) and comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX sets the bar for user expectations. Produce a design-ready specification for a self-custody delegation experience that could compete or pull users away from the path of least resistance of holding on an exchange, thus preserving the direct protocol participation that makes self-custody valuable: governance rights, earnings transparency, and independence from custodial intermediaries.
Problem Statement
Livepeer’s on-chain delegator count has fallen ~36% over two years, but total staked LPT and participation rate have held steady or grown. The gap is explained by a structural shift: centralised exchanges are delegating growing pools of custodial LPT without any user-facing staking product. No major exchange such as Binance, Coinbase, or Kraken offers LPT staking. The delegation is happening without user involvement.
The Explorer’s delegation flow needs to be compelling. Simply holding LPT on an exchange while the exchange stakes it without their involvement results in centralisation that undermines the network. We want actively grow delegators and direct governance participation.
We need to:
- Precisely quantify the UX gap between the Explorer’s delegation flow and the top staking UX standard set by major exchanges and comparable PoS tokens
- Identify the specific design and information-architecture changes that would improve self-custody delegation
- Produce a shippable design brief the Foundation can convert directly into build work (retro grants or follow-on RFP)
Desired Outcome
Within 3–4 weeks, we have:
- A competitive teardown showing exactly where and why the Explorer’s delegation experience falls short of the standard set by exchange staking UX or other ecosystems at each step of the journey
- A design-ready specification for a “minimum competitive staking experience” in the Explorer
- A prioritised backlog of improvements with expected impact and effort that can be shipped as follow-on work
2. Requirements
Key Deliverables
- Competitive teardown
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
Dimensions: steps-to-stake, time-to-stake, information architecture, trust signals, yield presentation, risk framing, reward monitoring, and unstaking/exit experience (including offboarding from custodial products to self-custody: withdraw/transfer out). Each comparison should include annotated screenshots or screen recordings documenting the full flow. - Secondary analysis (decentralised staking UX): Review of the best delegation and staking experiences across decentralised protocols, including but not limited to Lido, Rocket Pool, Cosmos/Keplr and/or other PoS ecosystems with strong delegator UX. This analysis should identify the UX patterns, information design, and onboarding flows that make these experiences work. What can we learn from the best decentralised staking UX?
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
- Standardised baseline scenarios (for comparable measurement)
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Scenario A (Fiat start): new user starting from fiat → staked/delegated
- Scenario B (Funds already on exchange): user already has funds on exchange → staked/delegated
- Include at least one concrete comparison like “What does it take to get $100 → staked LPT?” (time, steps, fees, failure points) across platforms.
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Gap specification
- Map each identified UX gap to a specific Explorer screen, flow, or missing feature
- Classify gaps by severity (blocking, friction, polish) and estimated effort (small / medium / large)
- Highlight the gaps that most plausibly explain the shift toward custodial staking
- Design brief: “Permissionless staking experience”
- What would a new user need to see and do in the Explorer to choose self-custody delegation over leaving LPT on an exchange?
- Wireframes or annotated flow diagrams (not just a written list) for the redesigned delegation journey
- Cover: discovery/landing, orchestrator selection, delegation execution, earnings monitoring, and re-delegation/exit
- Address the specific trust and clarity signals that custodial services provide and the Explorer currently lacks (yield clarity, risk framing, earnings visibility)
- Instrumentation plan
- What events and metrics need to be tracked to measure delegation conversion going forward
- Minimal and implementable, scoped to what can be added to the Explorer’s existing codebase without major infrastructure changes
- Propose a baseline measurement approach so future UX improvements can be evaluated
- Prioritised backlog
- Top 10–15 improvements ranked by: expected impact on self-custody delegation competitiveness, implementation effort, and dependency chain
- Clear split: quick wins (shippable via retro grants) vs. larger items (follow-on build RFP)
- Each item should reference the competitive teardown evidence that motivates it
Out of Scope
- Diagnosing why delegator count is declining (recent analysis confirms stake is centralising because exchanges are delegating custodial holdings, not because users are opting into custodial staking products)
- Implementing UX changes (this is an analysis + design specification scope)
- Protocol-level changes to staking mechanics (separate governance process)
- Large-scale design-system restyle work
- General-purpose user research unconnected to the competitive comparison
- Outreach / conversion strategy to migrate exchange-delegated LPT toward Explorer-based self-custody delegation (higher earnings, voting rights, orchestrator choice).
- Arbitrum liquidity readiness for sustained new stake originating from fiat — does the contributor see any concerns from the journey/teardown research?
Definition of Done — by Tranche
| Tranche | % Budget | Unlocks On |
|---|---|---|
| 1 — Signing | 25% | Audit plan agreed, competitive teardown scope confirmed (which services, which dimensions), kickoff doc filed |
| 2 — Delivery | 50% | Competitive teardown delivered, gap specification delivered, design brief with wireframes delivered, instrumentation plan delivered |
| 3 — Impact | 25% | Prioritised backlog accepted by Review Team after a public comment window (≥7 days) on the forum, with community feedback/reaction explicitly weighed as part of acceptance. At least 3 items converted into follow-on work (retro grants or RFP scope) within 30 days of acceptance. |
3. Capabilities Required
Skills
- Product design and UX analysis (competitive teardowns, information architecture)
- Ability to produce wireframes or annotated flow diagrams (Figma, or equivalent)
- Familiarity with web3 wallet interaction patterns and staking UX conventions
- Experience analysing decentralised protocol UX (delegation flows, validator/orchestrator selection, reward mechanics)
- Ability to read a modern web codebase (Explorer is React/Next.js) enough to assess instrumentation feasibility
Knowledge
- How centralised staking services (Binance, Coinbase, Kraken) present yield, risk, and onboarding to retail users for comparable PoS tokens
- How decentralised staking ecosystems (Cosmos/Keplr, Lido, Rocket Pool or others) handle delegator onboarding, validator discovery, and earnings transparency
- Livepeer delegator mechanics (L1/L2 bridging, orchestrator selection, reward cuts, bonding/unbonding)
- Web3 onboarding friction points and trust/risk communication patterns
Attitude
- Evidence-first: every recommendation grounded in the competitive comparison, not opinion
- Design-oriented: outputs should be visual and specification-ready, not just written analysis
- Comfortable working in public and with async feedback from the Foundation team
4. Proposal Requirements
Please include:
- Contributor / Team Overview
- Why you’re a fit (prior UX competitive analysis, staking product design, or delegation UX work)
- Approach & Timeline (mapped to tranches above)
- Which competitive services you will analyse (primary: Binance, Coinbase, Kraken staking UX for comparable PoS tokens; secondary: best-in-class decentralised staking/delegation experiences, e.g. Lido, Rocket Pool, Cosmos/Keplr or others you propose)
- Design output format (Figma, annotated screenshots, other)
- Pricing breakdown
- Conflict of interest disclosure
5. RFP Timeline
| Milestone | Date |
|---|---|
| RFP Posted | 2026-05-18 |
| Application Deadline | 2026-05-24 |
| Decision Announced | 2026-05-29 |
| Project Start | 2026-06-01 |
| Expected Completion | 2026-07-03 |
6. Proposal Submission Instructions
Reply to this forum post in the comments with your proposal (linking a doc or including it inline).
Questions: reach out to @rickstaa on Discord.
7. Decision & Governance
Selection criteria:
- Quality and specificity of competitive analysis approach, and do they understand what makes exchange staking UX set user expectations, and why users default to holding on exchanges?
- Demonstrated ability to produce design-ready specifications (wireframes, annotated flows), not just written reports
- Practical instrumentation plan that respects the Explorer’s current technical constraints
- Speed and clarity of execution
Hey everyone,
Wanted to share some updates on WEAVE as we get into Month 1 execution. There’s a team change, a budget adjustment, and some governance work happening.
SPE Naming
To align SPE naming with mission objectives, the WEAVE proposal deliverables are being operated now under WEAVE Growth SPE. Embody SPE stays its own thing, focused on embodied agent workloads. The broader roadmap lives under WEAVE Growth SPE.
Team Structure Updates
Dane decided to move on from WEAVE for personal reasons, and we parted on good terms.
Dane built the Unreal Engine avatars and most of the game UI that powered our PixelStreaming workloads. He was dedicated, hardworking, and consistently showed up when it counted. He overdelivered on his initial Embody deliverables and brought the game to a mature, production-ready state. The game builds he produced are what the Embody workloads ran on. We’re genuinely grateful for his contribution and wish him all the best going forward.
On the IP side, Dane has committed to granting the WEAVE Growth SPE entity a perpetual, royalty-free license to the source code with sub-licensing rights, allowing us to use, modify, and sublicense it as needed. The source can’t be MIT because of third-party plugin restrictions, but the license covers us fully. The packaged game goes MIT, same as all future Embody releases. We will follow up with Dane on the necessary actions and paperwork to make sure this is properly finalized. This development makes sure that the source code will become an other asset for the growth of Livepeer and ensures that Dane’s departure does not compromise our ability to create future workloads using Unreal Engine.
Budget
We will discuss actively with the community to make sure that the SPE acts according to stakeholder intent to decide what will happen to the funds that where earmarked towards Dane’s compensation.
Governance and transparency
We are currently discussing with the team the creation of a lightweight legal entity with non-profit operating provisions, where financial reporting and management obligations would be written into the founding documents themselves. The entity will operate with strict non profit provisions for the benefit of the whole Livepeer ecosystem and will possess ownership of the financial(incentives) and IP assets(unreal engine game, weave website, etc..) of the SPE.
What that looks like: budget, spending, and compensation reported publicly. Governance processes published online, how decisions get made, how workloads get evaluated, how incentive packets get managed. All incentive programs will run in the open with published criteria, schedules, and outcomes.
We’re still working out the exact structure, reporting format, and cadence with the team. Once that’s decided, we’ll share it publicly.
Month 1 Deliverables
You can find the month 1 deliverables spec bellow, we are currently finalizing this before posting the final version. Any feedback welcome.
Deliverables spec doc
WEAVE Growth SPE — Month 1 Deliverables
Version: v0.2 (April 2026)
Owner: DeFine
Technical Reviewer: Rick
Completion Rule: No deliverable is complete until Rick signs off on its evidence pack.
Month 1 Operating Logic
The dependency chain is:
- M1-D1 builds the open-source WEAVE Tool.
- M1-D2 exposes that capability through the DAO-operated hosted WEAVE App + API.
- M1-D3 activates the incentive loop that drives workflow creation and app creation.
- M1-D4 proves publicly what users did, what converted, and what became monetization-ready.
Month 1 completion is based on whether this machine exists, is live, and is measurable. Raw demand volume is a KPI outcome, not the sole approval condition.
M1-D1 — Open-source WEAVE Tool
Description: A public, open-source, self-hostable WEAVE Tool that lets any technical user create Scope .json workflows, run viability research, run QA, and extend the system independently. This is the core product layer, not the hosted WEAVE service.
Outcome: By end of Month 1, a technical user can take the WEAVE Tool repo, follow the docs, generate valid workflows, inspect viability + QA outputs, and adapt the tool for their own API or webapp if they choose.
Excludes: Hosted uptime, DAO-run API reliability, user onboarding/account systems, and incentive logic.
Sub-deliverables
M1-D1.1 — Public repo and licensing live
| Criteria | Done? |
|---|---|
| Repo is public | |
| License file is present | |
| README covers setup, architecture, usage, and extension points | |
| Example assets or example outputs are included or linked |
Evidence: Public repo URL, license file, README, architecture note.
M1-D1.2 — Workflow creation engine works
| Criteria | Done? |
|---|---|
Tool can generate valid Scope .json workflows | |
| At least 3 materially distinct workload classes are supported | |
| Each class has a reproducible example output | |
| Export path for generated workflows is documented |
Evidence: 3 exported .json outputs, supported workload list, reproduction notes.
M1-D1.3 — Commercial viability module integrated
| Criteria | Done? |
|---|---|
| Workflow creation includes an explicit viability-assessment step | |
| Viability output is generated inside the tool | |
| Output includes target user, use case, monetization path, market rationale, and build/no-build reasoning | |
| Viability output is saved or exportable alongside the workflow artifact |
Evidence: UI or CLI artifact showing the viability step, 3 example analyses, output schema.
M1-D1.4 — QA module integrated
| Criteria | Done? |
|---|---|
| QA stage exists inside the tool flow | |
| QA returns pass/fail or a structured issue list | |
Checks cover valid .json structure, required fields, runnable shape, and broken-config detection | |
| At least 1 failed QA case is demonstrated |
Evidence: QA checklist/spec, pass artifacts, fail artifact, output examples.
M1-D1.5 — Self-hostability proven
| Criteria | Done? |
|---|---|
| Fresh setup can be completed from the published docs | |
| Tool runs without requiring the hosted WEAVE App/API | |
| A technical user can extend or wrap the tool for their own API or webapp | |
| No WEAVE-managed account is required to use the core tool |
Evidence: Self-host setup note, fresh-run proof, extension or wrapping example.
Evidence Pack for Rick Review
- Public repo URL
- License file
- README + architecture note
- 3 sample workflow outputs
- 3 viability outputs
- QA pass/fail artifacts
- Self-host proof
M1-D2 — Hosted WEAVE App + API Access Layer
Description: The DAO-operated, free hosted access layer for WEAVE. This is the managed WEAVE App and public API that use the WEAVE Tool underneath so users can access WEAVE services without self-hosting.
Outcome: By end of Month 1, a user can complete the workflow-creation path through the hosted WEAVE App or API, view viability + QA outputs, and move from workflow creation into app creation without local deployment.
Excludes: Open-source licensing proof for the core tool, standalone self-host proof, and incentive policy itself.
Sub-deliverables
M1-D2.1 — Free hosted WEAVE webapp live
| Criteria | Done? |
|---|---|
| Public URL loads successfully | |
| User can complete workflow creation end-to-end through the webapp | |
| Viability and QA outputs are visible in the hosted flow | |
| Workflow output is viewable and exportable |
Evidence: Public URL, screenshots, end-to-end web demo recording.
M1-D2.2 — Public API live
| Criteria | Done? |
|---|---|
| API endpoint(s) are publicly reachable | |
| API docs are published | |
| Workflow creation, viability, and QA are available via API | |
| At least 1 successful API-created workflow is demonstrated |
Evidence: API base URL, API docs, example request/response, API demo artifact.
M1-D2.3 — Hosted surface is clearly downstream of D1
| Criteria | Done? |
|---|---|
| Hosted outputs use the same core workflow format as the WEAVE Tool | |
| Relationship between D1 and D2 is documented publicly | |
| Hosted access policy is stated | |
| Free access terms or limits are stated |
Evidence: Public note on tool vs hosted surface, access policy doc, parity note.
M1-D2.4 — Workflow-to-app creation path live
| Criteria | Done? |
|---|---|
| User can move from workflow creation into an app-creation path through the hosted surface | |
| This path is exposed in the webapp and documented in the API flow | |
| At least 1 example app-creation flow is demonstrated | |
| Output from this step can be used in the incentive system |
Evidence: App-creation demo, UI/API docs, example artifact.
M1-D2.5 — No-self-hosting path demonstrated
| Criteria | Done? |
|---|---|
| A user can complete the hosted flow without local deployment | |
| A web-based end-to-end demo exists | |
| An API-based end-to-end demo exists | |
| The hosted path is usable by a non-technical participant |
Evidence: Web demo, API demo, hosted-path walkthrough.
Evidence Pack for Rick Review
- Public webapp URL
- Public API docs URL
- Tool-to-hosted parity note
- Web demo recording
- API demo recording
- Example workflow artifact
- Example app-creation artifact
M1-D3 — Incentive Program Launch
Description: The live WEAVE incentive system that moves users from registration to workflow creation to app creation, with identity-gated enrollment to reduce bot/sybil spam. Phase 1 rewards support workflow and app creation. Phase 2 rewards unlock only after an app proves quality, monetization, and electronic payment readiness.
Outcome: By end of Month 1, incentive registration is live, users can enroll from both the WEAVE Tool and the WEAVE App, Phase 1 rewards are active, and the Phase 2 unlock rules are explicit and operational.
Sub-deliverables
M1-D3.1 — Incentive rules and governance published
| Criteria | Done? |
|---|---|
| Public incentive rules document exists | |
| Phase 1 and Phase 2 are defined separately | |
| Participant types and eligible actions are defined | |
| Calculation method and cadence are defined | |
| Dispute and exception handling path is defined |
Evidence: Public rules URL, version/date, example calculation, dispute policy.
M1-D3.2 — Worldcoin-gated registration live
| Criteria | Done? |
|---|---|
| Incentive enrollment path is live | |
| Worldcoin verification is required before incentive participation | |
| Anti-spam / anti-sybil rules are published | |
| At least 1 successful registration is evidenced |
Evidence: Enrollment URL, verification screenshots, policy note, first successful registration artifact.
M1-D3.3 — Dual onboarding paths live
| Criteria | Done? |
|---|---|
| User can enter the incentive system from the WEAVE Tool path | |
| User can enter the incentive system from the hosted WEAVE App path | |
| Differences between self-hosted and hosted participants are documented | |
| Both paths feed the same KPI/reporting surface |
Evidence: Tool-path walkthrough, app-path walkthrough, onboarding documentation.
M1-D3.4 — Phase 1 rewards active
| Criteria | Done? |
|---|---|
| Phase 1 rewards are live during Month 1 | |
| Workflow creation is a qualifying action | |
| App creation is a qualifying action | |
| Incentive window and cadence are publicly stated |
Evidence: Launch announcement, rules excerpt, active incentive window proof.
M1-D3.5 — Phase 2 activation gate defined and testable
| Criteria | Done? |
|---|---|
| Phase 2 activation criteria are published | |
| Criteria require proof of quality standards | |
| Criteria require proof of monetization | |
| Criteria require ability to accept electronic payments | |
| A qualifying evidence template or checklist exists |
Evidence: Phase 2 rules section, qualification checklist, sample evidence packet.
M1-D3.6 — First live cycle operational
| Criteria | Done? |
|---|---|
| Weekly calculation or review runbook exists | |
| First cycle calculation artifact is produced | |
| At least 1 real participant moved through registration → action → calculation | |
| Exception/dispute handling is usable |
Evidence: Runbook, first cycle artifact, participant flow proof, exception log template.
Evidence Pack for Rick Review
- Public incentive rules URL
- Worldcoin-gated registration proof
- Tool-path and app-path onboarding proofs
- Phase 1 live-window proof
- Phase 2 qualification checklist
- Weekly runbook
- First cycle calculation artifact
M1-D4 — Public KPI / Reporting Surface
Description: The public reporting layer that shows whether WEAVE is actually acquiring users, helping them create workflows, converting those workflows into apps, and moving those apps toward quality and monetization readiness.
Outcome: By end of Month 1, the public can verify acquisition, production, quality, monetization-readiness, and workflow-to-app stickiness from a live KPI/reporting surface.
Sub-deliverables
M1-D4.1 — Public KPI surface live
| Criteria | Done? |
|---|---|
| Public URL exists | |
| Metric definitions are visible | |
| Update cadence is stated | |
| Current snapshot is visible |
Evidence: Public dashboard/report URL, screenshots, metric definitions.
M1-D4.2 — Acquisition metrics live
| Criteria | Done? |
|---|---|
| New users are counted publicly | |
| Incentive-verified registrations are counted publicly | |
| Tool-path vs app-path acquisition can be distinguished or derived | |
| Reporting window is stated |
Evidence: KPI surface screenshot, acquisition methodology note.
M1-D4.3 — Production and completion metrics live
| Criteria | Done? |
|---|---|
| Workflows started are counted publicly | |
| Workflows completed are counted publicly | |
| Incentive completions are counted publicly | |
| Apps created are counted publicly |
Evidence: KPI surface screenshot, metric definitions, sample snapshot.
M1-D4.4 — Quality and monetization progression metrics live
| Criteria | Done? |
|---|---|
| Apps crossing the quality threshold are counted publicly | |
| Apps that are monetization-ready are counted publicly | |
| Apps that can accept electronic payments are counted publicly | |
| Phase 2-eligible apps are counted publicly |
Evidence: KPI surface screenshot, methodology note, status definitions.
M1-D4.5 — Stickiness / progression metrics live
| Criteria | Done? |
|---|---|
| Workflow-to-app conversion metric is defined | |
| Post-action stickiness metric is defined | |
| Repeat builder activity or return behavior metric is defined | |
| Measurement window and method are published |
Evidence: KPI definitions, methodology note, example snapshot.
M1-D4.6 — Public reporting artifacts published
| Criteria | Done? |
|---|---|
| Weekly report template exists | |
| First public KPI snapshot/report is published | |
| Caveats and methodology are published | |
| Reporting owner/update cadence is named |
Evidence: Report template, first snapshot/report, methodology doc.
Evidence Pack for Rick Review
- Public KPI/dashboard URL
- Metric definitions
- Acquisition, production, and conversion screenshots
- First public report or snapshot
- Methodology / caveat note
Month 1 KPI Targets
These are operating targets, not the sole completion gate. Month 1 approval depends first on whether the system is live, reviewable, and measurable.
| KPI | Month 1 Target |
|---|---|
| New verified incentive users | 10+ |
| Workflows started | 10+ |
| Workflows completed | 5+ |
| Apps created | 3+ |
| Phase 1 incentive completions | 3+ |
| Apps reaching quality review | 1+ |
| Apps reaching monetization readiness | 1+ |
| Workflow-to-app stickiness | 25%+ of workflow completers start an app path |
| Public KPI snapshots/reports published | 1+ live snapshot and weekly cadence defined |
Rick Review Gate
Rick signs off separately on each deliverable:
- M1-D1 technical completeness of the open-source WEAVE Tool
- M1-D2 hosted operability of the WEAVE App + API
- M1-D3 correctness and operability of the incentive mechanism
- M1-D4 correctness and integrity of the public KPI/reporting surface
| Deliverable | Evidence Submitted | Rick Status | Final |
|---|---|---|---|
| M1-D1 Open-source WEAVE Tool | |||
| M1-D2 Hosted WEAVE App + API | |||
| M1-D3 Incentive Program Launch | |||
| M1-D4 Public KPI / Reporting Surface |
Livepeer Inc Daydream Product Update
Hi all. I wanted to provide a product update from Livepeer Inc so that the community could see all that’s being built as we focus on Livepeer’s Realtime AI infrastructure opportunity.
Much of this information is available by following along on the Daydream X Account, the Daydream Discord, and the Scope release notes, but is summarized here for the Livepeer community.
Daydream
As you know, Livepeer Inc is primarily focused on finding demand for the Livepeer Network’s realtime AI capabilities through the Daydream brand. Realtime AI video is an early space where Livepeer is suited to offer unique value because of its GPUs and low latency streaming stack, expertise, and ecosystem alignment - however the arrival of the market remains dependent upon when key open source model capabilities drop that are acceptable to enterprise grade commercial use cases.
Because of the early state of the market, Daydream has developed an open source community oriented workflow management tool called Scope.
Scope is a local-first, open-source engine for real-time AI generation across video, audio, and computer vision. Creators compose custom pipelines visually, plug into their existing tools, and run inference on their machine or in the cloud via the Livepeer Network.
It incorporates the latest realtime AI models, lets users configure them into custom workflows we pre-and-post-processors, LORAs, audio + video input sources and outputs, and more. The early tinkerers and researchers in this market are using Scope to get access to, and control, the latest innovations in the space. And as more mainstream usable models arrive, this foundation will be the best control plane to get the outputs that users want. Here are some of the latest features to ship.
- Real-time video compositing powered by VACE. Edit and transform live video with inpainting, outpainting, and style transfer running at interactive framerates. This is continuous inference, not asynchronous generation. Every frame goes through the pipeline.
- Node-based workflow builder. Build custom AI pipelines by connecting nodes visually, spanning generative video, audio, and computer vision. A new scheduler node lets you fire timed triggers across the graph, and the canvas UX is designed to get you from zero to running workflow fast.
- Remote inference via the Livepeer Network. Scope offloads GPU-heavy workloads to the cloud rather than requiring a local 4090. Artists and developers without high-end hardware become direct network consumers. This is the link between Scope adoption and Livepeer demand.
- Plugin architecture for community-built nodes. The v0.2.4 release introduced a node abstraction system that lets anyone ship a custom Scope plugin. Initial examples include a YouTube input source and a local LLM prompt enhancer. The ecosystem is just getting started.
- LoRA style control. Apply and blend LoRAs for fine-grained aesthetic control, from subtle adjustments to full style transforms. Scope handles LoRA manifest resolution as part of workflow configuration.
- Shareable, importable workflows. Export and import full pipeline configurations, including LoRA manifests and dependency resolution. This makes community sharing practical and lowers onboarding friction for new users finding Scope through Daydream.live.
- Beat-synced parameter modulation. Parameters sync to Ableton Link and MIDI clock, making Scope viable for live performance where timing matters. OSC support extends reactive control to any tool that speaks the protocol.
- Integrations for professional creative tools. Scope connects to TouchDesigner (including the StreamDiffusionTD plugin by dotsimulate’s Lyell Hintz), Resolume, and other creative software via NDI, Spout, Syphon, OSC, and MIDI. This is where Scope reaches the communities most likely to run persistent, high-throughput inference on the network.
- Audio generation alongside video. Pipelines can return audio alongside video output, streamed over WebRTC. Scope is no longer a video-only tool.
- LTX-2 video model with ~18x faster loading. The latest LTX-2 integration ships with real-time pacing controls, faster model loading, faster prompt changes, and Ampere GPU compatibility. New users get text-to-video out of the box.
- MCP server for agentic workflows. Scope exposes an MCP server interface, connecting it to AI agent frameworks. Early infrastructure for a category of agentic, real-time AI applications that could drive sustained inference demand on the network.
Realtime Audio Generation
While realtime AI video and world models remain interesting early prototypes, many of the users who are getting value out of Scope are overlapping with the audio space. Often times performers, VJs, musicians are using scope to generate visuals for live performances, concerts, or event installations, because Scope enables the AI outputs to respond to the audio inputs themselves. Naturally, this is leading to a lot of interest in integrations with audio tools (Resolume), and even generative audio generation itself.
More to come on this in a future update (or join the upcoming water cooler chats to see live demos), but the team has worked on some research breakthroughs to get audio generating in realtime using one of the previously batch-only open source models. This is a big break through that lets creators actually configure AI as an instrument that plays along or modifies songs in real time, responding to many different input or prompt changes instantly.
Video is early and requires some model and workthrough breakthroughs before being widely adopted, however this realtime audio generation is compelling and high quality enough to make an impact today. Look for some proof of concept applications coming soon to test driving demand to Livepeer through these channels.
The Path to the Livepeer Network
As with all new capabilities developed by within Inc, typically we first work on validating demand with early users through prototypes and early productionization of our products. Typically the fastest path here is using cloud infrastructure at low volumes so that the community doesn’t have to incur the work of adding support for new experimental capabilities if there’s no actual demand or market fit.
The next phase typically consists of Livepeer Network pilots, using self-run infrastructure on the network and working with select orchestrators willing to run these job types early as they’re developed, so that they can be built the right way.
Next you typically see scaled load testing and redudnancy/backup service provided by the network. The Inc products typically use the cloud for some traffic, and duplicate it to the network to evaluate its performance and realiability. Eventually shifting more and more to the network as its primary source of traffic. Why? Because the Livepeer network is typically far more cost effective than the cloud - and ultimately needs to be as reliable or better.
Finally Inc deprecates any cloud infrastructure entirely, and relies entirely on the network. This is the path that Studio went through in the early days, before relying solely on the Livepeer network for transcoding traffic. And it is the path that Daydream and Scope are undergoing as well. Currently Scope is routing traffic through the Livepeer network, and is onboarding select O’s to troubleshoot the integrations for popular workflows.
Livepeer Studio
With the focus on Daydream and the Realtime AI opportunity, Livepeer Studio continues to support existing customers, but is not primarily focused on growing further demand generation through transcoding or streaming. As previously communicated, we’re working with the Frameworks team to carry the torch on transcoding and a modern low latency streaming stack on top of the network, and pursuing demand generation efforts on that track. And Orchestrators will likely see transcoding volumes from Studio ramping down in the coming months..
Orchestrator guidance from a Daydream perspective
Daydream is trying its hardest to find Product-Market-Fit and drive scaled demand to the Livepeer Network! But as we remain early in that process across our ambitious bets, its important to note that many of these GTM efforts are experiments. New models and capabilities drop, each often times requiring different hardware. We are committed to bringing demand to the Livepeer network, and the best way for Orchestrators to support is to flexibly provision hardware in support of these experiments. That may mean spinning resourced capacity up and down as experiments ebb-and-flow. It likely does not mean over-investing in purchased dedicated hardware until it is clear there is scaled demand for a job. Orchestrators should share openly and honestly what pricing they need to charge in support of these experiments, and consider the impact of delegated stake and reward cuts on their P&L when doing so.
Thanks everyone. Looking forward to showing off some of the latest Scope and realtime AI capabilities on the upcoming water cooler chats.
", replyCount: 2, views: 136, likeCount: 12, datePosted: "May 6, 2026", lastActivity: "May 6, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "LiveInfra SPE - Q2 2026 Operations", href: "https://forum.livepeer.org/t/3241", author: "By Joey (@ftkstaking)", content: "Proposer: FTK Staking
Contact: admin@liveinfraspe.com
ENS: liveinfra.eth
Discord: @ftkuhnsman
Abstract
The LiveInfra SPE requests funding for Q2 2026 to sustain the Community Node service, a free RPC service for the Livepeer community. This proposal covers recurring operational costs for cloud infrastructure, maintenance, and support.
Mission
The LiveInfra SPE is dedicated to empowering the Livepeer community by providing free, reliable blockchain infrastructure services.
Problem and Importance
Livepeer community members depend on accessible blockchain infrastructure to develop decentralized video applications and tools. Operating RPC nodes is costly and complex, and third-party providers charge high fees. The Community Node service delivers free Arbitrum L2 and Ethereum L1 RPC endpoints, removing these barriers.
Rationale
Continued funding for the LiveInfra SPE ensures the Community Node service remains a dependable, cost-free resource for Livepeer builders. Quarterly treasury proposals align with community oversight, minimize market impact on LPT, and allow flexibility to adapt to evolving ecosystem demands.
Current Operations
The LiveInfra SPE provides free Arbitrum L2 and Ethereum L1 RPC endpoints to Livepeer community members (active orchestrators, broadcasters, and delegators with ≥100 LPT staked). It operates with geo-distributed Ethereum L1 nodes (execution and consensus) and Arbitrum Nitro L2 nodes, load-balanced for reliability. A custom proxy layer authenticates user requests via unique URL endpoints, accessible after wallet-based signup. To sign up visit the LiveInfra SPE website and authenticate with your livepeer wallet.
Q2 2026 Operations Plan
This proposal focuses on sustaining service operations for Q2 2026 (April–June). No new features are proposed in the current maintenance period.
Milestones and Timeline
- April–June 2026:
- Maintain to support node operations.
- Perform ongoing maintenance, including software upgrades, node database pruning, and storage expansion as needed.
- Monitor and ensure 99.9% uptime, with transparent reporting via the KPI dashboard.
- Provide community support for RPC service users.
- Ongoing:
- Submit the next quarterly proposal (Q3 2026) to secure continued funding.
Budget Breakdown
The LiveInfra SPE requests $14,000 USD for Q2 2026 to cover recurring operational costs. Funds will be converted to LPT at submission using the current LPT price, with a margin to buffer against price volatility during voting.
- Quarterly Recurring Costs - $14,000
- $9,000 USD - Infrastructure: Quarterly costs for high-quality cloud resources.
- $5,000 USD - Maintenance & Support: Quarterly node upkeep, software upgrades, database pruning, and user support - $2,500 reduction from prior quarter due to improvements in operational efficiency and platform stability.
Total Request USD: $14,000
Total LPT tokens requested: TBD - Determined at submission based on the current LPT price.
Funding Strategy
The LiveInfra SPE will continue submitting quarterly treasury proposals to fund operations, ensuring:
- Minimized Market Impact: Requesting smaller LPT amounts each quarter and selling gradually to reduce price volatility.
- Community Oversight: Quarterly proposals allow the Livepeer community to assess the service’s performance and value, approving continued funding or requesting adjustments as needed.
This approach ensures transparency, sustainability, and alignment with community priorities.
Community Feedback and Suggestions
The LiveInfra SPE values input from the Livepeer community to ensure the RPC Service continues to meet ecosystem needs. We invite community members to suggest enhancements, new features, or additional infrastructure offerings during the pre-proposal review process. Please share your ideas directly in the Livepeer forum as part of the discussion for this proposal. Your feedback will help shape future proposals and ensure the service evolves to support the community’s goals.
", replyCount: 1, views: 55, likeCount: 4, datePosted: "Apr 21, 2026", lastActivity: "Apr 24, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Embody Team: Updates", href: "https://forum.livepeer.org/t/3215", author: "By DeFine (@DeFine)", content: "Embody Team: Retrospective
Date: February 9, 2026
This document provides a retrospective of the Embody team’s (DeFine + Dane) workstream, covering the Agent SPE Phase 2 period and post-separation efforts through February 9, 2026. Our focus is on the open-source deliverables and technical contributions made to the Livepeer ecosystem. This retrospective is scoped to the Embody-managed workstream and does not cover the full scope of the Agent SPE Phase 2 grant.
Executive Summary: What We Shipped
•Open-Source VTuber Stack: Shipped and maintained Unreal_Vtuber, a Pixel Streaming stack enabling Livepeer orchestrators to run embodied MetaHuman avatars. Tagged open-source releases from v1.0.0 (December 18, 2025) through v1.3.5 (January 28, 2026).
•Dynamic Customization: Delivered extensive avatar and environment customization, including a character customizer, morph targets, hair, clothing, and camera controls, as documented in the weekly work logs.
•Incentives Pipeline: Delivered and maintained an orchestrator incentives program, funded from Embody-managed inference credits. This work was outside the strict Phase 2 scope.
•Multi-Platform Broadcast Pipeline: Built a broadcast-capable pipeline (WebRTC source with an optional RTMP output for platforms like Twitch and YouTube). Automation of this pipeline is in active development.
•Continued Work Post-Separation: Despite a reduced budget following the separation from Agent SPE, the Embody team continued execution and completed the majority of technical and non-technical deliverables.
Timeline Highlights
•April 14, 2025: Phase 2 begins.
•August 20, 2025: Separation settlement and allocations are publicly posted.
•December 18, 2025: First tagged Unreal_Vtuber open-source release (v1.0.0).
•January 28, 2026: Unreal_Vtuber v1.3.5 is tagged.
•February 7, 2026: On-chain reconciliation packet is produced.
Promised Deliverables vs. Current Status
This section is structured by the Phase 2 proposal’s “Months 1–6” deliverables, with Embody’s current status and evidence pointers. Items Embody did not manage (funds and execution) are explicitly marked as Defer to Agent SPE.
| Deliverable | Status (Embody) | Evidence |
|---|---|---|
| Technical Excellence | Delivered a full embodied-avatar pipeline and operational Pixel Streaming stack. The “sub-100ms” latency target from the proposal is a goal; this document does not include an independent benchmark. | Unreal_Vtuber OSS stack |
| Livepeer Integration | Delivered. Orchestrators can run embodied avatars via the open-source stack, and Phase 2 weekly logs show Livepeer inference integrations and related pipeline work. | Unreal_Vtuber OSS stack, Livepeer-Autogen-Integration, plugin-livepeer-inference, NeuroSync-Core, eliza-livepeer-integration |
| Streamlined Onboarding | Delivered simplified operator onboarding for the OSS stack. The “<5 minutes” figure is a proposal target, not a universally measured setup time. | Unreal_Vtuber OSS stack |
| Comprehensive Analytics | Partially delivered. OSS/runtime telemetry exists, and production-validation analytics were set up via PostHog (not a treasury deliverable). | PostHog work is documented in internal repository files. |
| Dynamic Customization | Delivered. Dane’s Phase 2 work (Animator Handbook) documents extensive customization work. | Animator Handbook |
| Multi-Platform Deployment | Delivered a broadcast-capable pipeline (Pixel Streaming → RTMP) and ongoing operator automation for autonomous streaming. A fully autonomous, interactive VTuber is live and continuously improving, with memory and background tool-use capabilities. Note: the autonomous agent is continuously improving, and its current state represents the baseline of its capabilities. | Livi Embody — Autonomous VTuber (Twitch) |
| Protocol Partnerships | ElizaOS integration plans were paused/deprioritized; the primary execution path pivoted to Embody-managed direct integrations. | eliza-livepeer-integration |
| Startup Integration Program | Defer to Agent SPE. Embody did not manage these funds post-separation. | Separation Post |
| Usage Incentives | Defer to Agent SPE for the original proposal line item. Separately, Embody did operate and maintain an orchestrator incentives program funded from the inference credits allocated to Embody. Note: Livepeer stakeholders requiring the full unredacted financial/accounting pack may contact the Embody team. | Public Financial Audit Pack |
| Use Case Demonstrations | Delivered multiple demonstrations and continues to iterate on use cases, including a live autonomous interactive VTuber stream. | Livi Embody — Autonomous VTuber (Twitch), Livepeer Fireside Appearance, Unreal Vtuber Demo |
| Financial Sovereignty Infrastructure | In progress. Will be released this week with the public release of the OpenClaw agent repository. | Release pending. |
| Diversified Revenue Frameworks | Embody has begun operating in the agent-to-agent economy(see embody.zone). A further community update on this deliverable will follow within the week. | embody.zone |
Sources Used
", replyCount: 1, views: 129, likeCount: 4, datePosted: "Feb 10, 2026", lastActivity: "Mar 25, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "How Livepeer Solves The Tech Industry's Biggest Dilemma", href: "https://forum.livepeer.org/t/3257", author: "By Dane (@webRTCisCool)", content: "Introduction
With the Clarity Act getting closer to realization I’ve been pondering which protocols will benefit the most. Obviously the act has not passed and therefore, nothing is guaranteed or set in stone. However, based on the current language of the act, tokens with real utility, high levels of decentralization, and strong community will be categorized as digital commodities. Based on this language I believe Livepeer is safe. Livepeer’s utility is undeniable and may serve as a solution to the technology industry’s biggest problem. Resource intensive infrastructure.
The Problem
Centralized compute providers are relying on massive datacenters that require a ton of energy and cooling that only increase with demand. This creates negative sentiment around not only the data centers, but the deployments those data centers support, which right now leans heavily into AI and ML.
The Solution
Livepeer NaaP could potentially be the industry’s saving grace. While we don’t think about it every day, because of our immediate access to it, fresh water, energy, and land are all critical resources. As demand for compute continues to grow, so does the need for efficient ways to handle that demand.
Livepeer’s ability to provide compute for resource intensive use cases can help redistribute some of that demand across node operators that don’t necessarily rely on water intensive cooling infrastructure. If centralized providers continue to scale data centers aggressively, especially in drought stricken areas, governments may eventually step in to regulate resource usage, forcing providers to think differently about how cloud based software is deployed.
Decentralized networks like Livepeer offer a solution. Instead of concentrating compute in a few large facilities, workloads can be distributed across orchestrators using existing hardware that is far less reliant on our extremely valuable land, lakes, and rivers.
Conclusion
I am not saying decentralized compute or Livepeer replaces data centers, but acts as an environmentally friendly solution to handle growing demand through decentralized compute distribution. If Livepeer can capitalize on this specific issue, the protocol may help offset resource consumption. Potentially reducing the need for hundreds of millions to billions of gallons of water usage, and hundreds of acres of would-be datacenter land over time.
The Clarity Act favors real utility and decentralization. Livepeer is the definition of real utility and decentralization. With engineers working hard around the clock to increase the network’s accessibility, capabilities, and transparency, Livepeer is well positioned to solve or help alleviate the biggest problem our future generations will face.
GO LIVEPEER!
", replyCount: 0, views: 42, likeCount: 3, datePosted: "May 21, 2026", lastActivity: "May 21, 2026", categoryId: 6, categoryName: "Protocol", categoryColor: "#BF1E2E" }, { title: "Ecosystem Roadmap Update", href: "https://forum.livepeer.org/t/3234", author: "By b3nnn (@b3nnn)", content: "Activating the Livepeer Ecosystem Roadmap — What’s Changing and How to Get Involved
The Ecosystem roadmap at roadmap.livepeer.org has never fully satisfied us. It’s basically been a display board rather than a genuine two-way system between the Contributors, Foundation and the broader community.
We’re now fixing that. I’ll explain what’s changing and what we need from everyone in the ecosystem.
What the Roadmap Is For
The roadmap exists to make ecosystem direction visible, coherent, and participatory.
It is not a promise or a project plan. It is a shared and evolving view of where the network is headed. This includes projects being worked on, who is driving them, and where there are opportunities to pick things up or get involved.
Every item on the roadmap defines a problem, a desired outcome, and who owns it. Items previously came from only two sources:
-
Advisory Board Recommendations — captured from the project with domain experts last year
-
Foundation Priorities — strategic improvements identified and funded by the Foundation
And, excitedly we now introduce a third way for things to enter the roadmap:
- Community Suggestions — ideas submitted and validated through our community process
In this way, the Roadmap becomes further signalling for the things people want to see come to the network, and a way for everyone to put forward impactful projects and provide upvotes are genuine input signals — not performative ones — towards what gets prioritised.
Why a Community Intake Process Matters
Until now, there has been no clear path for a community member to propose something and see it taken seriously without testing it with a formal forum post or completing an SPE proposal. A lot of great suggestions and discussions were had in Discord or raised on Watercooler’s, but with no structured process, no feedback loop, and no progress, many were lost.
That’s a problem for two reasons. First, the ecosystem has real expertise distributed across contributors, orchestrators, builders, and delegators. Some of the best ideas about what Livepeer needs to build next will come from people outside Inc and the Foundation. Second, without a visible process, community participation in the roadmap is essentially performative and people have no reason to engage if engagement doesn’t lead anywhere.
A real intake process changes that. It creates accountability on both sides: the community commits to submitting well-formed proposals and raising the standard of what we want to see from suggestions, and the Foundation commits to reviewing them, providing a space and rituals for them to see further discussion, and publishing those discussions and any decisions to help advance items in ways that make sense.
The New Community Suggestions Process
Anyone in the Livepeer ecosystem can now propose a roadmap item at any time. Here’s how it works:
Step 1 — Submit a proposal
Go to roadmap.livepeer.org and click “Suggest an Item” (in future you will be able to simply type /featurebase directly in Discord). A good proposal answers three things: What is the problem? Why does it matter for the ecosystem? What does success look like?
I’ve included two project “proposals” that were recommended as part of the discussions on the emissions system which can act as helpful examples and jumpstart the monthly call:
Step 2 — Community upvoting (ongoing)
All proposals are publicly visible in the roadmap with the tag “Propose Ecosystem Project”. Upvote and comment on proposals you care about at any time. Momentum is tracked — strong community support between monthly cycles can fast-track a proposal into the next review.
Step 3 — Foundation weekly review
We will aim to review the proposal queue every week and provide some feedback about how to prepare for the monthly Discord call. The aim here is to get things well prepared and to knock out early things that are maybe not going to reach a bar that we all feel is needed for high quality suggestions.
Step 4 — Monthly Discord call
Once a month proposals are presented on a community Discord call (if not the Watercooler, another forum). We’ll make a quick intro for each including upvotes and comments, the Proposer can give a short discussion, and then community asks questions and discusses live. After the call, the Foundation will publish key information and based on sentiment aim to reach a decision that can be shared: Promoted to Roadmap, Held for Next Cycle, or Declined with a public explanation.
Proposals that are promoted join the roadmap with status Under Review and from there move forward to planning - most likely as an RFP, a SPE Proposal, or some other mechanism that makes sense (more on this to come).
How to Use the Roadmap
The roadmap will work best when the community is actively engaged. We’ll start to talk about it more effectively on the Watercooler. But here’s what we need from you:
Upvote items you care about. This does two things: it signals priorities to the item owners, and it subscribes you to all future updates on that item. When an item’s status changes, you’ll be notified automatically. Your upvote has a visible consequence.
Comment on items. Share context, ask questions, flag concerns, or offer to contribute. Comments are read by item owners and the Foundation. Good comments surface edge cases and use cases that owners may not have considered. Good feedback here can shut things down before wasting everyones time, but also can give the right spark for a simple idea to be a gamechanger!
Follow the changelog at roadmap.livepeer.org/changelog. Every major milestone on a roadmap item generates a changelog entry. This is the progress reporting mechanism for the ecosystem — if you want to know what’s actually shipping, the changelog is where to look.
Propose new items if you think something important is missing. The bar for submitting is low — a clear problem statement, the reason is matters, and what the future looks like if that proposed item becomes a success. The intake process can take it from there. Items might make it to the roadmap, or be bundled or merged with others “under” an SPE.
For teams shipping roadmap items: update your item’s status when it changes (this auto-notifies everyone who upvoted), and post a changelog entry at each major milestone. The changelog is your public progress report — it replaces ad hoc updates scattered across Discord and forum threads.
A Note on What This Is Not
This is not a governance mechanism. In time this can become a good funnel for the onchain treasury but for now we want this to become a way to surface useful recommendations and priorities and created a clearer, more participatory and better recorded feedback loop. The proposed items and upvotes are strong input signals — not binding votes. This is intentional: it keeps the roadmap strategically coherent while ensuring community voice is genuinely considered and visibly acted upon.
If a proposal is declined, people will know why. Transparency is a key part of this commitment. And people can always still take things to a vote onchain.. this just raises the bar for proposing something if it’s already been tested with the community in this way
Get Started
The roadmap is already live at roadmap.livepeer.org. The suggestions board is open now.
If you’ve had something in mind that Livepeer shoud be building or capitalising on, now is a great time to share it. We will run the first Monthly call at the end of Mark. And if you have questions or feedback just drop them in here.
", replyCount: 0, views: 67, likeCount: 3, datePosted: "Mar 9, 2026", lastActivity: "Mar 9, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "AI capability discovery", href: "https://forum.livepeer.org/t/3233", author: "By chrishobcroft (@chrishobcroft)", content: "Can someone help me learn how to reliably query which AI capabilities and models the network offers?
I’m running a gateway on localhost with 0.065 deposit and 0.03 reserve. I’m managing to get some text-to-image jobs through, which is a great start.
Ideally it would be great to be able to query:
- all available job types,
- which models are available,
- what the O’s pricing is.
It seems like an obvious thing from my limited perspective, that an O will advertise its services to a G.
Any clues?
", replyCount: 0, views: 35, likeCount: 2, datePosted: "Mar 7, 2026", lastActivity: "Mar 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }]; export const forumByViews = [{ title: "Telegram Bot: Transcoder-Watcher", href: "https://forum.livepeer.org/t/609", author: "By vires-in-numeris (@vires-in-numeris)", content: "Over the past few days, I’ve been further developing the Transcoder Watcher Bot running in my 0x525 Transcoder Telegram Channel. It was my goal to create a tool that everyone can use to get notified about transcoder events and here it is:
The Telegram Transcoder-Watcher Bot!
You can find the bot here: https://t.me/TranscoderWatcher_bot
What does it do?
By writing “/start”, the bot will give you an introduction and informs about the available commands:
- subscribe
- remove
- subscriptions
- history
details here: Telegram Bot: Transcoder-Watcher
If you subscribe to a transcoder (or multiple, there is no limit), you will get notified about the following events:
- reward calls
- missing reward calls
- reward cut changes
- transcoder becomes inactive
Whenever possible, I include the transaction link so you can be sure that no incorrect information is sent. However, please note that the bot is still in the testing phase and of course it’s always possible that the script crashes and the bot stops working.
How does it look like?
Here are some screenshots for the various events.
- Reward Calls:
- Missing Reward Calls:
- Reward Cut changes:
- Transcoder becomes inactive:
If you discover any error or have feature requests, you can reply here or send me a message on discord!
", replyCount: 16, views: 5777, likeCount: 16, datePosted: "Mar 21, 2019", lastActivity: "Mar 8, 2026", categoryId: 7, categoryName: "Transcoders", categoryColor: "#25AAE2" }, { title: "Streamplace 2.0: Solving Video for Everybody Forever", href: "https://forum.livepeer.org/t/2847", author: "By Eli Mallon (@iameli)", content: "EDIT: Updated proposal later in the thread.
Hey everyone. I’ve been tinkering with this draft all week but just wanted to get it out there ASAP to kick off the process. For more context, check out my presentation to the treasury last Monday - Part 1 and Part 2.
STREAMPLACE 2.0: SOLVING VIDEO FOR EVERYBODY FOREVER
Summary
We’re requesting 250,000 LPT to continue building the video layer for the next generation of decentralized social. In less than a year, Streamplace (née Aquareum) has evolved from a concept to a functional platform powering thousands of hours of livestreaming, securing partnership with Skylight (a TikTok alternative that reached #1 in entertainment on the App Store), and establishing itself as the go-to solution for live video on the AT Protocol.
The Livepeer treasury made all of that happen, and we’re thrilled to be continuing to fund the project as a shared public good. With your support, we’ll expand our infrastructure, hire specialized talent, enhance moderation capabilities, deepen AT Protocol integration, develop VOD functionality, and explore monetization options—all while maintaining our commitment to open-source development and building public infrastructure.
What We’ve Accomplished
Technical Achievements
- The Protocol: Streamplace has invented a novel form of decentralized livestreaming. Our technique, utilizing C2PA-powered Ethereum signatures over one-second MP4 files, is both cryptographically secure and easy to work with.
- The Node: The Streamplace node runs on all major platforms — Windows, macOS, and Linux, and supports AMD and ARM64 architectures. The node is a single file - deployment is the easiest thing in the world. It’s available for download at Stream.place!
- The App: We shipped the Streamplace mobile app to the App Store and Play Store; Streamplace Desktop is also available for download on Windows, Mac, and Linux. Grab it at https://app.stream.place!
- Implemented WHIP and WHEP protocols The Streamplace node utilizes WebRTC for the entire stack — this makes it super easy to support streaming from browsers and phones while delivering low-latency video playback for viewers.
- Libraries: We shipped c2pa-go, the first library for using C2PA primitives in Go. We implemented Ethereum key support in c2pa-rs and shipped the first library for AT Protocol Oauth using React Native, which is in production in multiple atproto applications.
- Livepeer transcoding: All streams through stream.place are transcoded on the Livepeer network, establishing LIvepeer as a key component in the next generation of decentralized social.
Community & Market Traction
- Sponsored ATmosphereConf livestreaming - Streamplace sponsored the first ATmosphereConf; we both operated the livestream and produced the stream on-site. It went really, really well!
- As a direct consequence, we were featured in TechCrunch as a part of a roundup of next-generation apps building on atproto — we were all by ourselves in the livestreaming category!
- Skylight Social partnership - Also as a direct consequence of the conference, we’re bringing livestreaming to Skylight Social, a Mark Cuban-backed TikTok alternative that recently reached #1 in entertainment and #7 overall on the iOS App Store. Skylight surpassed 150,000 users in the first three days after launch and users are consistently pinging their team asking to go live. As soon as this feature ships, all of this livestreaming will be going through the Livepeer network!
- Established ownership of the live video niche on the AT Protocol. Not only that, but Streamplace will be one of the earliest projects to launch significant video content outside of Bluesky’s infrastructure, contributing to the decentralization of the protocol.
All of this has been achieved while keeping every single line of code open-source and freely licensed.
The Opportunity
We’re at a critical inflection point. We’ve proven the concept works, secured key partnerships, and demonstrated clear product-market fit. Rather than pursuing venture capital with its inherent pressure toward extractive business models, we’re seeking continued support from the Livepeer treasury to pioneer a new public goods funding model—one focused on solving hard technical problems for the benefit of an entire ecosystem.
Funding Allocation (250,000 LPT)
Team Expansion
We need to bring on more people full-time to actually deliver on this dream; to start off we’ll be hiring a designer/front-end engineer and a video expert for hardening the node. Additionally, we’re planning on contracting out bounties and collaborating with other projects in the ATProto and Livepeer ecosystems on projects like code generation and SDK development to start to make Streamplace technology as accessible as possible.
Infrastructure Enhancement
- Servers and Scaling: It’s imperative that we deliver a great first impression to this community, and that means scaling up to handle demand and expanding our server infrastructure.
- Performance Hardening: Veterans of Livepeer Studio know there’s a huge gulf between something that mostly works and a battle-hardened piece of video infrastructure. It’s imperative that we deliver a great first impression; decentralized social needs to work at least as well as existing.
- Reliability Testing: Ensure consistent performance under varying network conditions
Core Technology Development
- AT Protocol Integration: Develop deeper, more native integration with AT Protocol. Currently the integration is relatively shallow; a signing key on a users’ PDS links the two accounts. We’re aiming to assist in the development of the protocol.
- NPM Packages: Streamplace has been architected from the ground up to be embeddable in other apps but we haven’t yet actually shipped this capability. With the Skylight partnership we’ll be building out the capabilities to embed broadcast and playback within other apps and websites; other atproto apps have also expressed interest.
- Clipping and VOD: Build decentralized video-on-demand capabilities (beyond Bluesky’s current 3-minute limit)
- Transcoding Infrastructure: Support increased transcoding demand from Skylight users via Livepeer Network
Trust & Safety
- Moderation Systems: As part of the Skylight launch, we will be building out a full content moderation infrastructure, utilizing AI models backed with human moderators. This kind of thing isn’t always emphasized in the Web3 space, but it’s essential to comply with mass market adoption.
- Community Standards: We plan on developing transparent guidelines aligned with decentralized values.
Growth & Sustainability
- Stream Incentives: Programs to encourage creators to use the platform
- Monetization Framework: Explore micropayment systems and creator revenue models in collaboration with others in the atproto space.
- Custom App Development: Our pitch to big Twitch streamers isn’t “switch from Twitch to Streamplace,” it’s “switch from Twitch to your own app, powered by Streamplace infrastructure.” This facilitates a direct relationship between creators and their fans, while the Streamplace layer still enables all the social features of a rich livestreaming platform - chat, hosting, and such.
Vision
We’re not just building a livestreaming platform—we’re establishing the infrastructure and primitives for an entire generation of video applications on decentralized social networks. Our ultimate goal remains unchanged: solving video for everybody, forever.
With your continued support, we can create something truly revolutionary: a creator-sovereign, open-source video layer that enables experiences on par with centralized platforms but aligned with the values of decentralization.
Thank you for considering this proposal. Let’s continue building the future of decentralized video together.
", replyCount: 28, views: 1472, likeCount: 77, datePosted: "Apr 12, 2025", lastActivity: "Apr 28, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Continuing discussions on Inflation", href: "https://forum.livepeer.org/t/3139", author: "By b3nnn (@b3nnn)", content: "Hey everyone, I wanted to use this post to reinvigorate the inflation discussion led by @dob in this thread earlier this year.
As a member of the Foundation, and as chair of the Capital Markets Advisory board, I think it’s important to keep us moving forward on this as it part of broader perceptions of the Livepeer project, is part of the broader industry focus on ‘fundamentals’, and is a key component of how capital is allocated within our ecosystem.
From previous discussions (and some new ones), it seems there is broad consensus on the need for small and incremental action. I see my role as helping give a little nudge so we take that small but important first step.
The previous draft from Dob got us to the starting line of what a proposal could look like. My personal tldr of the thread was that:
-
There was general alignment that we should start taking some action
-
There’s alignment on using existing parameters, which avoids risks or delays from new protocol or smart contract work
-
But.. the sticking point was whether to do that using
targetBondingRateorinflationChange, or both, and how to do it in a principled, risk aware way rather than using something that might feel a bit arbitrary
Reinforcing all of this, during the Livepeer summit Doug and Arunas /@Jonas_Pixelfield completed a hackathon project that both modeled parameter changes and surveyed a sizeable set of Orchestrators and Delegators on their perceptions. A short summary is that:
-
Simple modeling shows small parameter changes lead to effects over a fairly long time horizon (in the range of 12+ months to reach something that might be considered major change). This gives ample time to start, observe, and learn and adapt as necessary as we go
-
The survey and interviews further reinforced the consensus from Orchestrators and Delegators that they see the need for action, but sometimes struggle to find confidence with any given approach
With all this in mind, I want to share what we plan to do to help the community move forward:
-
Firstly, we want to keep discussing the Inflation topic with Orchestrators and Delegators. Two ways to do this include:
-
Completing a short survey to expand on your thoughts about the topic
-
Book a meeting where we can discuss or asnwer any questions in real time
-
-
Secondly, we intend to try to quantify the risks involved with some additional modeling. I’ve asked Andrew from Shtuka Research (who is a member of the Capital Markets Advisory board) to take the lead on this. Andrew is a mathematician with a long career in academic and applied research, who will help quantify the risks of different change scenarios. He’ll also be helping us build out a framework for continual risk monitoring and adjustment in the future, so that we can all have confidence to move forward to voting on any proposed changes.
Hopefully you agree that these goals are a relatively simple way to make that last important push and build on the broad consensus reached so far. This is not a one-and-done topic so we will share a bit more about what the path ahead could look like as we get more information.
I’m going to sign off here so that Andrew can share a bit more about the survey and modeling, and I’d encourage anyone who wants to chat on this topic to reach out to me direct via DM on Discord or by using my calendar link share above.
", replyCount: 20, views: 1045, likeCount: 50, datePosted: "Nov 5, 2025", lastActivity: "Mar 2, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "RFP — Explorer Maintenance", href: "https://forum.livepeer.org/t/3072", author: "By Rick (@rickstaa)", content: "Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rick Staa
1. Objective
Restore the Livepeer Explorer to a secure, maintainable, and high-performance state while laying the groundwork for new network-wide data and governance dashboards.
2. Problem Statement
The Explorer is the primary entry point for orchestrators, delegators, developers, and gateways. However, since December 2023 lack of ownership has accumulated significant technical debt:
- Outdated dependencies in the Explorer and design system, fragile under Node 20, break on updates and could lead to security risks, undermining long-term maintainability.
- Duplicated/obsolete code and missing contribution infrastructure (guidelines, CI/tests, stubs), making contributions slow and error-prone.
- Inefficient data fetching (e.g. Infura/Graph duplication), creating performance issues.
- A backlog of unmerged PRs and unresolved bugs (e.g., broken migration widget, UI inconsistencies, incorrectly displayed data).
A future roadmap for expanded network data and richer Explorer stakeholder experiences depends on first restoring a stable, secure, and maintainable Explorer. This RFP focuses on that critical first step.
3. Desired Outcome
Success means that within four months the Explorer is:
- Clean, well tested, with automated tests and continuous integration pipelines, providing a healthy, maintainable codebase.
- Free of critical bugs and stale pull requests, with a clearly organized issue backlog.
- Running on up-to-date, secure dependencies (Explorer and design system) fully compatible with the current Node.js LTS.
- Improved in performance, with faster page loads and a simplified, well-documented data layer for developers
- Equipped with a new voting-transparency feature integrated with the voting-tally subgraph.
- Backed by a clear 6-month roadmap and a dedicated maintainer team providing ongoing maintenance and timely support.
In short, the Explorer will be trusted infrastructure and ready to power further iteration of capabilities.
4. Deliverables
Within four months (target completion by February 1, 2026), the selected team will deliver the following milestone-based outcomes.
Each deliverable must be demonstrated in a Livepeer community call, and the team must provide public progress updates at least every two weeks (e.g., forum posts) throughout the project.
Payments are released only after each demo is accepted by the RFP owner.
(i) Establish Healthy Explorer Codebase
Goal: Deliver a clean, maintainable, and well-tested Explorer foundation to enable ongoing community contributions.
Requirements:
- Remove unused and duplicate code.
- Reorganize folder and module structure, where needed, to improve navigation and long-term maintainability.
- Add comprehensive unit and integration tests covering all critical user flows (e.g., staking, delegating, governance), with measurable coverage targets proposed by the vendor.
- Implement CI pipelines for reliable builds and automated checks.
- Ensure all components are fully typed (TypeScript) and all ESLint/TypeScript errors resolved.
- Provide clear contributor documentation and review workflow, with local-development stubs/mocks so the codebase can run without production environment variables.
Outcome: A clean, healthy, well-tested codebase with CI pipelines and local stubs that contributors can run with minimal setup, forming a solid foundation for future improvements.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the cleaned codebase, CI, tests, and contributor docs.
(II) Improve Data-Fetching Efficiency
Goal: Enhance the Explorer’s data layer to reduce latency, eliminate redundant calls, and ensure responsive, reliable performance for end users and contributors.
Requirements:
- Optimize subgraph and RPC data fetching to reduce latency, avoid duplication, and improve responsiveness.
Outcome: A faster, more efficient Explorer with reduced redundant calls and a simplified, well-documented data layer for easier future contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, showcasing faster data fetching and improved data-layer developer documentation.
(III) Resolve Critical UI Issues & Backlog
Goal: Eliminate high-impact bugs and stale pull requests to ensure a stable, accurate, user-friendly Explorer.
Requirements:
- Resolve all current critical UI bugs (GitHub bug list), including the delegator migration widget, data inaccuracies, and major UX defects, and triage/fix any new critical issues during the engagement.
- Review and merge, close, or supersede all open pull requests (GitHub pull requests) other than the voting-transparency feature (covered in Deliverable 5).
- Work with the Foundation and Advisory Boards to prioritize any other high-impact feature requests from the backlog that fit within the agreed budget and timeline.
Outcome: A more stable, accurate, and user-friendly Explorer with all critical issues resolved and a significantly reduced bug backlog, ready for ongoing community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting a detailed report of resolved bugs and key fixes, along with the cleaned and updated issue board.
(IV) Deliver Voting-Transparency Feature & Subgraph Integration
Goal: Provide clear, real-time visibility into on-chain governance participation.
Requirements:
- Finalize and deploy the voting-transparency feature, incorporating requested UI refinements and migrating data fetching to the voting-tally subgraph for improved performance, using feedback from the Foundation and Advisory Boards.
Outcome: A fully deployed voting-transparency feature integrated with the voting-tally subgraph and refined UI, offering accurate, real-time governance data.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the live voting-transparency feature.
(V) Establish Maintainability & Roadmap
Goal: Ensure the Explorer remains easy to maintain with a clear 6-month plan.
Requirements:
- Publish a 6-month feature/bug roadmap aligned with the Foundation’s Data Gap Analysis and community feedback.
- Provide contributor docs, maintenance practices, and an issue-tracking process (including a clean, well-labeled issue board).
Outcome: A documented maintenance framework and forward roadmap enabling smooth ongoing development and community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting the final roadmap and contributor maintenance guide.
(VI) Provide Ongoing Support & Post-Delivery Responsibility
Goal: Ensure professional post-launch support and continuity of maintenance, whether the same team continues or future maintainers take over.
Requirements:
- During the project, acknowledge critical bugs within 24–48 hours and resolve or mitigate them within a few business days (or faster per the proposer’s SLA).
- After delivery, provide at least a 60-day support window for critical fixes, security incidents, and knowledge transfer, meeting the proposer’s SLA.
Outcome: Stable post-launch operations with timely critical-issue resolution and clear processes for continued maintenance, regardless of who maintains the Explorer.
Payment: The team must present a support-readiness plan with defined SLA commitments, to be agreed with the RFP owner. Ninety percent of each milestone payment is released after acceptance of that milestone’s demo. The remaining ten percent of the total contract is held until the 60-day support period concludes and SLA commitments and resolution targets are met.
Out of Scope
To avoid confusion, the following items are not part of this RFP:
- A full UI/UX redesign or new visual styling of the Explorer.
- Major new product features beyond the initial voting-transparency integration.
- Broader data-gap mapping (handled by separate workstreams).
- Protocol/client changes or on-chain improvements to surface new data (managed through separate RFPs within the same workstream).
5 Capabilities required
Skills
- Strong front-end engineering in modern JavaScript/TypeScript (React/Next.js), including implementing and refining accessible UI components within an existing component library or design system.
- Proven experience with codebase modernization and maintainability—refactoring, setting up CI/CD pipelines, adding automated unit and integration tests, and enforcing TypeScript and ESLint standards.
- Ability to update and manage complex dependency stacks, including Node.js and modern package managers, while resolving breaking changes and configuring automated update tooling (e.g., Dependabot or Renovate).
- Proficiency in performance optimization and efficient data-fetching techniques, particularly with GraphQL/subgraph and RPC endpoints.
- Experience reviewing, triaging, and merging open-source pull requests and managing a clean, well-labeled issue backlog.
- Familiarity with monitoring and incident-response tools (e.g., Sentry, Bugsnag) to ensure production reliability.
Knowledge
- Understanding of the Ethereum/Web3 stack, including wallet flows, transactions, RPC providers, and common front-end pitfalls.
- Awareness of accessibility (a11y) best practices and secure front-end patterns such as dependency risk management and safe secret handling.
- Experience with open-source project governance, including contributor guidelines, code review workflows, semantic versioning, and changelogs.
- Familiarity with The Graph/subgraph architecture and GraphQL schemas (nice to have).
- Familiarity with the Livepeer protocol and current Explorer repository (nice to have).
Attitude
- Community-oriented and collaborative, engaging proactively with contributors, Advisory Boards, and Foundation stakeholders.
- Accountable and responsive, acknowledging critical bugs within 24–48 hours and working toward mitigation or resolution within a few business days.
- Documentation-first mindset, maintaining clear READMEs, runbooks, and migration notes to enable future contributors.
- Quality-driven and pragmatic, balancing rigorous testing, CI, and security with on-time delivery.
- Long-term stewardship, treating the Explorer as trusted infrastructure and designing for multi-year maintainability.
- Supportive and open, encouraging new contributors and fostering an inclusive contributor community.
- Mission-aligned, motivated to strengthen the Explorer as a cornerstone of the Livepeer ecosystem.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience – examples of large front-end refactors, dependency upgrades, CI/CD setup, performance optimization, or open-source project maintenance.
- Milestone Breakdown – a plan aligned with Section 2 deliverables, with proposer-set milestone dates and demo day schedules, each including clear outputs and payment tied to demo acceptance.
- Support & Maintenance Plan – proposed SLA commitments (e.g., response and resolution times), 60-day post-delivery support approach, and handover/knowledge-transfer strategy.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template.
7. RFP Timeline
Proposal Deadline: Wednesday 24th September 2025
Decision Announced: Friday 26th September 2025
Project Start: Wednesday 1 October 2025
Project Completion: Sunday 1 Feb 2026
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
@rickstaaon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rich O’Grady
1. Objective
Restructure, refresh, and modernize Livepeer’s documentation so that it is stakeholder-focused, AI-first, and future-proofed. It should cater to the core personas of the Livepeer project: developers, delegators, gateway operators and orchestrators.
2. Problem Statement
Current Livepeer docs suffer from:
- Complicated onboarding: User journeys (node operators, app builders, delegators, gateway providers) are hidden behind toggles instead of clear entry points.
- Outdated or inconsistent content: Deprecated APIs, stale references, incomplete AI coverage, and fragmented changelogs.
- Brand & duplication: Studio-specific guidance is mixed into core docs; AI SDKs and APIs are duplicated across gateways.
- Weak site integration: Poor linkage between website, explorer, governance portal, and docs. Too many Studio dashboard references.
3. Desired Outcome
Success is a single-source-of-truth documentation system that:
- Leads with clear stakeholder-focused onboarding and goal-oriented entry points.
- Cleanly separates AI Jobs vs Transcoding Jobs while still surfacing cross-cutting resources (SDKs, APIs, CLI, on-chain/network).
- Fully deprecates Studio content with redirects and zero broken links.
- Provides AI-first documentation: semantically structured, LLM-readable, with embedded natural language search/assistant.
- Consolidates changelogs and introduces versioning / deprecation tracking.
- Establishes a style guide, contribution model, and ownership playbook for consistency.
- Integrates seamlessly with the broader Livepeer ecosystem (website, explorer, governance, dashboards).
4. Deliverables
(i) Present New Documentation Strategy
Goal: Create a new outline for Livepeer documentation, including full map of current documentation, a clear information architecture and timeline for writing new documents.
Requirements:
- Identify core stakeholder groups (Livepeer Foundation, Livepeer Inc, AI SPE, Cloud SPE, Streamplace, Frameworks and more)
- Conduct of all docs pages with status recommendations across the 4 categories (Developers, Delegators, Orchestrators, Gateway Operators)
- Developers: clean up deprecated sections and plan integrations with new gateway products (Streamplace, Frameworks, Daydream and more)
- Orchestrators: simplify documentation to easy onboarding with plan for support in Discord.
- Delegators: integrate new video content to make it easy to delegate.
- Gateways: streamline documentation and workflows with support from the Foundation.
- Create plan for an updated sidebar, taxonomy, and breadcrumb structure.
- Consolidation of multiple changelogs into a single canonical feed.
- Onboard stakeholders to project management process
Outcome: A forum post detailing the new documentation to the community with a 1-week window RFC.
Demo Due Date: Friday 17th October
(ii) Re-Write Documentation
Goal: Systematically edit and rewrite new content to meet stakeholder needs with consistent accuracy and depth.
Requirements:
- Work with core stakeholders to rewrite documentation
- Make the documentation easily consumable by AI systems and empower users with an embedded assistant ( semantic headings, structured metadata, and machine-readable references (OpenAPI specs, JSON examples).
- Integrate embedded natural-language search or AI assistant (leveraging Mintlify features) and ensure clear explanations and concise summaries for LLM parsing.
- Rewrite quickstarts for both AI Jobs and Transcoding Jobs.
- Migration guides for Studio users.
- Integrate goal-based tutorials for each stakeholder type where possible.
- Work with existing groups to incorporate starter repos, examples, and copy-paste snippets and full API/SDK/CLI references with updated coverage (including realtime + BYOC APIs).
- Conduct review with core stakeholders with a clear RFC.
Outcome: First written draft of clear, accurate, and goal-oriented documentation that accelerates adoption and reduces support overhead.
Demo Due Date: Friday 7th November
(iii) V1 Documentation Live
Goal: Deliver a technically sound and reliable documentation site.
Requirements:
- Implement redesigned IA and content in the current docs stack (Mintlify/Docusaurus).
- Set up redirects, SEO and AEO optimization, and accessibility compliance (WCAG).
- Integrate multilingual readiness and analytics tracking.
- Integrate the documentation into the website.
Outcome: A responsive and performant documentation site with zero broken links, measurable engagement, and improved accessibility.
Demo Due Date: Friday 14th November
(iv) Public Workflow For Maintenance & Community Contributions
Goal: Create a consistent tone and a scalable contribution process.
Requirements:
- Work with the Livepeer Foundation’s Technical Director to establish a unified voice and style guide (tone, terminology, formatting, accessibility).
- Create contribution guidelines and PR workflow for community involvement.
- Define and handover ownership and review process for maintaining quality.
- Integrate multilingual readiness and analytics tracking.
- Provide a clear ticketing system for reporting problems and patching fixes.
Outcome: A sustainable documentation process with consistent voice, tone, and governance.
Demo Due Date: Friday 5th December
5. Capabilities Required
Skills
- Developer documentation strategy, IA design, technical writing.
- Static site tooling, redirect management, docs CI pipelines.
- SEO, accessibility, multilingual documentation workflows.
Knowledge
- 1+ years experience with Livepeer ecosystem
- Streaming/transcoding basics (FFmpeg, GPU workloads).
- AI inference workflows basics, particularly working with APIs.
- Open-source contribution models and GitHub-based workflows.
- Comparative familiarity with best-in-class docs (e.g., Chainlink, Base, Solana).
Attitude
- Community-first, collaborative, pragmatic.
- Strong eye for clarity, consistency, and long-term maintainability.
- Willingness to challenge outdated patterns and propose future-proof solutions.
- Enjoyment in distilling complex technical concepts into minimal, user-focused documentation.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience - examples of docs restructures, especially for developer platforms.
- Milestone Breakdown - giving a week-by-week breakdown of the project in line with the due dates and requirements above.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template
7. RFP Timeline
- Proposal Deadline: Wednesday 24th September 2025
- Decision Announced: Friday 26th September 2025
- Project Start: Monday 29th September 2025
- Project Completion: Friday 5th December 2025
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
Rich | Livepeer Foundationon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
- Payments: when thinking through your total budget, be mindful that payments will be paid out on milestone completion.
Livepeer FrameWorks SPE: Pilot phase
Author(s): The MistServer Team
Contact: developers@mistserver.org
Abstract
The FrameWorks SPE proposes to strengthen the Livepeer protocol by bridging the gap between transcoding infrastructure and real-world media applications.
This includes:
- Providing dedicated engineering resources to ensure stability, feature enhancements, automated testing and a clear & complete documentation.
- Providing onboarding and infrastructure support for teams building on Livepeer.
- Operating an independent, Livepeer-powered E2E media pipeline that validates new transcoding features in real-world deployments.
By focusing on low operating costs, easy integration and strategic partnerships, FrameWorks aims to provide a viable, scalable alternative to traditional full-service video providers.
This first phase serves as a pilot to build trust and credibility within the Livepeer ecosystem while keeping the initial funding request modest.
Mission
The media industry is highly complex. Building reliable, scalable streaming applications requires complex deployments and industry expertise.
Livepeer Inc has laid a robust foundation for decentralized video infrastructure. However, there remains a gap between what the network offers versus what video applications need.
This proposal builds on their achievements by addressing key areas where we can contribute with our expertise.
The MistServer team proposes a Special Purpose Entity to take ownership of maintaining and enhancing the transcoding pipeline, ensuring that node operators have the support, documentation, and features they need.
FrameWorks will also bridge the DevOps gap by offering an E2E media pipeline that businesses can directly integrate or self-host, rather than relying on Livepeer Studio for infrastructure, support or custom features.
Instead of replicating Studios’ high-complexity, full-service model, FrameWorks aims to build a scalable, low-overhead alternative aimed at easy integration with external business logic.
Result: A more stable, performant, and accessible transcoding pipeline for node operators and Livepeer-powered media applications.
Terminology
Some of these terms are not present in this pre-proposal, but can be helpful when browsing through the feature board.
- E2E media pipeline: Provides the core infrastructure for a full media pipeline. Including but not limited to: ingesting, processing, storing, and delivering video.
- Transcoding: The process of decoding a video stream, transforming it (resolution, bitrate, etc.), and encoding it for delivery or storage.
- Segmented Workflow: A process of breaking video streams into discrete segments for transcoding. A full segment is required before it can be transcoded by the network.
- Streaming Workflow: A continuous processing method where the video stream is sent in small chunks and immediately transcoded.
- Intel QSV: Intel’s “Quick Sync Video” hardware for video encoding/decoding, allowing efficient transcoding on Intel CPUs and GPUs.
- AV1: A royalty-free, high-efficiency video coding format which is gaining in popularity.
- Latency: In the context of Livepeer we consider the delay between the stream ingest at a Gateway node and receiving the transcoded frames back.
- Netint: Specialized hardware device for video transcoding.
- LPMS: Livepeer Media Server, the core transcoding library used within the Livepeer stack.
- FTE: Full Time Equivalent, indicates the amount of hours dedicated to a project. 1 FTE equals one fulltime employee, but could also be two people each contributing 0.5 FTEs worth of effort.
Structure
The MistServer Team leads the SPE, with Marco (stronk-tech.eth) acting as the primary decision-maker and point of contact.
The SPE is open to expand the core SPE team with additional applications from outside the MistServer team.
Structure
- Lead: Marco, long-time Orchestrator and MistServer maintainer.
- Core Team: MistServer maintainers with expertise in transcoding and live streaming.
- Open-Source Contributors: Developers in the Livepeer community who take on bounties.
- Advisors:
- Rick (
transcode.eth): AI SPE Lead. - Brad (
ad-astra-video.eth): AI SPE Engineer, also familiar with the transcoding codebase. - Josh: Livepeer Inc engineer with extensive experience with relevant code repositories (
LPMSandgo-livepeer). - Rich: Livepeer Ecosystem Growth Team
- Rick (
Responsibilities
- Core Team: Scoping out tasks, assigning bounties, conducting code reviews, and core development of the transcoding pipeline.
- DDVTech: The business entity of the MistServer team, responsible for hiring, team coordination, and administrative processes.
- Advisors: Provide strategic & operational guidance and brainstorming about potential solutions.
About the MistServer Team
The MistServer team is composed of experts in live streaming and media server technology. Our journey began in 2009 when we set out to build a better media server following the failure of a media-related project due to unreliable software. Since then, MistServer has become our core business, and we’ve dedicated our professional lives to advancing live streaming technology.
We bring over half a century of combined hands-on experience in live streaming and media server development, including experience managing streaming infrastructure (like Picarto).
This hands-on expertise positions us uniquely to lead the FrameWorks SPE and contribute meaningfully to the ecosystem.
Scope
The core responsibilities of this SPE include:
- Making the Livepeer transcoding pipeline more robust and competitive.
Adding codecs, adding device support, reducing latency and enhancing transcoding jobs with more parameters.
- Supporting node operators.
Identifying & addressing common pain points, like replacing the static session limit with smarter GPU load balancing and improving Gateway Documentation.
- Ongoing core maintenance
This is a task which also sees ownership from existing core contributors. The Transcoding SPE intends to jump in (wherever required) to assist with tasks like keeping the build pipelines up-to-date, rebasing the LPMS FFMPEG patches and fixing bugs or crashes.
- Research & integrations
The media industry landscape changes over time (slowly evolving). WebRTC and SRT are now common methods to transport media, but are unsupported by Gateway nodes.
These kind of features could also be supported by siderunning applications, like how WebRTC has limited support through go-livepeer’s MediaMTX integration.
This topic covers exploring enhancements to the Gateway with additional protocols or improving integrations with external applications.
- Expanding testing & QA practices
Implementing automated testing to ensure network stability and prevent regressions.
This includes writing feature-specific tests for each change we make, while also expanding coverage with additional regression or benchmark tests.
- Bridging the DevOps gap for media applications
Providing support to entities looking to build on the network as well as setting up an E2E media pipeline, making it easier for applications to integrate Livepeer-powered streaming without reliance on Livepeer Studio.
Any development work will of course be published open-source and under the Unlicense.
Phase 1: Pilot
Goals
- Gather pain points from Gateway and Orchestrator operators.
- Prioritize roadmap items to address critical gaps in the transcoding pipeline.
- Set up a transcoding bounty program.
- Scope out the E2E media pipeline.
- Cross off the first few items from the roadmap.
Timeline
March 2025:
- Set up operations and governance structure.
- Identify and re-prioritize key tasks for this quarter.
- Launch a bounty board for community contributions.
- Initial discussions on FrameWorks infrastructure.
April – July 2025:
- Engineering work on Q2 key tasks, explained in the roadmap below.
- Next phase planning: Identifying FTE needs and define the FrameWorks infrastructure roadmap.
Roadmap
We have published a feature board where anyone can request items, vote on priorities, and comment on issues.
The roadmap will be prioritized based on continuous conversations with node operators, as well as the needs of inbound opportunities for our E2E media pipeline.
Initial Q2 goals are:
- Improve documentation for Gateway operators.
- Pull Netint integration over the finish line.
- Pull AV1 codec support over the finish line.
- Add Intel QSV support.
- Smarter session limits & load balancing for transcoders.
This roadmap indicates our short-term goals. Not all of these features might see completion in Q2.
Future Phases
If the pilot phase succeeds future requests may include:
- Expanding the core SPE team to increase engineering capacity.
- Addressing long-term goals and more complex tasks, including transitioning to a streaming workflow or expanding the Transcoding job type with more parameters (for example: allowing non-realtime, high quality transcodes for VoD processing).
- Further development & deployment of the FrameWorks E2E media pipeline.
Budget Breakdown
Funding Period: March – June 2025
Total Ask: 15,000 LPT
Breakdown:
| Item | Amount | Explanation |
|---|---|---|
| March: SPE Kickoff & onboarding | Free | Structuring the SPE, setting up communication channels, onboarding contributors, gathering feedback from Gateway & Orchestrator operators, initial design work on the E2E media pipeline. |
| April – June: Core Development | 12000 LPT | Managing bounties, active community participation, feature development, testing, and infrastructure work. |
| Community Incentives | 3000 LPT | Open-source contributor incentives to drive external contributions. |
Rate Justification
For 4,000 LPT per month, the MistServer team operates the SPE while providing 1 FTE of dedicated engineering work. At $5 per LPT, this equates to $20,000 a month (~$115/hr), which is a reduced bulk rate for long-term commitments. This ensures that developers assigned to the SPE remain fully committed, without being pulled into other commercial projects.
If future proposals require additional engineers, we can use the DDVTech entity to hire freelancers or full-timers. This approach allows us to:
- Offer security & guarantees to SPE hires through an established legal entity, of course with access to our office and team’s expertise for onboarding.
- Provide additional engineering capacity at a lower cost, ensuring efficient use of treasury funds.
We are open to adjusting the LPT request or FTE commitment based on community feedback, but believe the amounts are fair given the technical expertise required and in comparison with common rates in the media industry.
Success Metrics:
Defining success metrics for a broad core-development SPE like this is difficult. We encourage feedback on what we can do to measure impact and ensure accountability.
-
Core Contributions:
- Completed bounties.
- PRs submitted and merged into the Livepeer codebase.
- Increase in test coverage.
-
Feedback & Adoption:
- Positive feedback from Gateway & Orchestrator operators.
- Growth in the number of Gateway operators on the network, onboarded through the FrameWorks SPE.
- Transcoded minutes on the E2E media pipeline.
Transparency and Accountability
Engagement with protocol participants is an important part of this SPE. We will work closely with Gateway & Orchestrator operators to collect issues or requests to put on the feature board. We gather community input through multiple channels:
- Discord threads & forum discussions.
- a Canny task board to track development progress, request items or discuss tasks.
- Titan’s weekly water cooler sessions.
Leftover LPT will roll over into future proposals or return to the treasury if the SPE disbands for any reason.
Reporting:
- Quarterly progress reports will include:
- Amount of LPT spent, staked, or held.
- Progress on any of the success metrics.
", replyCount: 18, views: 842, likeCount: 52, datePosted: "Feb 22, 2025", lastActivity: "Mar 17, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Proposal - Protocol R&D Special Purpose Entity", href: "https://forum.livepeer.org/t/3160", author: "By Rick (@rickstaa)", content: "
Abstract
All network value depends on protocol security.
Protocol security requires dedicated capacity to detect issues early, resolve them quickly and deploy upgrades with confidence. The current model depends on limited, distributed resources that cannot consistently support these demands. The Protocol R&D Special Purpose Entity (SPE) resolves this by establishing a professional, continuously staffed function responsible for vulnerability triage, safe upgrade preparation, and shipping additional protocol features like a reliable testnet for rigorous validation and development.
This proposal funds the SPE for an initial six-month term. It brings together a contracted security and engineering partner, under the governance of Livepeer Foundation and Livepeer Inc. The SPE creates a single, accountable structure that protects the protocol, reduces operational risk and enables faster, safer delivery of protocol improvements as the network continues to scale.
Mision
The mission of the Protocol R&D SPE is to provide the most secure, resilient and continuously improving protocol foundations possible for Livepeer, at the best possible price-to-value ratio.
Rationale
The protocol supports significant on-chain value which continues to grow through the expansion of services to real-time video AI inference. Protecting this requires consistent access to security and engineering expertise. The current model, while effective at securing the protocol since inception, relies on Livepeer Inc and places a significant load on the security committee. This constrains core feature development and protocol progress. Having a dedicated security partner reduces the load on the security committee and frees them for other obligations, while increasing the speed at which we can improve network security.
Core to this SPE is the engagement of a Protocol Engineering & Security Partner (Sidestream) to provide a dedicated, multi-disciplinary team. They provide first‑response to Immunefi-identified vulnerabilities and implement audited on‑chain patches and upgrades. Immunefi has been a massive success in terms of the mission, keeping the protocol safe at modest cost—historically about $75–100k per year in bounty payouts—while helping protect tens of millions in protocol value. The Partner works in close coordination with the Security Committee, which retains review and execution authority for upgrades and emergency patches.
The steps reduce our reliance on more constrained support, and moves toward a stable, accountable model for protocol security. The SPE creates a durable, well defined structure for protocol stewardship as the network decentralizes. It gives the community a clear point of accountability for security and core maintenance, which reduces operational risk and supports the reliable functioning of the protocol over the long term.
Deliverables
The Protocol R&D SPE improves operational responsibilities, fast and continuous response, ships already‑built but not‑yet‑deployed features in the protocol R&D pipeline, and launches and maintains a public testnet and DevEx toolkit to speed up future development.
(1) Core Protocol Security Operations
Goal: Maintain continuous protocol security coverage and rapid incident response through the Immunefi bounty program and close coordination with the Security Committee.
Outputs: The SPE will manage the Immunefi process as first responder for vulnerability reports. The Partner will reproduce, validate, and propose patches within defined response windows, in coordination with the Foundation Technical Lead and the Security Committee for review and deployment. Quarterly readiness reviews will strengthen detection, response time, and coordination.
Success Indicators: Continuous Immunefi coverage with valid reports acknowledged within 24 hours and triaged within one week. Critical issues are resolved or escalated for deployment within agreed timelines. The SPE operates the response process independently while the Security Committee maintains oversight.
(2) Ship Backlog Features and Build the R&D Pipeline
Goal: Deliver the high-priority protocol upgrades from the existing backlog while building the foundation for a sustainable and iterative R&D process.
Outputs: The SPE will complete and deploy existing features nearing readiness for mainnet release—such as the Reward Call Delegate, Ticket Distinction, and stability patches. The specific upgrades shipped each release cycle will be selected through a lightweight triage process established by the SPE, supported by the Foundation protocol engineer as the role comes online.
Success Indicators: At least one backlog feature or patch deployed to mainnet per release cycle. Lightweight triage and delivery process is established and used to prioritize and ship work. The Foundation protocol engineer is hired and supporting development and coordination by the end of Q1 2026.
(3) Public Testnet and Developer Infrastructure
Goal: Deliver and maintain the testnet and tooling needed for reliable validation, audits, and developer experimentation, supporting both protocol and client development.
Outputs: The SPE will operate a continuously available public testnet with faucet access, CI integration, and simulation tooling. Clear developer documentation and workflows will make it easier to run local or private devnets and test upgrades or integrations before mainnet deployment.
Success Indicators: Public testnet operational with ≥99% uptime and integrated into CI and simulation workflows. Developer and client teams actively use the infrastructure for validation and testing.
Key Milestones
| Milestone | Target Completion | Description |
|---|---|---|
| Partner Onboarding Completed | Q4 2025 | Protocol Engineering & Security Partner contracted and operational, and security and triage procedures aligned with the Security Committee. |
| Continuous Immunefi Vulnerability Response | All of H1 2026 | Maintain full first-response capability for Immunefi reports: reproduce issues, propose fixes, coordinate Security Committee review, and ensure continuous coverage. |
| Public Testnet Live | Q1 2026 | Launch a stable, persistent public testnet with faucet, CI integration, and reproducible deployment tooling. |
| Triage Pipeline Established & First Upgrade Shipped | Q1 2026 | Lightweight triage process established and validated through at least one feature or protocol upgrade shipped to mainnet. |
| Triage Pipeline Updated & Additional Upgrade Shipped | Q2 2026 | Triage pipeline updated, with at least one additional upgrade triaged and deployed to mainnet. |
| Six-Month Review & Renewal Assessment | Q2 2026 | Performance and financial review concluded by the SPE Board,; results shared publicly and renewal proposal prepared. |
SPE Governance Structure
The Protocol R&D SPE is managed and governed by the Livepeer Foundation and Livepeer Security Committee. Through their collaboration, they enable the work of the Protocol Engineering & Security Partner.
The exact operations of security practices are not shared here.
SPE funds are held in a secure multisig SAFE with a threshold of known, trusted signers from the Foundation and the Security Committee, following standard security practices.
The SPE will operate transparently through quarterly public reporting, open development and open access to non-sensitive work.
Roles & Responsibilities
| Body / Role | Responsibilities | Scope | Funding Source |
|---|---|---|---|
| Security Committee | Review and execute upgrades and patches a final security checkpoint | Security oversight; upgrade authorization & execution. | Livepeer Inc. |
| Foundation | Coordinate roadmap and delivery, manage funds and payouts for Immunefi, audits and security partner milestones | Program and roadmap management, coordination and treasury/ops. | Foundation |
| Protocol Engineering & Security Partner | First responder for patches, implementator of new protocol features, audited upgrades, and patches, and build/maintenance of testnet and tooling components | On-chain development, security response, contract CI/tooling, on-chain testnet components. | SPE |
Budget
The Protocol R&D SPE seeks $360,000 equivalent amount. This ensures 24/7 responsiveness from the team in addition to their core security deveopment work.
The budget includes a line item for audits to ensure that significant protocol changes and new implementations receive appropriate security review before deployment. Other necessary costs for executing this SPE, such as the Foundation’s protocol engineer, infrastructure, and operations, are covered separately by the Foundation.
A core responsibility of the SPE is managing the Immunefi bounty program. The Livepeer Foundation will cover Immunefi payouts in the short term to avoid withdrawing capital from the treasury until necessary. This approach allows treasury capital to continue supporting other strategic initiatives across the ecosystem. As part of the Foundation, I can share that we are glad to support this active capital management to advance Livepeer’s collective goals.
Projected Spending:
| Category | LPT | USD | Description |
|---|---|---|---|
| Protocol Engineering & Security Partner (team) | N | $300,000 | Six-month engagement focused on security response, prioritized backlog features, and on-chain testnet ops. |
| Audits & External Reviews | N | $60,000 | Third-party security reviews (reserve-based) |
| Total Initial Request | N | $360,000 |
Key Terms
| Term | Definition |
|---|---|
| Protocol R&D SPE | A Special Purpose Entity funded by the Livepeer Treasury to manage protocol research, development, and security operations. |
| Protocol Engineering & Security Partner | The contracted team responsible for hands-on protocol development, audits, and vulnerability response under the SPE framework. |
| Security Committee | Oversight body responsible for reviewing protocol upgrades, validating critical patches, and guiding decentralization of security responsibilities. |
| Immunefi Program | Livepeer’s bug-bounty initiative that incentivizes whitehat researchers to identify and responsibly disclose vulnerabilities in the protocol. Managed under the SPE to ensure continuous coverage and rapid triage. |
| Triage Pipeline | The structured process for evaluating, prioritizing, and implementing protocol work, including community proposals (LIPs) and vulnerability reports, through coordinated specification, review, and deployment stages. |
| Public Testnet | A continuously maintained network environment mirroring mainnet, used for protocol validation, client testing, and developer experimentation before production deployments. |
| DevEx Tooling | Developer-experience infrastructure, including CI pipelines, simulations, and documentation, enabling contributors to test and validate protocol upgrades efficiently and safely. |
| SPE Board | The governance body composed of representatives from the Foundation, Security Committee, and Livepeer Inc., responsible for approvals, budget oversight, and performance reviews. |
| Audits | Independent security reviews performed by external experts to assess the safety, correctness, and performance of protocol changes before deployment. |
| Multisig SAFE | A secure multi-signature wallet used for custody and management of SPE funds, requiring approval from designated Foundation and Security Committee signers. |
Hi everyone! I’m running a Livepeer transcoder based in Slovenia since 2022, focused on reliability, sustainability, and geographical diversity in the network. I truly believe Livepeer has huge room to grow, and I’m in it for the long run.
Hardware setup:
- 2× NVIDIA GTX 1070 GPUs for rock-solid transcoding
- 1× NVIDIA RTX 3090 dedicated to the AI network
- Solar-powered when available
Current fee structure:
- Reward cut: 8%
- Fee cut: 49%
Cuts may lower as more LPT is staked — early delegators are rewarded!
If you’re looking to support a trustworthy, green, and diverse node, consider staking with me:
Delegate here
Got questions or just want to connect? Join me on Discord: @gasper5466
", replyCount: 12, views: 482, likeCount: 6, datePosted: "May 30, 2025", lastActivity: "Mar 4, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "Embody SPE: Pre-proposal Intelligent Public Pipelines", href: "https://forum.livepeer.org/t/3220", author: "By DeFine (@DeFine)", content: "Pre-proposal v5: WEAVE
Authors: DeFine (Strategy & Engineering), Dane (Virtual Worlds & Avatars)Date: March 15, 2026
1. Abstract
The Embody SPE is an entity dedicated to bringing embodied avatar workloads into the Livepeer ecosystem. Since our inception, we have continuously evolved our technology to meet the needs of the network. Our core drive is to deliver sustained fee growth for Livepeer orchestrators.
Along our journey, we have developed solutions and frameworks that address Livepeer’s core bottleneck: the workload lifecycle. Embody seeks funding to develop and prove these solutions, and to expand them into an open-source public-good toolset fit for every existing and upcoming workload deployed on Livepeer.
2. The Problem
To understand the problem, one must recognize three fundamental actors within the Livepeer ecosystem:
-
Orchestrators, who provide compute for workloads.
-
Workload Facilitators, who engineer and maintain the workloads that orchestrators run.
-
Consumers, who utilize these workloads and generate demand.
The Livepeer network provides adequate tokenomic incentives for orchestrators. However, workload facilitator and consumer incentives are currently funded in a non-standardized way by the Livepeer treasury, with limited success so far. In supply and demand terms, compute suppliers vastly outnumber both demand seekers and demand creators.
Workload facilitators generally fall into two subcategories: startups seeking capital to pay for compute and build a consumer base, and established organizations that already possess compute capital and consumers. Livepeer is attractive to both because orchestrators are incentivized through token inflation to offer compute below standard market costs. Theoretically, workload facilitators should be able to offer better prices to their consumers by selecting Livepeer orchestrators.
Despite this advantage, creating workloads within the Livepeer ecosystem remains exceedingly difficult due to the following barriers:
The Technical and Conceptual Barrier Workload facilitators must deeply understand the Livepeer ecosystem technically and conceptually. Furthermore, manually executing every step of a workload’s lifecycle and managing the handoff to the next stage requires an immense amount of time and effort. This creates an exceptionally high barrier to entry, practically excluding non-technical participants from the creation process.
The Economic and Incentive Barrier Economic incentives for workload creation are virtually non-existent by default. Startups rely on the treasury to incentivize their work. Even if a team possesses the technical capability to deliver workloads, they must invest significant time navigating the community and preparing proposals, hoping for treasury approval. For established organizations, there is no incentive to risk service downtime and consumer dissatisfaction by migrating from centralized providers to Livepeer. To date, there are zero documented successful cases of such organizations making the swap.
The Distribution and Interface Barrier Once a workload is live, startups without established consumer bases face the monumental task of building consumer interfaces and executing outreach. Such organizations typically have low headcounts. The added overhead of maintaining Livepeer-specific infrastructure, building interfaces, and distributing workloads is enough to make Livepeer unattractive, especially given the generous inference subsidies offered by centralized providers.
This culmination of friction leads to a critical question: How can we radically reduce the time it takes to convert intent into workload creation and distribution?
3. The Solution
To resolve this bottleneck, we propose WEAVE; an open-source, semi-autonomous agentic orchestration tool with a human-in-the-loop design. WEAVE is designed to turn stakeholder intent into researched, engineered, tested, maintained, and distributed workloads, compressing the lifecycle from months to mere hours.
WEAVE will be accessible to everyone, resolving lifecycle bottlenecks from initial research to consumer distribution. It allows workload facilitators to create new GPU-powered workloads and rapidly deploy them to orchestrators and consumers.
The human operator’s role is simplified: they prompt the initial intent, review the output at the end of each lifecycle stage, and authorize the agent to proceed to the next step. Embody will develop and provide the first WEAVE workloads, managing consumer and orchestrator incentives to power our own and future WEAVE users.
How WEAVE Solves Each Stage
WEAVE directly addresses each stage of the workload lifecycle:
Research Lifecycle agents help identify promising workloads, synthesize demand, evaluate tooling and feasibility signals, and prepare proposals for Livepeer stakeholder review.
Engineering and Maintenance Lifecycle agents turn approved intent into implemented workloads, updates, fixes, and ongoing maintenance work inside bounded environments.
QA Lifecycle agents validate workloads, catch regressions, and prepare them for release through a repeatable testing path.
Consumer Interface The public entry point is a published SKILL.md—a markdown contract that instructs consumers on how to start, control, and end the workload through a mediated public control surface.
Orchestrator Release Lifecycle agents package workloads, document release requirements, and move them through a clear operator onboarding and rollout path.
Consumer Distribution Lifecycle agents support the distribution work needed to reach consumers, drive adoption, and keep the workload legible as a public interface rather than an obscure private implementation.
From Intent to Live Workload
WEAVE provides a clear path from initial intent to live network execution:
-
Intent Submission: A user submits a workload intent. This can propose a new workload, request an improvement, or point the pipeline toward a concrete opportunity (e.g., real-time camera tracking).
-
Lifecycle Execution: Agents pick up the intent and move it through research, engineering, QA, release preparation, and distribution.
-
Stage Review and Authorization: At the end of each stage, agents publish artifacts and request human review. Agents carry the workflow forward, but human authorization is strictly required to complete a stage.
-
Runtime Release and Distribution: When release-ready, WEAVE distributes the workload to the orchestrator registry. Operators can adopt it through a bounded action. The system simultaneously publishes the consumer-facing
SKILL.mdand begins distribution outreach.
For orchestrators, this creates a faster path to new fee-generating workloads and lowers integration friction.
Economic Incentives
WEAVE resolves the time constraints and technical barriers, but this only solves part of the problem. The other half is the absence of economic incentives for workload facilitators and consumers. Similarly, orchestrators typically do not run workloads for free out of goodwill; there must be clear incentives for them to support WEAVE workloads. To address this, we propose three perpetual financial packets:
1. Workload Facilitator Hackathon Packet A perpetual hackathon powered by an LPT economic packet, where a portion of the accrued inflation value is used to incentivize the weekly creation of new workloads. The remaining value is fed back into the principal, allowing it to compound continuously so that token rewards grow over time. The shape of the hackathon and its economic parameters will be subject to ongoing refinement by the multisig participants. Participants will engage through a SKILL.md contract, and funding will be distributed retroactively upon the completion of intended targets. This creates an asymmetric upside: participants are incentivized with an initial allocation, and upon delivering a high-demand workload, they receive retroactive funding along with the ability to deploy applications on top of the workload.
2. Consumer Incentive PacketThis perpetual financial packet operates similarly to the facilitator packet, utilizing weekly accrued inflation to incentivize consumers of WEAVE workloads to take specific actions. For example, SKILL.md consumer agents holding a blockchain wallet could be eligible for rewards if they deliver a working open-source companion application that reaches five concurrent daily users. Like the facilitator packet, this is designed with an asymmetric risk/reward model: the consumer uses the workload without charge and receives a small initial incentive (subject to terms), while the upside includes retroactive rewards and the ability to profit from an application built on WEAVE’s incentive layer.
3. Orchestrator Incentive PacketAn economic packet dedicated to providing weekly rewards for orchestrators who run WEAVE workloads on their hardware systems, ensuring consistent compute availability and sustained network participation.
4. Where We Are Today
WEAVE is being proposed on top of assets the Embody team already operates: a mature Embody workload, an orchestrator rollout lane, and a working consumer entry point.
-
embody-skill: The published skill-contract path for the workload interface, providing a working consumer-distribution surface.
-
livepeer-ops: The control-plane layer for sessions, policy, and orchestrator allocation.
-
Unreal_Vtuber: The runtime environment for the embodied avatar workload.
-
Registered Orchestrators: 13+ orchestrators have registered to the pipeline and received workloads; seven are currently active, and prior participants can reenter.
-
Rollout Capability: The active lane can already receive auto-updates through the Unreal_Vtuber path.
Together, these assets provide the execution base for the proposal: a mature workload, an existing operator lane, and functioning distribution tooling on which WEAVE can be built, tested, and released.
5. What We Are Delivering (4-Month Scope)
The roadmap advances in three stages: first, deploy Embody as the inaugural workload on WEAVE; second, extend WEAVE to host daydream/scope; third, generalize WEAVE beyond both to support any realtime application, establishing it as a true open-source public good for the Livepeer ecosystem.
The perpetual financial packets are foundational to this progression. All three launch alongside the Embody workload in Month 1, ensuring that workload facilitator and consumer incentives are active from the start and that orchestrator expenses are covered from day one.
Month 1 — Embody Workload, Lifecycle Automation & Incentives Launch
DeFine
Deliverables
-
Establish the first bounded lifecycle-agent runtime.
-
Automate research, engineering, maintenance, and QA flows on the Embody (non game-dependent) proving lane.
-
Release Embody as the first working WEAVE workload, accessible via
SKILL.mdand processing sessions on at least one active orchestrator. -
Deploy all three perpetual incentive packets (Workload Facilitator Hackathon, Consumer, and Orchestrator).
Success Criteria
-
Lifecycle agent runtime operational and processing intents end-to-end on the Embody lane.
-
Embody workload live and accessible via
SKILL.md, processing sessions on at least one active orchestrator. -
All three incentive packets deployed and accepting participants.
-
At least 3 orchestrators enrolled in the WEAVE lane.
Dane
Deliverables
- Automate the Embody/Unreal Engine workload engineering pipeline through DeFine’s agent runtime: plugin automation, adding and removing code and features, and game packaging — covering ≥80% of the engineering workflow end-to-end.
Success Criteria
- Agent runtime can execute Unreal Engine engineering tasks end-to-end (plugin add/remove, code changes, game packaging) with ≥80% workflow coverage.
Month 2 — Daydream/Scope Workload Path
DeFine
Deliverables
-
Adapt WEAVE end to end to accept daydream/scope workloads.
-
Bring the orchestrator rollout path online for daydream/scope workloads.
-
Support the first new community workload generated from the Month 1 Hackathon.
Success Criteria
-
WEAVE adapted end to end for daydream/scope workloads.
-
Orchestrator rollout path operational for daydream/scope workloads.
-
First community hackathon workload supported end-to-end.
Dane
Deliverables
- Deliver a functional prototype of the alternative (non-Unreal Engine) embodied avatar workload demonstrating core session flow.
Success Criteria
- Alternative avatar workload prototype operational and demonstrating end-to-end session handling.
Month 3 — Generalized Path & Alternative Avatar Pipeline
DeFine
Deliverables
-
Expand WEAVE from scope and daydream to support custom-lane workloads built on any framework or technology stack, including those outside the Embody and daydream/scope ecosystem.
-
Package Dane’s alternative embodied avatar workload into WEAVE.
-
Open WEAVE to public orchestrator onboarding.
-
Publish the supported workflow for releasing and maintaining additional workloads through WEAVE.
Success Criteria
-
WEAVE custom lane operational and accepting at least one workload built on a framework outside Embody and daydream/scope.
-
Dane’s alternative workload packaged and accessible through WEAVE.
-
At least one external orchestrator onboarded through the public path.
-
Supported workflow for releasing additional workloads documented and tested.
Dane
Deliverables
-
Deliver the alternative (non-Unreal Engine) avatar pipeline, fully operational and documented, ready for DeFine to integrate and automate.
-
Deploy the ability to add and edit new avatars and game environments in both the Unreal Engine and the alternative avatar pipeline.
Success Criteria
-
Alternative avatar pipeline operational, documented, and handed off to DeFine for WEAVE integration.
-
Avatar and environment creation and editing operational in both pipelines, with at least one new avatar or environment demonstrably added through the system on each pipeline.
Month 4 — Governance and Handover
DeFine
Deliverables
-
Facilitate a public governance discussion with multisig participants and the community on how the incentive packets and lifecycle-agent runtime should be managed post-grant.
-
Strategize and document the operating model for the three perpetual incentive packets going forward — how they will run, who will manage them, and what community input shapes their parameters. This decision passes through the community.
-
Document the agreed governance path: multisig participants may elect to transition to a decentralized on-chain layer, continue multisig management until a decentralized solution is ready, or confirm another path agreed upon by the group.
-
Resolve all pending bugs submitted against WEAVE during the grant period.
-
Publish handover documentation and a residual-risk list regardless of the governance decision.
Success Criteria
-
Governance discussion held and outcome documented publicly.
-
Incentive operating model documented and ratified by community input.
-
One of the following governance paths confirmed and recorded: (a) decentralized governance contracts deployed and management transitioned, or (b) a clear continuation plan agreed upon by multisig participants with an explicit path toward eventual decentralization.
-
All flagged WEAVE bugs resolved or, where blocked by external dependency, documented with root cause and mitigation plan.
-
Handover documentation and residual-risk list published.
Dane
Deliverables
- Resolve all bugs flagged across both pipelines during the grant period (Months 1–3).
Success Criteria
- All flagged bugs resolved or, where resolution is blocked by external dependency, documented with root cause and mitigation plan.
Each monthly tranche is released independently via 3/5 multisig upon confirmation of that month’s criteria — DeFine: $4,000 per month, Dane: $6,000 per month. Month 4 payments for both tracks are advanced upon Month 3 confirmation, with final deliverables confirming grant completion. A delay or gap in one track does not block the other.
6. Budget & Financial Governance
The total amount requested from the on-chain treasury is $100,000 USD, equal to 43,478 LPT at an LPT reference price of $2.30 on March 15, 2026.
Budget Breakdown
-
Team Compensation: 17,391 LPT / $40,000 total.
-
DeFine: $16,000 total ($4,000/month). Strategy, control plane, WEAVE engineering, and governance/runtime delivery.
-
Dane: $24,000 total ($6,000/month). Embodied avatar workload engineering across Unreal Engine and non-Unreal runtime paths.
-
Release mechanism: Each monthly tranche is held in the multisig and released only after the month’s work is complete and its success criteria have been met. Release requires 3/5 multisig confirmation. Each track is independently verified and independently released — a delay in one does not block the other.
-
-
Operational Costs: 4,348 LPT / $10,000. Infrastructure, runtime, measurement, and support costs for the proving workload during the grant window.
- Release mechanism: Funds are released against submitted receipts as expenses are incurred. No advance disbursement; each release requires documentation of the corresponding expense.
-
Network Incentives: 13,043 LPT / $30,000. Principal for the Orchestrator Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participating orchestrators according to the published incentive rules.
-
Workload Facilitator Incentives: 4,348 LPT / $10,000. Principal for the Workload Facilitator Hackathon Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participants who meet the published hackathon criteria.
-
Consumer Hackathon: 4,348 LPT / $10,000. Principal for the Consumer Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to consumers who meet the published incentive terms.
Total: 43,478 LPT / $100,000.
The grant will be managed on Arbitrum through a proposal-facing multisig, incorporating comprehensive receipt spend tracking and structured spending categories.
Multisig Composition
-
Orchestrator Tiebreaker: One signer - Pon.
-
Embody Team: Two signers.
-
Foundation: Two signers, including Rick, the Foundation’s head engineer.
Treasury actions will proceed through a 3/5 signature scheme path. If funds need to be returned, the remaining balance can be converted to LPT and sent back to the Livepeer treasury through the governance process described in the separate wallet governance packet.
7. Addressing Past Feedback
We want to thank the Livepeer stakeholders who gave feedback on earlier versions of this pre-proposal. That feedback improved the proposal materially by surfacing three important issues: the security boundary needed to be clearer, the scope was too abstract, and the budget needed to match the size of the work more credibly.
This revision responds directly to those points. It narrows the first workload claim, explicitly defines the system as an open-source tool rather than a decentralized protocol, makes the public consumer path and governance shape more legible, and ties the four-month ask to reviewable milestone outputs. During the core engineering period, the team will remain responsive to ongoing feedback and incorporate useful improvements.
8. FAQ
1. Who is WEAVE for? WEAVE is designed for both the creation of entirely new workloads and the implementation of changes to existing ones.
2. How much automation exists in WEAVE? A WEAVE user can select their preferred level of automation. They can choose to manually review each stage, leave the review to the agent for auto-authorization, or take a highly hands-on approach in the creation process. The lifecycle agents are capable of automating the entire workload lifecycle, including scanning for novel opportunities.
3. How will WEAVE workloads be deployed to orchestrators? The Embody team will maintain a registry where the lifecycle agents of every WEAVE user can post their workloads. Livepeer orchestrators can then browse this registry and select to deploy these workloads through a single command.
4.How are you sure that workloads will be secure? The security evaluation process naturally sits outside the domain of individual WEAVE users. All workloads will be automatically inspected by centralized lifecycle agents operated by the Embody team. Furthermore, every workload will require a manual review before it is approved for deployment to the registry.
5. Will WEAVE use existing Livepeer components for the workload lifecycle and orchestrator payments? Yes. WEAVE will use Bring Your Own Compute (BYOC) for workload deployment, alongside Livepeer gateways and the clearinghouse for workload delivery and payments. The custom Embody parts that previously fulfilled these functions will be replaced with their mapped Livepeer-specific components.
6. What happens if you aren’t finished in the provided timeframe? All provided funds managed by the multisig will be converted to LPT and sent back to the treasury.
9. References & Technical Appendix
This appendix serves as the deeper review bundle behind the shorter forum post. The post stays high-level; the linked docs carry the architecture, roadmap, budget, and governance detail.
Repositories
-
embody-skill: https://github.com/its-DeFine/embody-skill
-
livepeer-ops: https://github.com/its-DeFine/livepeer-ops
-
Unreal_Vtuber: https://github.com/its-DeFine/Unreal_Vtuber
Packet Docs
note: packet docs are being actively updated for the new version
", replyCount: 21, views: 423, likeCount: 39, datePosted: "Feb 17, 2026", lastActivity: "Apr 1, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Metrics and SLA Foundations for NaaP", href: "https://forum.livepeer.org/t/3189", author: "By speedybird (@speedybird)", content: "Thank you to everyone who reviewed the earlier pre-proposal and shared detailed feedback in the forum and during the Watercooler. The concerns raised around scope, cost, architectural risk, and MVP clarity were well-founded and directly informed this revision.
This updated pre-proposal reflects a deliberate reset toward a smaller, clearer Network-as-a-Product MVP. The scope has been significantly narrowed, the budget reduced, and the architecture simplified to prioritize time-to-value, reuse of existing Livepeer infrastructure, and immediate usefulness to gateways, orchestrators, and ecosystem teams.
Below is the revised pre-proposal. We welcome the community’s review and feedback on the updated scope, design, and framing. We will be present on this coming Monday’s Water Cooler for discussion.
Cloud SPE Pre-Proposal: Network-as-a-Product (NaaP) MVP – SLA Metrics, Analytics, and Public Infrastructure
Abstract
This pre-proposal seeks treasury funding for the Livepeer Cloud Special Purpose Entity (SPE) to design, build, and operate a focused Network-as-a-Product (NaaP) MVP for SLA metrics, analytics, and public visibility.
The objective of this work is to make the Livepeer network measurable, comparable, and trustworthy at a network level by delivering a small but complete set of standardized performance, reliability, and demand metrics. These metrics will be publicly observable and designed to support gateway providers, orchestrators, and ecosystem builders evaluating Livepeer as production infrastructure.
This MVP intentionally prioritizes time-to-value, architectural simplicity, and reuse of existing Livepeer infrastructure, while establishing a durable foundation for future SLA-aware routing, scaling, and productization efforts led by Livepeer Inc, the Livepeer Foundation, and the community.
Rationale
As Livepeer advances toward the Network-as-a-Product vision, predictable service characteristics and transparent performance signals become essential. While the network supports real workloads today, participants lack a shared, network-wide view of performance, reliability, and demand that can be used to assess suitability for production use.
Community discussions around earlier drafts of this initiative strongly aligned on the problem, while raising important concerns around scope, cost, architectural risk, and MVP clarity. This pre-proposal reflects that feedback by narrowing focus to a practical MVP that:
- Demonstrates clear value with minimal complexity
- Leverages existing data sources and pipelines wherever possible
- Avoids protocol changes, enforcement mechanisms, or premature decentralization
- Produces immediately usable outputs for real network participants
Key challenges addressed by this proposal include:
- Fragmented metrics: Existing performance and reliability data is dispersed across systems and difficult for non-core teams to consume.
- Limited network-level visibility: Gateway providers and orchestrators cannot easily compare performance across regions, workloads, or peers.
- Adoption friction: Without transparent, shared metrics, external developers and partners struggle to evaluate Livepeer for serious workloads.
- Missing foundation for NaaP evolution: Future SLA-aware routing, scaling, and automation require a trusted measurement layer first.
The Cloud SPE is well positioned to deliver this work as neutral, public infrastructure, building on its prior experience operating gateways, test tooling, dashboards, and analytics for the Livepeer network.
Importantly, this proposal does not attempt to enforce SLAs, modify protocol incentives, or introduce new routing logic. Its purpose is to establish shared measurement and learning infrastructure as a prerequisite for those future decisions.
Deliverables
The NaaP MVP will deliver a constrained, end-to-end metrics system focused on observability and learning inspired by the NaaP product MVP and Foundation roadmap.
1. Core SLA Metrics (MVP Scope)
- A standardized set of network, performance, and reliability metrics sufficient to evaluate orchestrator and GPU behavior across workflows.
- Metrics sourced primarily from job tester gateway and orchestrator-emitted telemetry, with targeted additions only when other Gateways opt-in.
2. Network Test & Verification Signals
- Operation of one or more reference load-test gateways to generate consistent, reproducible performance signals for live AI video pipelines.
- Public test scenarios (aka test datasets) designed to reflect real workloads while remaining transparent and community-verifiable. These will be captured in Github.
- Test results contributed into the same analytics layer as organic network traffic to enable comparison (when other Gateways participate).
3. Analytics & Aggregation Layer
- Lightweight ETL and aggregation pipelines to transform raw metrics into network-level views.
- Computation of a small number of derived indicators as outlined in the Metrics Catalog
- Data structured for efficient querying without requiring dashboards to load raw job data.
4. Public Dashboard & APIs
- A standalone public dashboard presenting live and historical metrics.
- Public, read-only APIs for aggregate SLA scores and hardware.
- Clear paths for gateways and ecosystem teams to consume the data directly or mirror it into their own analytics systems.
5. Operations & Stewardship
- Ongoing operation of testing, analytics, and dashboard infrastructure.
- Maintenance, monitoring, and community support for the MVP for 1 year.
Any scope not outlined here is not part of the Deliverables and out of the scope of this proposal.
Key Milestones
Milestone 1 – Metrics Collection & Aggregation
- Define and implement the minimal metrics set
- Aggregate existing telemetry into a unified analytics layer
- A basic dashboard showing sample data flowing end to end
Milestone 2 – Test Signals & Derived Analytics
- Deploy reference load-test gateways
- Launch a public dashboard with core views
- APIs for ecosystem consumption
Milestone 3 – Stabilization & Review
- Harden infrastructure for reliability and cost efficiency
- Document metrics, assumptions, and known gaps
- Review outcomes with the community to determine next steps
Timeline
Delivery is anticipated to take approximately six months (and already underway as of November 2025). This is dependent on the team’s development velocity and subject to change. Preliminary design and validation work has begun to reduce delivery risk.
- November 2025 - Works began on original proposal and discovery process
- February 2026 – Milestone 1: Metrics Collection & Aggregation
- March 2026 – Milestone 2 – Test Signals & Derived Analytics
- April 2026 – Milestone 3 – Stabilization & Review
Budget
Total Requested Budget: $90,000
This budget supports:
- Engineering work to aggregate, validate, and expose SLA-relevant metrics
- Development of Load Testing Gateway (AI Job Tester + Gateway enhancements) and Network Data Scraper
- Development of minimal analytics and public-facing dashboards
- Development of DevOps infrastructure and automation
- Operation of testing, analytics, and storage infrastructure for approximately one year
- Ongoing maintenance, documentation, and community support
The budget is intentionally sized for a thin but complete MVP, designed to validate assumptions, inform future investment, and avoid long-term commitments before value is demonstrated.
Closing Note
This pre-proposal reflects extensive community and Livepeer Inc feedback and represents a deliberate step toward a simpler, clearer, and more actionable NaaP MVP.
By focusing on shared measurement rather than enforcement or protocol change, this work aims to give the Livepeer ecosystem a common understanding of network behavior today — and a solid foundation for deciding what to build next.
", replyCount: 12, views: 331, likeCount: 48, datePosted: "Jan 10, 2026", lastActivity: "Apr 14, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Lisar SPE Release Notes", href: "https://forum.livepeer.org/t/3159", author: "By serial_winner (@serial_winner)", content: "As part of our monthly accountability updates, the Lisar SPE is happy to share our second monthly progress update covering—what we’ve completed, what’s currently in motion, and what’s coming next.
Quick note: This release notes will serve as a way to share what work is going on with Lisar. All future reports will be added under this thread so anyone can easily track progress without hunting for older updates. Dive in to explore what’s happening and please reach out or reply if you have any questions.
October - Status Update
We previously published our first update sharing details of what work was done, if you missed it please find link to the report here
November – Status Update
The Lisar SPE is actively working toward our core deliverable:
unlocking delegation access for everyone globally by enabling fiat-based delegations (USD, NGN, GBP, KES, and more).
Here’s what was completed in November
- Completed a closed beta with users and internal testers
- Switched the transparency dashboard to live mode, enabling real-time community visibility
- Public launch after beta validation
Closed Beta Testing
We kicked off a closed beta in early November with a group of early users. This allowed us to test the entire lifecycle—depositing fiat, converting to LPT, delegating, tracking rewards, and withdrawing back to fiat—with real users.
The beta surfaced minor UX improvements, but overall validation was strong, and all core flows performed as expected.
Live Transparency Dashboard
Our public transparency dashboard is now live.
This means the community can monitor Lisar’s progress in real time—delegators onboarded, total fiat converted, total delegations and more.
Dashboard link: https://lisarstake.com/dashboard
Community transparency is one of our commitments, so getting this live was a major step.
Gearing Up for Public Launch
With beta successfully completed, we’ve shifted into launch mode.
Announcements are ready and will be going out shortly. We’re now entering the final stage outlined in the original four-month proposal with the remaining months focusing on driving adoption and scaling the platform responsibly.
Milestones & Timeline (As Outlined on the proposal)
Check out full proposal on the forum
Build the Core Platform — Completed
- Full fiat → LPT → delegation flow implemented
- Secure fiat on/offramp integrations for multiple currencies
- Gas sponsorship enabled (users never need ETH)
- Delegation + reward tracking in fiat equivalents
- Seamless withdrawals back to fiat
The core platform is stable and production-ready.
Transparency Dashboard — Completed
The dashboard now tracks and displays real-time metrics:
- Number of delegators onboarded
- Total fiat converted
- Total LPT delegated through Lisar
- Delegations per orchestrator
Launch & Scale — In Progress
Up Next
- Launch & Scale - we’re opening access for anyone to delegate on Livepeer through Lisar, with announcements going out across all channels soon. Our next phase focuses on bringing delegators onboard responsibly marking the transition from building → testing → growth.
Find below all relevant links on Lisar, we look forward to sharing more updates soon
Links
-
Begin staking on the Lisar app
-
Track live progress on the dashboard
-
Learn about Lisar, Livepeer, and staking through Lisar Academy
-
Guides on how to stake on livepeer through lisar are up on youtube
-
Follow development on Github
Hey everyone,
Wanted to share some updates on WEAVE as we get into Month 1 execution. There’s a team change, a budget adjustment, and some governance work happening.
SPE Naming
To align SPE naming with mission objectives, the WEAVE proposal deliverables are being operated now under WEAVE Growth SPE. Embody SPE stays its own thing, focused on embodied agent workloads. The broader roadmap lives under WEAVE Growth SPE.
Team Structure Updates
Dane decided to move on from WEAVE for personal reasons, and we parted on good terms.
Dane built the Unreal Engine avatars and most of the game UI that powered our PixelStreaming workloads. He was dedicated, hardworking, and consistently showed up when it counted. He overdelivered on his initial Embody deliverables and brought the game to a mature, production-ready state. The game builds he produced are what the Embody workloads ran on. We’re genuinely grateful for his contribution and wish him all the best going forward.
On the IP side, Dane has committed to granting the WEAVE Growth SPE entity a perpetual, royalty-free license to the source code with sub-licensing rights, allowing us to use, modify, and sublicense it as needed. The source can’t be MIT because of third-party plugin restrictions, but the license covers us fully. The packaged game goes MIT, same as all future Embody releases. We will follow up with Dane on the necessary actions and paperwork to make sure this is properly finalized. This development makes sure that the source code will become an other asset for the growth of Livepeer and ensures that Dane’s departure does not compromise our ability to create future workloads using Unreal Engine.
Budget
We will discuss actively with the community to make sure that the SPE acts according to stakeholder intent to decide what will happen to the funds that where earmarked towards Dane’s compensation.
Governance and transparency
We are currently discussing with the team the creation of a lightweight legal entity with non-profit operating provisions, where financial reporting and management obligations would be written into the founding documents themselves. The entity will operate with strict non profit provisions for the benefit of the whole Livepeer ecosystem and will possess ownership of the financial(incentives) and IP assets(unreal engine game, weave website, etc..) of the SPE.
What that looks like: budget, spending, and compensation reported publicly. Governance processes published online, how decisions get made, how workloads get evaluated, how incentive packets get managed. All incentive programs will run in the open with published criteria, schedules, and outcomes.
We’re still working out the exact structure, reporting format, and cadence with the team. Once that’s decided, we’ll share it publicly.
Month 1 Deliverables
You can find the month 1 deliverables spec bellow, we are currently finalizing this before posting the final version. Any feedback welcome.
Deliverables spec doc
WEAVE Growth SPE — Month 1 Deliverables
Version: v0.2 (April 2026)
Owner: DeFine
Technical Reviewer: Rick
Completion Rule: No deliverable is complete until Rick signs off on its evidence pack.
Month 1 Operating Logic
The dependency chain is:
- M1-D1 builds the open-source WEAVE Tool.
- M1-D2 exposes that capability through the DAO-operated hosted WEAVE App + API.
- M1-D3 activates the incentive loop that drives workflow creation and app creation.
- M1-D4 proves publicly what users did, what converted, and what became monetization-ready.
Month 1 completion is based on whether this machine exists, is live, and is measurable. Raw demand volume is a KPI outcome, not the sole approval condition.
M1-D1 — Open-source WEAVE Tool
Description: A public, open-source, self-hostable WEAVE Tool that lets any technical user create Scope .json workflows, run viability research, run QA, and extend the system independently. This is the core product layer, not the hosted WEAVE service.
Outcome: By end of Month 1, a technical user can take the WEAVE Tool repo, follow the docs, generate valid workflows, inspect viability + QA outputs, and adapt the tool for their own API or webapp if they choose.
Excludes: Hosted uptime, DAO-run API reliability, user onboarding/account systems, and incentive logic.
Sub-deliverables
M1-D1.1 — Public repo and licensing live
| Criteria | Done? |
|---|---|
| Repo is public | |
| License file is present | |
| README covers setup, architecture, usage, and extension points | |
| Example assets or example outputs are included or linked |
Evidence: Public repo URL, license file, README, architecture note.
M1-D1.2 — Workflow creation engine works
| Criteria | Done? |
|---|---|
Tool can generate valid Scope .json workflows | |
| At least 3 materially distinct workload classes are supported | |
| Each class has a reproducible example output | |
| Export path for generated workflows is documented |
Evidence: 3 exported .json outputs, supported workload list, reproduction notes.
M1-D1.3 — Commercial viability module integrated
| Criteria | Done? |
|---|---|
| Workflow creation includes an explicit viability-assessment step | |
| Viability output is generated inside the tool | |
| Output includes target user, use case, monetization path, market rationale, and build/no-build reasoning | |
| Viability output is saved or exportable alongside the workflow artifact |
Evidence: UI or CLI artifact showing the viability step, 3 example analyses, output schema.
M1-D1.4 — QA module integrated
| Criteria | Done? |
|---|---|
| QA stage exists inside the tool flow | |
| QA returns pass/fail or a structured issue list | |
Checks cover valid .json structure, required fields, runnable shape, and broken-config detection | |
| At least 1 failed QA case is demonstrated |
Evidence: QA checklist/spec, pass artifacts, fail artifact, output examples.
M1-D1.5 — Self-hostability proven
| Criteria | Done? |
|---|---|
| Fresh setup can be completed from the published docs | |
| Tool runs without requiring the hosted WEAVE App/API | |
| A technical user can extend or wrap the tool for their own API or webapp | |
| No WEAVE-managed account is required to use the core tool |
Evidence: Self-host setup note, fresh-run proof, extension or wrapping example.
Evidence Pack for Rick Review
- Public repo URL
- License file
- README + architecture note
- 3 sample workflow outputs
- 3 viability outputs
- QA pass/fail artifacts
- Self-host proof
M1-D2 — Hosted WEAVE App + API Access Layer
Description: The DAO-operated, free hosted access layer for WEAVE. This is the managed WEAVE App and public API that use the WEAVE Tool underneath so users can access WEAVE services without self-hosting.
Outcome: By end of Month 1, a user can complete the workflow-creation path through the hosted WEAVE App or API, view viability + QA outputs, and move from workflow creation into app creation without local deployment.
Excludes: Open-source licensing proof for the core tool, standalone self-host proof, and incentive policy itself.
Sub-deliverables
M1-D2.1 — Free hosted WEAVE webapp live
| Criteria | Done? |
|---|---|
| Public URL loads successfully | |
| User can complete workflow creation end-to-end through the webapp | |
| Viability and QA outputs are visible in the hosted flow | |
| Workflow output is viewable and exportable |
Evidence: Public URL, screenshots, end-to-end web demo recording.
M1-D2.2 — Public API live
| Criteria | Done? |
|---|---|
| API endpoint(s) are publicly reachable | |
| API docs are published | |
| Workflow creation, viability, and QA are available via API | |
| At least 1 successful API-created workflow is demonstrated |
Evidence: API base URL, API docs, example request/response, API demo artifact.
M1-D2.3 — Hosted surface is clearly downstream of D1
| Criteria | Done? |
|---|---|
| Hosted outputs use the same core workflow format as the WEAVE Tool | |
| Relationship between D1 and D2 is documented publicly | |
| Hosted access policy is stated | |
| Free access terms or limits are stated |
Evidence: Public note on tool vs hosted surface, access policy doc, parity note.
M1-D2.4 — Workflow-to-app creation path live
| Criteria | Done? |
|---|---|
| User can move from workflow creation into an app-creation path through the hosted surface | |
| This path is exposed in the webapp and documented in the API flow | |
| At least 1 example app-creation flow is demonstrated | |
| Output from this step can be used in the incentive system |
Evidence: App-creation demo, UI/API docs, example artifact.
M1-D2.5 — No-self-hosting path demonstrated
| Criteria | Done? |
|---|---|
| A user can complete the hosted flow without local deployment | |
| A web-based end-to-end demo exists | |
| An API-based end-to-end demo exists | |
| The hosted path is usable by a non-technical participant |
Evidence: Web demo, API demo, hosted-path walkthrough.
Evidence Pack for Rick Review
- Public webapp URL
- Public API docs URL
- Tool-to-hosted parity note
- Web demo recording
- API demo recording
- Example workflow artifact
- Example app-creation artifact
M1-D3 — Incentive Program Launch
Description: The live WEAVE incentive system that moves users from registration to workflow creation to app creation, with identity-gated enrollment to reduce bot/sybil spam. Phase 1 rewards support workflow and app creation. Phase 2 rewards unlock only after an app proves quality, monetization, and electronic payment readiness.
Outcome: By end of Month 1, incentive registration is live, users can enroll from both the WEAVE Tool and the WEAVE App, Phase 1 rewards are active, and the Phase 2 unlock rules are explicit and operational.
Sub-deliverables
M1-D3.1 — Incentive rules and governance published
| Criteria | Done? |
|---|---|
| Public incentive rules document exists | |
| Phase 1 and Phase 2 are defined separately | |
| Participant types and eligible actions are defined | |
| Calculation method and cadence are defined | |
| Dispute and exception handling path is defined |
Evidence: Public rules URL, version/date, example calculation, dispute policy.
M1-D3.2 — Worldcoin-gated registration live
| Criteria | Done? |
|---|---|
| Incentive enrollment path is live | |
| Worldcoin verification is required before incentive participation | |
| Anti-spam / anti-sybil rules are published | |
| At least 1 successful registration is evidenced |
Evidence: Enrollment URL, verification screenshots, policy note, first successful registration artifact.
M1-D3.3 — Dual onboarding paths live
| Criteria | Done? |
|---|---|
| User can enter the incentive system from the WEAVE Tool path | |
| User can enter the incentive system from the hosted WEAVE App path | |
| Differences between self-hosted and hosted participants are documented | |
| Both paths feed the same KPI/reporting surface |
Evidence: Tool-path walkthrough, app-path walkthrough, onboarding documentation.
M1-D3.4 — Phase 1 rewards active
| Criteria | Done? |
|---|---|
| Phase 1 rewards are live during Month 1 | |
| Workflow creation is a qualifying action | |
| App creation is a qualifying action | |
| Incentive window and cadence are publicly stated |
Evidence: Launch announcement, rules excerpt, active incentive window proof.
M1-D3.5 — Phase 2 activation gate defined and testable
| Criteria | Done? |
|---|---|
| Phase 2 activation criteria are published | |
| Criteria require proof of quality standards | |
| Criteria require proof of monetization | |
| Criteria require ability to accept electronic payments | |
| A qualifying evidence template or checklist exists |
Evidence: Phase 2 rules section, qualification checklist, sample evidence packet.
M1-D3.6 — First live cycle operational
| Criteria | Done? |
|---|---|
| Weekly calculation or review runbook exists | |
| First cycle calculation artifact is produced | |
| At least 1 real participant moved through registration → action → calculation | |
| Exception/dispute handling is usable |
Evidence: Runbook, first cycle artifact, participant flow proof, exception log template.
Evidence Pack for Rick Review
- Public incentive rules URL
- Worldcoin-gated registration proof
- Tool-path and app-path onboarding proofs
- Phase 1 live-window proof
- Phase 2 qualification checklist
- Weekly runbook
- First cycle calculation artifact
M1-D4 — Public KPI / Reporting Surface
Description: The public reporting layer that shows whether WEAVE is actually acquiring users, helping them create workflows, converting those workflows into apps, and moving those apps toward quality and monetization readiness.
Outcome: By end of Month 1, the public can verify acquisition, production, quality, monetization-readiness, and workflow-to-app stickiness from a live KPI/reporting surface.
Sub-deliverables
M1-D4.1 — Public KPI surface live
| Criteria | Done? |
|---|---|
| Public URL exists | |
| Metric definitions are visible | |
| Update cadence is stated | |
| Current snapshot is visible |
Evidence: Public dashboard/report URL, screenshots, metric definitions.
M1-D4.2 — Acquisition metrics live
| Criteria | Done? |
|---|---|
| New users are counted publicly | |
| Incentive-verified registrations are counted publicly | |
| Tool-path vs app-path acquisition can be distinguished or derived | |
| Reporting window is stated |
Evidence: KPI surface screenshot, acquisition methodology note.
M1-D4.3 — Production and completion metrics live
| Criteria | Done? |
|---|---|
| Workflows started are counted publicly | |
| Workflows completed are counted publicly | |
| Incentive completions are counted publicly | |
| Apps created are counted publicly |
Evidence: KPI surface screenshot, metric definitions, sample snapshot.
M1-D4.4 — Quality and monetization progression metrics live
| Criteria | Done? |
|---|---|
| Apps crossing the quality threshold are counted publicly | |
| Apps that are monetization-ready are counted publicly | |
| Apps that can accept electronic payments are counted publicly | |
| Phase 2-eligible apps are counted publicly |
Evidence: KPI surface screenshot, methodology note, status definitions.
M1-D4.5 — Stickiness / progression metrics live
| Criteria | Done? |
|---|---|
| Workflow-to-app conversion metric is defined | |
| Post-action stickiness metric is defined | |
| Repeat builder activity or return behavior metric is defined | |
| Measurement window and method are published |
Evidence: KPI definitions, methodology note, example snapshot.
M1-D4.6 — Public reporting artifacts published
| Criteria | Done? |
|---|---|
| Weekly report template exists | |
| First public KPI snapshot/report is published | |
| Caveats and methodology are published | |
| Reporting owner/update cadence is named |
Evidence: Report template, first snapshot/report, methodology doc.
Evidence Pack for Rick Review
- Public KPI/dashboard URL
- Metric definitions
- Acquisition, production, and conversion screenshots
- First public report or snapshot
- Methodology / caveat note
Month 1 KPI Targets
These are operating targets, not the sole completion gate. Month 1 approval depends first on whether the system is live, reviewable, and measurable.
| KPI | Month 1 Target |
|---|---|
| New verified incentive users | 10+ |
| Workflows started | 10+ |
| Workflows completed | 5+ |
| Apps created | 3+ |
| Phase 1 incentive completions | 3+ |
| Apps reaching quality review | 1+ |
| Apps reaching monetization readiness | 1+ |
| Workflow-to-app stickiness | 25%+ of workflow completers start an app path |
| Public KPI snapshots/reports published | 1+ live snapshot and weekly cadence defined |
Rick Review Gate
Rick signs off separately on each deliverable:
- M1-D1 technical completeness of the open-source WEAVE Tool
- M1-D2 hosted operability of the WEAVE App + API
- M1-D3 correctness and operability of the incentive mechanism
- M1-D4 correctness and integrity of the public KPI/reporting surface
| Deliverable | Evidence Submitted | Rick Status | Final |
|---|---|---|---|
| M1-D1 Open-source WEAVE Tool | |||
| M1-D2 Hosted WEAVE App + API | |||
| M1-D3 Incentive Program Launch | |||
| M1-D4 Public KPI / Reporting Surface |
Livepeer Inc Daydream Product Update
Hi all. I wanted to provide a product update from Livepeer Inc so that the community could see all that’s being built as we focus on Livepeer’s Realtime AI infrastructure opportunity.
Much of this information is available by following along on the Daydream X Account, the Daydream Discord, and the Scope release notes, but is summarized here for the Livepeer community.
Daydream
As you know, Livepeer Inc is primarily focused on finding demand for the Livepeer Network’s realtime AI capabilities through the Daydream brand. Realtime AI video is an early space where Livepeer is suited to offer unique value because of its GPUs and low latency streaming stack, expertise, and ecosystem alignment - however the arrival of the market remains dependent upon when key open source model capabilities drop that are acceptable to enterprise grade commercial use cases.
Because of the early state of the market, Daydream has developed an open source community oriented workflow management tool called Scope.
Scope is a local-first, open-source engine for real-time AI generation across video, audio, and computer vision. Creators compose custom pipelines visually, plug into their existing tools, and run inference on their machine or in the cloud via the Livepeer Network.
It incorporates the latest realtime AI models, lets users configure them into custom workflows we pre-and-post-processors, LORAs, audio + video input sources and outputs, and more. The early tinkerers and researchers in this market are using Scope to get access to, and control, the latest innovations in the space. And as more mainstream usable models arrive, this foundation will be the best control plane to get the outputs that users want. Here are some of the latest features to ship.
- Real-time video compositing powered by VACE. Edit and transform live video with inpainting, outpainting, and style transfer running at interactive framerates. This is continuous inference, not asynchronous generation. Every frame goes through the pipeline.
- Node-based workflow builder. Build custom AI pipelines by connecting nodes visually, spanning generative video, audio, and computer vision. A new scheduler node lets you fire timed triggers across the graph, and the canvas UX is designed to get you from zero to running workflow fast.
- Remote inference via the Livepeer Network. Scope offloads GPU-heavy workloads to the cloud rather than requiring a local 4090. Artists and developers without high-end hardware become direct network consumers. This is the link between Scope adoption and Livepeer demand.
- Plugin architecture for community-built nodes. The v0.2.4 release introduced a node abstraction system that lets anyone ship a custom Scope plugin. Initial examples include a YouTube input source and a local LLM prompt enhancer. The ecosystem is just getting started.
- LoRA style control. Apply and blend LoRAs for fine-grained aesthetic control, from subtle adjustments to full style transforms. Scope handles LoRA manifest resolution as part of workflow configuration.
- Shareable, importable workflows. Export and import full pipeline configurations, including LoRA manifests and dependency resolution. This makes community sharing practical and lowers onboarding friction for new users finding Scope through Daydream.live.
- Beat-synced parameter modulation. Parameters sync to Ableton Link and MIDI clock, making Scope viable for live performance where timing matters. OSC support extends reactive control to any tool that speaks the protocol.
- Integrations for professional creative tools. Scope connects to TouchDesigner (including the StreamDiffusionTD plugin by dotsimulate’s Lyell Hintz), Resolume, and other creative software via NDI, Spout, Syphon, OSC, and MIDI. This is where Scope reaches the communities most likely to run persistent, high-throughput inference on the network.
- Audio generation alongside video. Pipelines can return audio alongside video output, streamed over WebRTC. Scope is no longer a video-only tool.
- LTX-2 video model with ~18x faster loading. The latest LTX-2 integration ships with real-time pacing controls, faster model loading, faster prompt changes, and Ampere GPU compatibility. New users get text-to-video out of the box.
- MCP server for agentic workflows. Scope exposes an MCP server interface, connecting it to AI agent frameworks. Early infrastructure for a category of agentic, real-time AI applications that could drive sustained inference demand on the network.
Realtime Audio Generation
While realtime AI video and world models remain interesting early prototypes, many of the users who are getting value out of Scope are overlapping with the audio space. Often times performers, VJs, musicians are using scope to generate visuals for live performances, concerts, or event installations, because Scope enables the AI outputs to respond to the audio inputs themselves. Naturally, this is leading to a lot of interest in integrations with audio tools (Resolume), and even generative audio generation itself.
More to come on this in a future update (or join the upcoming water cooler chats to see live demos), but the team has worked on some research breakthroughs to get audio generating in realtime using one of the previously batch-only open source models. This is a big break through that lets creators actually configure AI as an instrument that plays along or modifies songs in real time, responding to many different input or prompt changes instantly.
Video is early and requires some model and workthrough breakthroughs before being widely adopted, however this realtime audio generation is compelling and high quality enough to make an impact today. Look for some proof of concept applications coming soon to test driving demand to Livepeer through these channels.
The Path to the Livepeer Network
As with all new capabilities developed by within Inc, typically we first work on validating demand with early users through prototypes and early productionization of our products. Typically the fastest path here is using cloud infrastructure at low volumes so that the community doesn’t have to incur the work of adding support for new experimental capabilities if there’s no actual demand or market fit.
The next phase typically consists of Livepeer Network pilots, using self-run infrastructure on the network and working with select orchestrators willing to run these job types early as they’re developed, so that they can be built the right way.
Next you typically see scaled load testing and redudnancy/backup service provided by the network. The Inc products typically use the cloud for some traffic, and duplicate it to the network to evaluate its performance and realiability. Eventually shifting more and more to the network as its primary source of traffic. Why? Because the Livepeer network is typically far more cost effective than the cloud - and ultimately needs to be as reliable or better.
Finally Inc deprecates any cloud infrastructure entirely, and relies entirely on the network. This is the path that Studio went through in the early days, before relying solely on the Livepeer network for transcoding traffic. And it is the path that Daydream and Scope are undergoing as well. Currently Scope is routing traffic through the Livepeer network, and is onboarding select O’s to troubleshoot the integrations for popular workflows.
Livepeer Studio
With the focus on Daydream and the Realtime AI opportunity, Livepeer Studio continues to support existing customers, but is not primarily focused on growing further demand generation through transcoding or streaming. As previously communicated, we’re working with the Frameworks team to carry the torch on transcoding and a modern low latency streaming stack on top of the network, and pursuing demand generation efforts on that track. And Orchestrators will likely see transcoding volumes from Studio ramping down in the coming months..
Orchestrator guidance from a Daydream perspective
Daydream is trying its hardest to find Product-Market-Fit and drive scaled demand to the Livepeer Network! But as we remain early in that process across our ambitious bets, its important to note that many of these GTM efforts are experiments. New models and capabilities drop, each often times requiring different hardware. We are committed to bringing demand to the Livepeer network, and the best way for Orchestrators to support is to flexibly provision hardware in support of these experiments. That may mean spinning resourced capacity up and down as experiments ebb-and-flow. It likely does not mean over-investing in purchased dedicated hardware until it is clear there is scaled demand for a job. Orchestrators should share openly and honestly what pricing they need to charge in support of these experiments, and consider the impact of delegated stake and reward cuts on their P&L when doing so.
Thanks everyone. Looking forward to showing off some of the latest Scope and realtime AI capabilities on the upcoming water cooler chats.
", replyCount: 2, views: 136, likeCount: 12, datePosted: "May 6, 2026", lastActivity: "May 6, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "Pre-Proposal: Network Engineering SPE", href: "https://forum.livepeer.org/t/3240", author: "By honestly_rich (@honestly_rich)", content: "Proposed by: Rich O’Grady (Co-Director, Livepeer Foundation) and Rick Staa (Technical Director, Livepeer Foundation)
Abstract
The Network Engineering SPE is a delegated pool of capital that funds scoped engineering RFPs and retroactive contributor grants, without requiring a standalone on-chain proposal for each initiative. The mission of the SPE is to fund smaller engineering initiatives to make the Livepeer network more observable, performant, and developer-centric. It targets the $2k–$20k range of work that the current SPE process makes too slow to fund. We’ve seen this model work: the Explorer upgrade proved what a vetted contributor with a clear scope and accountable oversight can deliver. This SPE scales that, while exploring a more retroactive model.
Requested duration: 3 month (pilot program) + 2 weeks (retro)
Requested budget: $95,000 USD-equivalent in LPT
The Problem
The Livepeer project needs the ability to execute fast and targeted actions to support users, operators and builders on the network. The current SPE model works well for large, multi-month programmes. It doesn’t work for the $2k–$20k engineering work the network often needs.
The friction is structural:
- A full SPE proposal requires significant time before any work begins
- On-chain vote cycles add weeks of delay — often longer than the work itself
- As AI tooling compresses build cycles, this gap is getting worse, not better
The result: well-supported, clearly-needed work goes unfunded — not because the community doesn’t want it, but because there’s no efficient path to fund it.
This was validated by three public community discussions (March–April 2026) with strong consensus. The Water Cooler on 13 April returned a clear signal: move forward.
The Solution
The aim of this SPE is to build a delegated funding pool with a fast, accountable process which funds critical engineering work fast. This would sit alongside the formal SPE process, which primarily focuses on longer-term (3+ months) initiatives.
This SPE replicates and scales that model across two funding tracks: RFPs dividing up known work and distributing it amongst the community; and retroactive grants funding for work that has already been completed.
Note: Retroactive Grants don’t necessarily go through the Roadmap process.
Eligibility Areas
For the first round of SPE funding, there will be 3 primary focus areas, which are focused on Livepeer’s core stakeholder groups, each with different needs:
Priority 1: [Developers] Developer Portal — The 5-Minute API — Work on the Developer Portal’s critical path: the engineering that takes a developer from docs to first inference call in under five minutes, from any MCP-compatible tool. This includes the Python SDK, BYOC container tooling, payment and auth infrastructure, agentic harness tooling, and any library or scaffolding that removes onboarding friction.
Priority 2: [Delegators] Explorer — Participation & Observability — Work that makes the Explorer a better permissionless participation portal for operators and delegators. This includes staking interfaces, governance participation features, network observability dashboards, and tooling that surfaces real network behaviour to support informed decision-making.
Priority 3: [Orchestrators] Tooling & Infrastructure — Work that helps orchestrators run more reliably, scale capacity, and integrate with the evolving SDK-first architecture. This includes containerisation, orchestration tooling, runtime improvements, go-livepeer contributions, and infrastructure that affects network reliability and operational experience. Note: that this area requires particularly strong community validation before an RFP is promoted
Funding Track 1 — RFPs (~$5k–$20k, 2–8 weeks)
Full proposed process: RFP Process - Network Engineering SPE
Community members post Roadmap Suggestions on the forum, where the suggester drafts initial requirements and deliverables with the community - facilitated by the Livepeer Foundation. After an initial community validation via Discord, the Foundation then publishes a finalised RFP for contributors to apply to, and assigns it to a selected team or contributor within 7 days.
All decisions and disbursements are published with written rationale. Payment is split across three tranches: 25% on signing; 50% on delivery and verification by Review team; and 25% on impact paid at the end of the pilot (in August). Any incomplete work or assessments at the end of the pilot triggers a brief remediation window.
Three Suggestions have already been initially identified and will be scoped with community contributors and then validated by the community to become (or not become) RFPs:
- Roadmap Suggestion 1: Developer Portal & Discoverability platform
- Roadmap Suggestion 2: Improved Explorer as Participation Portal
- Roadmap Suggestion 3: Payment Clearinghouse & Remote Signer
Funding Track 2 — Retroactive Grants (<$5k, retroactive)
Full proposed process: Retro Grants Funding Process - Network Engineering SPE
Build first, then apply. Contributors post a public application on the forum after the work has shipped. The Review Team reviews on a monthly cycle and publishes an approve, partial approve, or decline decision with written rationale. Approved grants are paid in full in a single disbursement.
The primary bar is impact, not completion. Each application must name the problem, who had it, and who is already using the solution. Describe what was built, link to the work, and state the amount requested. Projected usage does not count.
Examples of eligible work and impact:
- OpenRouter integration — 5 developers discovered and integrated with Livepeer via OpenRouter.
- Live video-to-video / BYOC full-stack runner — 3 community members running live video-to-video with BYOC end-to-end — a workflow the network had no viable path for before this.
- Agentic harness tooling — 3 Livepeer solutions cutting time-to-working-agent-loop from days to hours using standardised scripts, tool definitions, and prompts.
Quantifying Impact
Impact means the network becomes more observable, more reliable, or more easy-to-use for Developers, Delegators or Orchestrators. The concrete impact signals that the Review team will look at are all about usage and adoption:
- Named adopter — a specific person or team outside the author is using it in their own work.
- Downstream dependency — another project or contributor is building on top of it.
- Capability confirmed in the wild — someone who wasn’t involved in the build has run it successfully.
It is also expected that the work is maintained and still live by the end of the program. What impact is not: download counts, repo stars, or the builder using their own tool.
What This SPE Isn’t
Not a demand generation fund (coming soon). The Network Engineering SPE funds the engineering substrate: the infrastructure that makes demand solutions like Daydream, Frameworks, Blueclaw, Streamplace possible. Go-to-market, marketing, and end-user services are out of scope.
Not an open-ended bounty pool. Every disbursement requires a verified definition of done. Work must be complete, reviewable, address a recognised need and have verifiable impact.
Replacing the SPE Process. For larger pieces of work network engineering (e.g. 2+ months with multiple contributors), the onchain treasury process will still be used.
SPE Governance Structure
Custody: Funds held by the Livepeer Foundation.
Decision process: All decisions made live in weekly Review Team meetings via a simple 2-of-3 vote, with a written decision log published after each meeting. Any Review Team member with a direct financial interest in a decision must recuse.
| Role | Who | Responsibilities | Paid by SPE? |
|---|---|---|---|
| Review Team Lead & Technical Director | Rick Starr (Livepeer Foundation) | Refines scope of RFPs with Suggester; leads RFP team selection; signs off on technical quality for all RFP Track 1 work - sole gate on technical delivery, no broader Review Team vote required; produces pilot evaluation report | No |
| Reviewer, RFPs | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Reviews and scores RFP applications against evaluation criteria; represents community interests in first-pass scoping; casts an independent vote on Tranche 2 and Tranche 3 payouts; publishes written rationale for any dissent or recusal | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Reviewer, Retro Grants | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Owns first-pass review of retroactive grant applications against the published rubric (supported by AI pre-screening); triages and quality-screens incoming applications; compiles monthly review shortlist; proactively surfaces strong unsubmitted community work; casts an independent vote on retroactive grant approvals | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Roadmap Manager | Rich O’Grady (Livepeer Foundation) | Facilitates community Suggestion sessions; manages the Suggestions pipeline; promotes validated ideas to the roadmap; signals funding path per item | No |
| Program Manager | Mehrdad (Livepeer Foundation) | Runs and records weekly Review Team meetings; maintains the public decision log; tracks milestone status; manages remediation windows | No |
| Contributors | Community | Deliver scoped outputs with full ownership and accountability | Yes |
This SPE will have AI-native workflows embedded from day one, reducing Review Team overhead, keeping the public record current, and ensuring consistent quality control without manual lift.
AI-led tasks include: retro grant pre-screening; automating meeting notes and updates; decision log drafting; application triaging.
Timeline
15 May 2026 — Funding Programs Live
Review Team seated. Weekly cadence established. First 3 RFPs posted publicly. Retroactive grants open. Public tracker live. Key assessment: did we launch on time with the right scope?
30 Jun 2026 — First Deliveries Verified
At least 1 RFP delivered. At least 1 retroactive grant awarded. Key assessment: is the quality bar holding? Is the 14-day selection target being met?
30 Aug 2026 — Pilot Complete
Minimum 3 RFPs delivered, with aspirational goal of 5. All impact assessments done. All spend published. Evaluation report out with a clear recommendation: continue, modify, or stop.
Budget Breakdown
Total requested: $95,000 USD-equivalent (4-month pilot)
| Budget line | Assumption | Amount (USD-equiv.) |
|---|---|---|
| Review Team Member compensation (×2) | 2 × $7,500 / 3 months (~10 hrs/week) | $15,000 |
| Track 1 — RFP pool | Aim: 3 RFPs over pilot at ~$15k average | $45,000 |
| Track 2 — Retroactive Grants pool | Aim: 5 retroactive grants at ~$3k average | $15,000 |
| Funding Buffer — for additional grants or RFP | To either be allocated, returned to the onchain treasury or carried over to future SPE | $20,000 |
| Total | $95,000 (in LPT) |
If uptake for RFPs and/or retroactive grants are lower than expected at the 30 June checkpoint, the Review Team has the opportunity to reallocate between pools based on where community activity is strongest.
Any unspent funds or incomplete RFPs at pilot end are returned to treasury (with a small undefined, remediation window if work near completion).
All amounts sized using the 30-day moving average LPT price at the time of RFP approval.
Deliverables
Pilot success criteria (3 months):
1. Minimum 3 RFPs reach verified impact - At least 3 scoped engineering RFPs complete with a confirmed definition of done, verified by the Technical Director and community Review Team Members. Each delivery is published publicly with a written rationale and outcome assessment.
2. Minimum 5 retroactive grants funded - At least 5 retroactive grant applications reviewed and awarded, covering work that has already shipped and meets the published rubric. Each award is published publicly with written rationale, the amount approved, and the impact evidence submitted by the contributor.
3. Three public SPE updates published during pilot - One per month (June, July, August). Each update covers: RFPs active and delivered, retroactive grants reviewed and awarded, funds disbursed to date, and Review Team decisions with written rationale. Published within 7 days of the monthly Review Team meeting. Zero black-box decisions.
4. Pilot evaluation & impact report published by 30 Aug 2026 - A concise report covering: RFPs funded and delivered, retroactive grants awarded, total spend vs. budget, community signal on delivered work, and a clear recommendation: continue, modify, or stop. Written for a community audience, not an internal one.
Transparency and Accountability
- Every RFP and retroactive grant decision published publicly with written rationale.
- Public tracker RFPs: all RFPs, status, funds allocated and disbursed, Review Team decisions
- Public tracker grants: all retro grant applications, decisions, amounts awarded, and impact evidence
- Review Team Members publish justification for any overrule or recusal
- Monthly written reporting to the community (per SPE norms) plus update at Water Cooler
- All conflicts of interest disclosed and recused
Embody Team: Retrospective
Date: February 9, 2026
This document provides a retrospective of the Embody team’s (DeFine + Dane) workstream, covering the Agent SPE Phase 2 period and post-separation efforts through February 9, 2026. Our focus is on the open-source deliverables and technical contributions made to the Livepeer ecosystem. This retrospective is scoped to the Embody-managed workstream and does not cover the full scope of the Agent SPE Phase 2 grant.
Executive Summary: What We Shipped
•Open-Source VTuber Stack: Shipped and maintained Unreal_Vtuber, a Pixel Streaming stack enabling Livepeer orchestrators to run embodied MetaHuman avatars. Tagged open-source releases from v1.0.0 (December 18, 2025) through v1.3.5 (January 28, 2026).
•Dynamic Customization: Delivered extensive avatar and environment customization, including a character customizer, morph targets, hair, clothing, and camera controls, as documented in the weekly work logs.
•Incentives Pipeline: Delivered and maintained an orchestrator incentives program, funded from Embody-managed inference credits. This work was outside the strict Phase 2 scope.
•Multi-Platform Broadcast Pipeline: Built a broadcast-capable pipeline (WebRTC source with an optional RTMP output for platforms like Twitch and YouTube). Automation of this pipeline is in active development.
•Continued Work Post-Separation: Despite a reduced budget following the separation from Agent SPE, the Embody team continued execution and completed the majority of technical and non-technical deliverables.
Timeline Highlights
•April 14, 2025: Phase 2 begins.
•August 20, 2025: Separation settlement and allocations are publicly posted.
•December 18, 2025: First tagged Unreal_Vtuber open-source release (v1.0.0).
•January 28, 2026: Unreal_Vtuber v1.3.5 is tagged.
•February 7, 2026: On-chain reconciliation packet is produced.
Promised Deliverables vs. Current Status
This section is structured by the Phase 2 proposal’s “Months 1–6” deliverables, with Embody’s current status and evidence pointers. Items Embody did not manage (funds and execution) are explicitly marked as Defer to Agent SPE.
| Deliverable | Status (Embody) | Evidence |
|---|---|---|
| Technical Excellence | Delivered a full embodied-avatar pipeline and operational Pixel Streaming stack. The “sub-100ms” latency target from the proposal is a goal; this document does not include an independent benchmark. | Unreal_Vtuber OSS stack |
| Livepeer Integration | Delivered. Orchestrators can run embodied avatars via the open-source stack, and Phase 2 weekly logs show Livepeer inference integrations and related pipeline work. | Unreal_Vtuber OSS stack, Livepeer-Autogen-Integration, plugin-livepeer-inference, NeuroSync-Core, eliza-livepeer-integration |
| Streamlined Onboarding | Delivered simplified operator onboarding for the OSS stack. The “<5 minutes” figure is a proposal target, not a universally measured setup time. | Unreal_Vtuber OSS stack |
| Comprehensive Analytics | Partially delivered. OSS/runtime telemetry exists, and production-validation analytics were set up via PostHog (not a treasury deliverable). | PostHog work is documented in internal repository files. |
| Dynamic Customization | Delivered. Dane’s Phase 2 work (Animator Handbook) documents extensive customization work. | Animator Handbook |
| Multi-Platform Deployment | Delivered a broadcast-capable pipeline (Pixel Streaming → RTMP) and ongoing operator automation for autonomous streaming. A fully autonomous, interactive VTuber is live and continuously improving, with memory and background tool-use capabilities. Note: the autonomous agent is continuously improving, and its current state represents the baseline of its capabilities. | Livi Embody — Autonomous VTuber (Twitch) |
| Protocol Partnerships | ElizaOS integration plans were paused/deprioritized; the primary execution path pivoted to Embody-managed direct integrations. | eliza-livepeer-integration |
| Startup Integration Program | Defer to Agent SPE. Embody did not manage these funds post-separation. | Separation Post |
| Usage Incentives | Defer to Agent SPE for the original proposal line item. Separately, Embody did operate and maintain an orchestrator incentives program funded from the inference credits allocated to Embody. Note: Livepeer stakeholders requiring the full unredacted financial/accounting pack may contact the Embody team. | Public Financial Audit Pack |
| Use Case Demonstrations | Delivered multiple demonstrations and continues to iterate on use cases, including a live autonomous interactive VTuber stream. | Livi Embody — Autonomous VTuber (Twitch), Livepeer Fireside Appearance, Unreal Vtuber Demo |
| Financial Sovereignty Infrastructure | In progress. Will be released this week with the public release of the OpenClaw agent repository. | Release pending. |
| Diversified Revenue Frameworks | Embody has begun operating in the agent-to-agent economy(see embody.zone). A further community update on this deliverable will follow within the week. | embody.zone |
Sources Used
", replyCount: 1, views: 129, likeCount: 4, datePosted: "Feb 10, 2026", lastActivity: "Mar 25, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "RFP — Delegator UX Analysis (Self-Custody vs. Custodial Staking)", href: "https://forum.livepeer.org/t/3254", author: "By Rick (@rickstaa)", content: "Budget Envelope: Up to $10,000 USD equivalent
Date Issued: 2026-05-14
Issued By: Rick Staa
1. Purpose
Objective
Analyse the Explorer’s delegation UX against the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) and comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX sets the bar for user expectations. Produce a design-ready specification for a self-custody delegation experience that could compete or pull users away from the path of least resistance of holding on an exchange, thus preserving the direct protocol participation that makes self-custody valuable: governance rights, earnings transparency, and independence from custodial intermediaries.
Problem Statement
Livepeer’s on-chain delegator count has fallen ~36% over two years, but total staked LPT and participation rate have held steady or grown. The gap is explained by a structural shift: centralised exchanges are delegating growing pools of custodial LPT without any user-facing staking product. No major exchange such as Binance, Coinbase, or Kraken offers LPT staking. The delegation is happening without user involvement.
The Explorer’s delegation flow needs to be compelling. Simply holding LPT on an exchange while the exchange stakes it without their involvement results in centralisation that undermines the network. We want actively grow delegators and direct governance participation.
We need to:
- Precisely quantify the UX gap between the Explorer’s delegation flow and the top staking UX standard set by major exchanges and comparable PoS tokens
- Identify the specific design and information-architecture changes that would improve self-custody delegation
- Produce a shippable design brief the Foundation can convert directly into build work (retro grants or follow-on RFP)
Desired Outcome
Within 3–4 weeks, we have:
- A competitive teardown showing exactly where and why the Explorer’s delegation experience falls short of the standard set by exchange staking UX or other ecosystems at each step of the journey
- A design-ready specification for a “minimum competitive staking experience” in the Explorer
- A prioritised backlog of improvements with expected impact and effort that can be shipped as follow-on work
2. Requirements
Key Deliverables
- Competitive teardown
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
Dimensions: steps-to-stake, time-to-stake, information architecture, trust signals, yield presentation, risk framing, reward monitoring, and unstaking/exit experience (including offboarding from custodial products to self-custody: withdraw/transfer out). Each comparison should include annotated screenshots or screen recordings documenting the full flow. - Secondary analysis (decentralised staking UX): Review of the best delegation and staking experiences across decentralised protocols, including but not limited to Lido, Rocket Pool, Cosmos/Keplr and/or other PoS ecosystems with strong delegator UX. This analysis should identify the UX patterns, information design, and onboarding flows that make these experiences work. What can we learn from the best decentralised staking UX?
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
- Standardised baseline scenarios (for comparable measurement)
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Scenario A (Fiat start): new user starting from fiat → staked/delegated
- Scenario B (Funds already on exchange): user already has funds on exchange → staked/delegated
- Include at least one concrete comparison like “What does it take to get $100 → staked LPT?” (time, steps, fees, failure points) across platforms.
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Gap specification
- Map each identified UX gap to a specific Explorer screen, flow, or missing feature
- Classify gaps by severity (blocking, friction, polish) and estimated effort (small / medium / large)
- Highlight the gaps that most plausibly explain the shift toward custodial staking
- Design brief: “Permissionless staking experience”
- What would a new user need to see and do in the Explorer to choose self-custody delegation over leaving LPT on an exchange?
- Wireframes or annotated flow diagrams (not just a written list) for the redesigned delegation journey
- Cover: discovery/landing, orchestrator selection, delegation execution, earnings monitoring, and re-delegation/exit
- Address the specific trust and clarity signals that custodial services provide and the Explorer currently lacks (yield clarity, risk framing, earnings visibility)
- Instrumentation plan
- What events and metrics need to be tracked to measure delegation conversion going forward
- Minimal and implementable, scoped to what can be added to the Explorer’s existing codebase without major infrastructure changes
- Propose a baseline measurement approach so future UX improvements can be evaluated
- Prioritised backlog
- Top 10–15 improvements ranked by: expected impact on self-custody delegation competitiveness, implementation effort, and dependency chain
- Clear split: quick wins (shippable via retro grants) vs. larger items (follow-on build RFP)
- Each item should reference the competitive teardown evidence that motivates it
Out of Scope
- Diagnosing why delegator count is declining (recent analysis confirms stake is centralising because exchanges are delegating custodial holdings, not because users are opting into custodial staking products)
- Implementing UX changes (this is an analysis + design specification scope)
- Protocol-level changes to staking mechanics (separate governance process)
- Large-scale design-system restyle work
- General-purpose user research unconnected to the competitive comparison
- Outreach / conversion strategy to migrate exchange-delegated LPT toward Explorer-based self-custody delegation (higher earnings, voting rights, orchestrator choice).
- Arbitrum liquidity readiness for sustained new stake originating from fiat — does the contributor see any concerns from the journey/teardown research?
Definition of Done — by Tranche
| Tranche | % Budget | Unlocks On |
|---|---|---|
| 1 — Signing | 25% | Audit plan agreed, competitive teardown scope confirmed (which services, which dimensions), kickoff doc filed |
| 2 — Delivery | 50% | Competitive teardown delivered, gap specification delivered, design brief with wireframes delivered, instrumentation plan delivered |
| 3 — Impact | 25% | Prioritised backlog accepted by Review Team after a public comment window (≥7 days) on the forum, with community feedback/reaction explicitly weighed as part of acceptance. At least 3 items converted into follow-on work (retro grants or RFP scope) within 30 days of acceptance. |
3. Capabilities Required
Skills
- Product design and UX analysis (competitive teardowns, information architecture)
- Ability to produce wireframes or annotated flow diagrams (Figma, or equivalent)
- Familiarity with web3 wallet interaction patterns and staking UX conventions
- Experience analysing decentralised protocol UX (delegation flows, validator/orchestrator selection, reward mechanics)
- Ability to read a modern web codebase (Explorer is React/Next.js) enough to assess instrumentation feasibility
Knowledge
- How centralised staking services (Binance, Coinbase, Kraken) present yield, risk, and onboarding to retail users for comparable PoS tokens
- How decentralised staking ecosystems (Cosmos/Keplr, Lido, Rocket Pool or others) handle delegator onboarding, validator discovery, and earnings transparency
- Livepeer delegator mechanics (L1/L2 bridging, orchestrator selection, reward cuts, bonding/unbonding)
- Web3 onboarding friction points and trust/risk communication patterns
Attitude
- Evidence-first: every recommendation grounded in the competitive comparison, not opinion
- Design-oriented: outputs should be visual and specification-ready, not just written analysis
- Comfortable working in public and with async feedback from the Foundation team
4. Proposal Requirements
Please include:
- Contributor / Team Overview
- Why you’re a fit (prior UX competitive analysis, staking product design, or delegation UX work)
- Approach & Timeline (mapped to tranches above)
- Which competitive services you will analyse (primary: Binance, Coinbase, Kraken staking UX for comparable PoS tokens; secondary: best-in-class decentralised staking/delegation experiences, e.g. Lido, Rocket Pool, Cosmos/Keplr or others you propose)
- Design output format (Figma, annotated screenshots, other)
- Pricing breakdown
- Conflict of interest disclosure
5. RFP Timeline
| Milestone | Date |
|---|---|
| RFP Posted | 2026-05-18 |
| Application Deadline | 2026-05-24 |
| Decision Announced | 2026-05-29 |
| Project Start | 2026-06-01 |
| Expected Completion | 2026-07-03 |
6. Proposal Submission Instructions
Reply to this forum post in the comments with your proposal (linking a doc or including it inline).
Questions: reach out to @rickstaa on Discord.
7. Decision & Governance
Selection criteria:
- Quality and specificity of competitive analysis approach, and do they understand what makes exchange staking UX set user expectations, and why users default to holding on exchanges?
- Demonstrated ability to produce design-ready specifications (wireframes, annotated flows), not just written reports
- Practical instrumentation plan that respects the Explorer’s current technical constraints
- Speed and clarity of execution
Activating the Livepeer Ecosystem Roadmap — What’s Changing and How to Get Involved
The Ecosystem roadmap at roadmap.livepeer.org has never fully satisfied us. It’s basically been a display board rather than a genuine two-way system between the Contributors, Foundation and the broader community.
We’re now fixing that. I’ll explain what’s changing and what we need from everyone in the ecosystem.
What the Roadmap Is For
The roadmap exists to make ecosystem direction visible, coherent, and participatory.
It is not a promise or a project plan. It is a shared and evolving view of where the network is headed. This includes projects being worked on, who is driving them, and where there are opportunities to pick things up or get involved.
Every item on the roadmap defines a problem, a desired outcome, and who owns it. Items previously came from only two sources:
-
Advisory Board Recommendations — captured from the project with domain experts last year
-
Foundation Priorities — strategic improvements identified and funded by the Foundation
And, excitedly we now introduce a third way for things to enter the roadmap:
- Community Suggestions — ideas submitted and validated through our community process
In this way, the Roadmap becomes further signalling for the things people want to see come to the network, and a way for everyone to put forward impactful projects and provide upvotes are genuine input signals — not performative ones — towards what gets prioritised.
Why a Community Intake Process Matters
Until now, there has been no clear path for a community member to propose something and see it taken seriously without testing it with a formal forum post or completing an SPE proposal. A lot of great suggestions and discussions were had in Discord or raised on Watercooler’s, but with no structured process, no feedback loop, and no progress, many were lost.
That’s a problem for two reasons. First, the ecosystem has real expertise distributed across contributors, orchestrators, builders, and delegators. Some of the best ideas about what Livepeer needs to build next will come from people outside Inc and the Foundation. Second, without a visible process, community participation in the roadmap is essentially performative and people have no reason to engage if engagement doesn’t lead anywhere.
A real intake process changes that. It creates accountability on both sides: the community commits to submitting well-formed proposals and raising the standard of what we want to see from suggestions, and the Foundation commits to reviewing them, providing a space and rituals for them to see further discussion, and publishing those discussions and any decisions to help advance items in ways that make sense.
The New Community Suggestions Process
Anyone in the Livepeer ecosystem can now propose a roadmap item at any time. Here’s how it works:
Step 1 — Submit a proposal
Go to roadmap.livepeer.org and click “Suggest an Item” (in future you will be able to simply type /featurebase directly in Discord). A good proposal answers three things: What is the problem? Why does it matter for the ecosystem? What does success look like?
I’ve included two project “proposals” that were recommended as part of the discussions on the emissions system which can act as helpful examples and jumpstart the monthly call:
Step 2 — Community upvoting (ongoing)
All proposals are publicly visible in the roadmap with the tag “Propose Ecosystem Project”. Upvote and comment on proposals you care about at any time. Momentum is tracked — strong community support between monthly cycles can fast-track a proposal into the next review.
Step 3 — Foundation weekly review
We will aim to review the proposal queue every week and provide some feedback about how to prepare for the monthly Discord call. The aim here is to get things well prepared and to knock out early things that are maybe not going to reach a bar that we all feel is needed for high quality suggestions.
Step 4 — Monthly Discord call
Once a month proposals are presented on a community Discord call (if not the Watercooler, another forum). We’ll make a quick intro for each including upvotes and comments, the Proposer can give a short discussion, and then community asks questions and discusses live. After the call, the Foundation will publish key information and based on sentiment aim to reach a decision that can be shared: Promoted to Roadmap, Held for Next Cycle, or Declined with a public explanation.
Proposals that are promoted join the roadmap with status Under Review and from there move forward to planning - most likely as an RFP, a SPE Proposal, or some other mechanism that makes sense (more on this to come).
How to Use the Roadmap
The roadmap will work best when the community is actively engaged. We’ll start to talk about it more effectively on the Watercooler. But here’s what we need from you:
Upvote items you care about. This does two things: it signals priorities to the item owners, and it subscribes you to all future updates on that item. When an item’s status changes, you’ll be notified automatically. Your upvote has a visible consequence.
Comment on items. Share context, ask questions, flag concerns, or offer to contribute. Comments are read by item owners and the Foundation. Good comments surface edge cases and use cases that owners may not have considered. Good feedback here can shut things down before wasting everyones time, but also can give the right spark for a simple idea to be a gamechanger!
Follow the changelog at roadmap.livepeer.org/changelog. Every major milestone on a roadmap item generates a changelog entry. This is the progress reporting mechanism for the ecosystem — if you want to know what’s actually shipping, the changelog is where to look.
Propose new items if you think something important is missing. The bar for submitting is low — a clear problem statement, the reason is matters, and what the future looks like if that proposed item becomes a success. The intake process can take it from there. Items might make it to the roadmap, or be bundled or merged with others “under” an SPE.
For teams shipping roadmap items: update your item’s status when it changes (this auto-notifies everyone who upvoted), and post a changelog entry at each major milestone. The changelog is your public progress report — it replaces ad hoc updates scattered across Discord and forum threads.
A Note on What This Is Not
This is not a governance mechanism. In time this can become a good funnel for the onchain treasury but for now we want this to become a way to surface useful recommendations and priorities and created a clearer, more participatory and better recorded feedback loop. The proposed items and upvotes are strong input signals — not binding votes. This is intentional: it keeps the roadmap strategically coherent while ensuring community voice is genuinely considered and visibly acted upon.
If a proposal is declined, people will know why. Transparency is a key part of this commitment. And people can always still take things to a vote onchain.. this just raises the bar for proposing something if it’s already been tested with the community in this way
Get Started
The roadmap is already live at roadmap.livepeer.org. The suggestions board is open now.
If you’ve had something in mind that Livepeer shoud be building or capitalising on, now is a great time to share it. We will run the first Monthly call at the end of Mark. And if you have questions or feedback just drop them in here.
", replyCount: 0, views: 67, likeCount: 3, datePosted: "Mar 9, 2026", lastActivity: "Mar 9, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "LiveInfra SPE - Q2 2026 Operations", href: "https://forum.livepeer.org/t/3241", author: "By Joey (@ftkstaking)", content: "Proposer: FTK Staking
Contact: admin@liveinfraspe.com
ENS: liveinfra.eth
Discord: @ftkuhnsman
Abstract
The LiveInfra SPE requests funding for Q2 2026 to sustain the Community Node service, a free RPC service for the Livepeer community. This proposal covers recurring operational costs for cloud infrastructure, maintenance, and support.
Mission
The LiveInfra SPE is dedicated to empowering the Livepeer community by providing free, reliable blockchain infrastructure services.
Problem and Importance
Livepeer community members depend on accessible blockchain infrastructure to develop decentralized video applications and tools. Operating RPC nodes is costly and complex, and third-party providers charge high fees. The Community Node service delivers free Arbitrum L2 and Ethereum L1 RPC endpoints, removing these barriers.
Rationale
Continued funding for the LiveInfra SPE ensures the Community Node service remains a dependable, cost-free resource for Livepeer builders. Quarterly treasury proposals align with community oversight, minimize market impact on LPT, and allow flexibility to adapt to evolving ecosystem demands.
Current Operations
The LiveInfra SPE provides free Arbitrum L2 and Ethereum L1 RPC endpoints to Livepeer community members (active orchestrators, broadcasters, and delegators with ≥100 LPT staked). It operates with geo-distributed Ethereum L1 nodes (execution and consensus) and Arbitrum Nitro L2 nodes, load-balanced for reliability. A custom proxy layer authenticates user requests via unique URL endpoints, accessible after wallet-based signup. To sign up visit the LiveInfra SPE website and authenticate with your livepeer wallet.
Q2 2026 Operations Plan
This proposal focuses on sustaining service operations for Q2 2026 (April–June). No new features are proposed in the current maintenance period.
Milestones and Timeline
- April–June 2026:
- Maintain to support node operations.
- Perform ongoing maintenance, including software upgrades, node database pruning, and storage expansion as needed.
- Monitor and ensure 99.9% uptime, with transparent reporting via the KPI dashboard.
- Provide community support for RPC service users.
- Ongoing:
- Submit the next quarterly proposal (Q3 2026) to secure continued funding.
Budget Breakdown
The LiveInfra SPE requests $14,000 USD for Q2 2026 to cover recurring operational costs. Funds will be converted to LPT at submission using the current LPT price, with a margin to buffer against price volatility during voting.
- Quarterly Recurring Costs - $14,000
- $9,000 USD - Infrastructure: Quarterly costs for high-quality cloud resources.
- $5,000 USD - Maintenance & Support: Quarterly node upkeep, software upgrades, database pruning, and user support - $2,500 reduction from prior quarter due to improvements in operational efficiency and platform stability.
Total Request USD: $14,000
Total LPT tokens requested: TBD - Determined at submission based on the current LPT price.
Funding Strategy
The LiveInfra SPE will continue submitting quarterly treasury proposals to fund operations, ensuring:
- Minimized Market Impact: Requesting smaller LPT amounts each quarter and selling gradually to reduce price volatility.
- Community Oversight: Quarterly proposals allow the Livepeer community to assess the service’s performance and value, approving continued funding or requesting adjustments as needed.
This approach ensures transparency, sustainability, and alignment with community priorities.
Community Feedback and Suggestions
The LiveInfra SPE values input from the Livepeer community to ensure the RPC Service continues to meet ecosystem needs. We invite community members to suggest enhancements, new features, or additional infrastructure offerings during the pre-proposal review process. Please share your ideas directly in the Livepeer forum as part of the discussion for this proposal. Your feedback will help shape future proposals and ensure the service evolves to support the community’s goals.
", replyCount: 1, views: 55, likeCount: 4, datePosted: "Apr 21, 2026", lastActivity: "Apr 24, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "How Livepeer Solves The Tech Industry's Biggest Dilemma", href: "https://forum.livepeer.org/t/3257", author: "By Dane (@webRTCisCool)", content: "Introduction
With the Clarity Act getting closer to realization I’ve been pondering which protocols will benefit the most. Obviously the act has not passed and therefore, nothing is guaranteed or set in stone. However, based on the current language of the act, tokens with real utility, high levels of decentralization, and strong community will be categorized as digital commodities. Based on this language I believe Livepeer is safe. Livepeer’s utility is undeniable and may serve as a solution to the technology industry’s biggest problem. Resource intensive infrastructure.
The Problem
Centralized compute providers are relying on massive datacenters that require a ton of energy and cooling that only increase with demand. This creates negative sentiment around not only the data centers, but the deployments those data centers support, which right now leans heavily into AI and ML.
The Solution
Livepeer NaaP could potentially be the industry’s saving grace. While we don’t think about it every day, because of our immediate access to it, fresh water, energy, and land are all critical resources. As demand for compute continues to grow, so does the need for efficient ways to handle that demand.
Livepeer’s ability to provide compute for resource intensive use cases can help redistribute some of that demand across node operators that don’t necessarily rely on water intensive cooling infrastructure. If centralized providers continue to scale data centers aggressively, especially in drought stricken areas, governments may eventually step in to regulate resource usage, forcing providers to think differently about how cloud based software is deployed.
Decentralized networks like Livepeer offer a solution. Instead of concentrating compute in a few large facilities, workloads can be distributed across orchestrators using existing hardware that is far less reliant on our extremely valuable land, lakes, and rivers.
Conclusion
I am not saying decentralized compute or Livepeer replaces data centers, but acts as an environmentally friendly solution to handle growing demand through decentralized compute distribution. If Livepeer can capitalize on this specific issue, the protocol may help offset resource consumption. Potentially reducing the need for hundreds of millions to billions of gallons of water usage, and hundreds of acres of would-be datacenter land over time.
The Clarity Act favors real utility and decentralization. Livepeer is the definition of real utility and decentralization. With engineers working hard around the clock to increase the network’s accessibility, capabilities, and transparency, Livepeer is well positioned to solve or help alleviate the biggest problem our future generations will face.
GO LIVEPEER!
", replyCount: 0, views: 42, likeCount: 3, datePosted: "May 21, 2026", lastActivity: "May 21, 2026", categoryId: 6, categoryName: "Protocol", categoryColor: "#BF1E2E" }, { title: "AI capability discovery", href: "https://forum.livepeer.org/t/3233", author: "By chrishobcroft (@chrishobcroft)", content: "Can someone help me learn how to reliably query which AI capabilities and models the network offers?
I’m running a gateway on localhost with 0.065 deposit and 0.03 reserve. I’m managing to get some text-to-image jobs through, which is a great start.
Ideally it would be great to be able to query:
- all available job types,
- which models are available,
- what the O’s pricing is.
It seems like an obvious thing from my limited perspective, that an O will advertise its services to a G.
Any clues?
", replyCount: 0, views: 35, likeCount: 2, datePosted: "Mar 7, 2026", lastActivity: "Mar 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }]; export const forumByNewest = [{ title: "How Livepeer Solves The Tech Industry's Biggest Dilemma", href: "https://forum.livepeer.org/t/3257", author: "By Dane (@webRTCisCool)", content: "Introduction
With the Clarity Act getting closer to realization I’ve been pondering which protocols will benefit the most. Obviously the act has not passed and therefore, nothing is guaranteed or set in stone. However, based on the current language of the act, tokens with real utility, high levels of decentralization, and strong community will be categorized as digital commodities. Based on this language I believe Livepeer is safe. Livepeer’s utility is undeniable and may serve as a solution to the technology industry’s biggest problem. Resource intensive infrastructure.
The Problem
Centralized compute providers are relying on massive datacenters that require a ton of energy and cooling that only increase with demand. This creates negative sentiment around not only the data centers, but the deployments those data centers support, which right now leans heavily into AI and ML.
The Solution
Livepeer NaaP could potentially be the industry’s saving grace. While we don’t think about it every day, because of our immediate access to it, fresh water, energy, and land are all critical resources. As demand for compute continues to grow, so does the need for efficient ways to handle that demand.
Livepeer’s ability to provide compute for resource intensive use cases can help redistribute some of that demand across node operators that don’t necessarily rely on water intensive cooling infrastructure. If centralized providers continue to scale data centers aggressively, especially in drought stricken areas, governments may eventually step in to regulate resource usage, forcing providers to think differently about how cloud based software is deployed.
Decentralized networks like Livepeer offer a solution. Instead of concentrating compute in a few large facilities, workloads can be distributed across orchestrators using existing hardware that is far less reliant on our extremely valuable land, lakes, and rivers.
Conclusion
I am not saying decentralized compute or Livepeer replaces data centers, but acts as an environmentally friendly solution to handle growing demand through decentralized compute distribution. If Livepeer can capitalize on this specific issue, the protocol may help offset resource consumption. Potentially reducing the need for hundreds of millions to billions of gallons of water usage, and hundreds of acres of would-be datacenter land over time.
The Clarity Act favors real utility and decentralization. Livepeer is the definition of real utility and decentralization. With engineers working hard around the clock to increase the network’s accessibility, capabilities, and transparency, Livepeer is well positioned to solve or help alleviate the biggest problem our future generations will face.
GO LIVEPEER!
", replyCount: 0, views: 42, likeCount: 3, datePosted: "May 21, 2026", lastActivity: "May 21, 2026", categoryId: 6, categoryName: "Protocol", categoryColor: "#BF1E2E" }, { title: "RFP — Delegator UX Analysis (Self-Custody vs. Custodial Staking)", href: "https://forum.livepeer.org/t/3254", author: "By Rick (@rickstaa)", content: "Budget Envelope: Up to $10,000 USD equivalent
Date Issued: 2026-05-14
Issued By: Rick Staa
1. Purpose
Objective
Analyse the Explorer’s delegation UX against the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) and comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX sets the bar for user expectations. Produce a design-ready specification for a self-custody delegation experience that could compete or pull users away from the path of least resistance of holding on an exchange, thus preserving the direct protocol participation that makes self-custody valuable: governance rights, earnings transparency, and independence from custodial intermediaries.
Problem Statement
Livepeer’s on-chain delegator count has fallen ~36% over two years, but total staked LPT and participation rate have held steady or grown. The gap is explained by a structural shift: centralised exchanges are delegating growing pools of custodial LPT without any user-facing staking product. No major exchange such as Binance, Coinbase, or Kraken offers LPT staking. The delegation is happening without user involvement.
The Explorer’s delegation flow needs to be compelling. Simply holding LPT on an exchange while the exchange stakes it without their involvement results in centralisation that undermines the network. We want actively grow delegators and direct governance participation.
We need to:
- Precisely quantify the UX gap between the Explorer’s delegation flow and the top staking UX standard set by major exchanges and comparable PoS tokens
- Identify the specific design and information-architecture changes that would improve self-custody delegation
- Produce a shippable design brief the Foundation can convert directly into build work (retro grants or follow-on RFP)
Desired Outcome
Within 3–4 weeks, we have:
- A competitive teardown showing exactly where and why the Explorer’s delegation experience falls short of the standard set by exchange staking UX or other ecosystems at each step of the journey
- A design-ready specification for a “minimum competitive staking experience” in the Explorer
- A prioritised backlog of improvements with expected impact and effort that can be shipped as follow-on work
2. Requirements
Key Deliverables
- Competitive teardown
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
Dimensions: steps-to-stake, time-to-stake, information architecture, trust signals, yield presentation, risk framing, reward monitoring, and unstaking/exit experience (including offboarding from custodial products to self-custody: withdraw/transfer out). Each comparison should include annotated screenshots or screen recordings documenting the full flow. - Secondary analysis (decentralised staking UX): Review of the best delegation and staking experiences across decentralised protocols, including but not limited to Lido, Rocket Pool, Cosmos/Keplr and/or other PoS ecosystems with strong delegator UX. This analysis should identify the UX patterns, information design, and onboarding flows that make these experiences work. What can we learn from the best decentralised staking UX?
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
- Standardised baseline scenarios (for comparable measurement)
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Scenario A (Fiat start): new user starting from fiat → staked/delegated
- Scenario B (Funds already on exchange): user already has funds on exchange → staked/delegated
- Include at least one concrete comparison like “What does it take to get $100 → staked LPT?” (time, steps, fees, failure points) across platforms.
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Gap specification
- Map each identified UX gap to a specific Explorer screen, flow, or missing feature
- Classify gaps by severity (blocking, friction, polish) and estimated effort (small / medium / large)
- Highlight the gaps that most plausibly explain the shift toward custodial staking
- Design brief: “Permissionless staking experience”
- What would a new user need to see and do in the Explorer to choose self-custody delegation over leaving LPT on an exchange?
- Wireframes or annotated flow diagrams (not just a written list) for the redesigned delegation journey
- Cover: discovery/landing, orchestrator selection, delegation execution, earnings monitoring, and re-delegation/exit
- Address the specific trust and clarity signals that custodial services provide and the Explorer currently lacks (yield clarity, risk framing, earnings visibility)
- Instrumentation plan
- What events and metrics need to be tracked to measure delegation conversion going forward
- Minimal and implementable, scoped to what can be added to the Explorer’s existing codebase without major infrastructure changes
- Propose a baseline measurement approach so future UX improvements can be evaluated
- Prioritised backlog
- Top 10–15 improvements ranked by: expected impact on self-custody delegation competitiveness, implementation effort, and dependency chain
- Clear split: quick wins (shippable via retro grants) vs. larger items (follow-on build RFP)
- Each item should reference the competitive teardown evidence that motivates it
Out of Scope
- Diagnosing why delegator count is declining (recent analysis confirms stake is centralising because exchanges are delegating custodial holdings, not because users are opting into custodial staking products)
- Implementing UX changes (this is an analysis + design specification scope)
- Protocol-level changes to staking mechanics (separate governance process)
- Large-scale design-system restyle work
- General-purpose user research unconnected to the competitive comparison
- Outreach / conversion strategy to migrate exchange-delegated LPT toward Explorer-based self-custody delegation (higher earnings, voting rights, orchestrator choice).
- Arbitrum liquidity readiness for sustained new stake originating from fiat — does the contributor see any concerns from the journey/teardown research?
Definition of Done — by Tranche
| Tranche | % Budget | Unlocks On |
|---|---|---|
| 1 — Signing | 25% | Audit plan agreed, competitive teardown scope confirmed (which services, which dimensions), kickoff doc filed |
| 2 — Delivery | 50% | Competitive teardown delivered, gap specification delivered, design brief with wireframes delivered, instrumentation plan delivered |
| 3 — Impact | 25% | Prioritised backlog accepted by Review Team after a public comment window (≥7 days) on the forum, with community feedback/reaction explicitly weighed as part of acceptance. At least 3 items converted into follow-on work (retro grants or RFP scope) within 30 days of acceptance. |
3. Capabilities Required
Skills
- Product design and UX analysis (competitive teardowns, information architecture)
- Ability to produce wireframes or annotated flow diagrams (Figma, or equivalent)
- Familiarity with web3 wallet interaction patterns and staking UX conventions
- Experience analysing decentralised protocol UX (delegation flows, validator/orchestrator selection, reward mechanics)
- Ability to read a modern web codebase (Explorer is React/Next.js) enough to assess instrumentation feasibility
Knowledge
- How centralised staking services (Binance, Coinbase, Kraken) present yield, risk, and onboarding to retail users for comparable PoS tokens
- How decentralised staking ecosystems (Cosmos/Keplr, Lido, Rocket Pool or others) handle delegator onboarding, validator discovery, and earnings transparency
- Livepeer delegator mechanics (L1/L2 bridging, orchestrator selection, reward cuts, bonding/unbonding)
- Web3 onboarding friction points and trust/risk communication patterns
Attitude
- Evidence-first: every recommendation grounded in the competitive comparison, not opinion
- Design-oriented: outputs should be visual and specification-ready, not just written analysis
- Comfortable working in public and with async feedback from the Foundation team
4. Proposal Requirements
Please include:
- Contributor / Team Overview
- Why you’re a fit (prior UX competitive analysis, staking product design, or delegation UX work)
- Approach & Timeline (mapped to tranches above)
- Which competitive services you will analyse (primary: Binance, Coinbase, Kraken staking UX for comparable PoS tokens; secondary: best-in-class decentralised staking/delegation experiences, e.g. Lido, Rocket Pool, Cosmos/Keplr or others you propose)
- Design output format (Figma, annotated screenshots, other)
- Pricing breakdown
- Conflict of interest disclosure
5. RFP Timeline
| Milestone | Date |
|---|---|
| RFP Posted | 2026-05-18 |
| Application Deadline | 2026-05-24 |
| Decision Announced | 2026-05-29 |
| Project Start | 2026-06-01 |
| Expected Completion | 2026-07-03 |
6. Proposal Submission Instructions
Reply to this forum post in the comments with your proposal (linking a doc or including it inline).
Questions: reach out to @rickstaa on Discord.
7. Decision & Governance
Selection criteria:
- Quality and specificity of competitive analysis approach, and do they understand what makes exchange staking UX set user expectations, and why users default to holding on exchanges?
- Demonstrated ability to produce design-ready specifications (wireframes, annotated flows), not just written reports
- Practical instrumentation plan that respects the Explorer’s current technical constraints
- Speed and clarity of execution
Livepeer Inc Daydream Product Update
Hi all. I wanted to provide a product update from Livepeer Inc so that the community could see all that’s being built as we focus on Livepeer’s Realtime AI infrastructure opportunity.
Much of this information is available by following along on the Daydream X Account, the Daydream Discord, and the Scope release notes, but is summarized here for the Livepeer community.
Daydream
As you know, Livepeer Inc is primarily focused on finding demand for the Livepeer Network’s realtime AI capabilities through the Daydream brand. Realtime AI video is an early space where Livepeer is suited to offer unique value because of its GPUs and low latency streaming stack, expertise, and ecosystem alignment - however the arrival of the market remains dependent upon when key open source model capabilities drop that are acceptable to enterprise grade commercial use cases.
Because of the early state of the market, Daydream has developed an open source community oriented workflow management tool called Scope.
Scope is a local-first, open-source engine for real-time AI generation across video, audio, and computer vision. Creators compose custom pipelines visually, plug into their existing tools, and run inference on their machine or in the cloud via the Livepeer Network.
It incorporates the latest realtime AI models, lets users configure them into custom workflows we pre-and-post-processors, LORAs, audio + video input sources and outputs, and more. The early tinkerers and researchers in this market are using Scope to get access to, and control, the latest innovations in the space. And as more mainstream usable models arrive, this foundation will be the best control plane to get the outputs that users want. Here are some of the latest features to ship.
- Real-time video compositing powered by VACE. Edit and transform live video with inpainting, outpainting, and style transfer running at interactive framerates. This is continuous inference, not asynchronous generation. Every frame goes through the pipeline.
- Node-based workflow builder. Build custom AI pipelines by connecting nodes visually, spanning generative video, audio, and computer vision. A new scheduler node lets you fire timed triggers across the graph, and the canvas UX is designed to get you from zero to running workflow fast.
- Remote inference via the Livepeer Network. Scope offloads GPU-heavy workloads to the cloud rather than requiring a local 4090. Artists and developers without high-end hardware become direct network consumers. This is the link between Scope adoption and Livepeer demand.
- Plugin architecture for community-built nodes. The v0.2.4 release introduced a node abstraction system that lets anyone ship a custom Scope plugin. Initial examples include a YouTube input source and a local LLM prompt enhancer. The ecosystem is just getting started.
- LoRA style control. Apply and blend LoRAs for fine-grained aesthetic control, from subtle adjustments to full style transforms. Scope handles LoRA manifest resolution as part of workflow configuration.
- Shareable, importable workflows. Export and import full pipeline configurations, including LoRA manifests and dependency resolution. This makes community sharing practical and lowers onboarding friction for new users finding Scope through Daydream.live.
- Beat-synced parameter modulation. Parameters sync to Ableton Link and MIDI clock, making Scope viable for live performance where timing matters. OSC support extends reactive control to any tool that speaks the protocol.
- Integrations for professional creative tools. Scope connects to TouchDesigner (including the StreamDiffusionTD plugin by dotsimulate’s Lyell Hintz), Resolume, and other creative software via NDI, Spout, Syphon, OSC, and MIDI. This is where Scope reaches the communities most likely to run persistent, high-throughput inference on the network.
- Audio generation alongside video. Pipelines can return audio alongside video output, streamed over WebRTC. Scope is no longer a video-only tool.
- LTX-2 video model with ~18x faster loading. The latest LTX-2 integration ships with real-time pacing controls, faster model loading, faster prompt changes, and Ampere GPU compatibility. New users get text-to-video out of the box.
- MCP server for agentic workflows. Scope exposes an MCP server interface, connecting it to AI agent frameworks. Early infrastructure for a category of agentic, real-time AI applications that could drive sustained inference demand on the network.
Realtime Audio Generation
While realtime AI video and world models remain interesting early prototypes, many of the users who are getting value out of Scope are overlapping with the audio space. Often times performers, VJs, musicians are using scope to generate visuals for live performances, concerts, or event installations, because Scope enables the AI outputs to respond to the audio inputs themselves. Naturally, this is leading to a lot of interest in integrations with audio tools (Resolume), and even generative audio generation itself.
More to come on this in a future update (or join the upcoming water cooler chats to see live demos), but the team has worked on some research breakthroughs to get audio generating in realtime using one of the previously batch-only open source models. This is a big break through that lets creators actually configure AI as an instrument that plays along or modifies songs in real time, responding to many different input or prompt changes instantly.
Video is early and requires some model and workthrough breakthroughs before being widely adopted, however this realtime audio generation is compelling and high quality enough to make an impact today. Look for some proof of concept applications coming soon to test driving demand to Livepeer through these channels.
The Path to the Livepeer Network
As with all new capabilities developed by within Inc, typically we first work on validating demand with early users through prototypes and early productionization of our products. Typically the fastest path here is using cloud infrastructure at low volumes so that the community doesn’t have to incur the work of adding support for new experimental capabilities if there’s no actual demand or market fit.
The next phase typically consists of Livepeer Network pilots, using self-run infrastructure on the network and working with select orchestrators willing to run these job types early as they’re developed, so that they can be built the right way.
Next you typically see scaled load testing and redudnancy/backup service provided by the network. The Inc products typically use the cloud for some traffic, and duplicate it to the network to evaluate its performance and realiability. Eventually shifting more and more to the network as its primary source of traffic. Why? Because the Livepeer network is typically far more cost effective than the cloud - and ultimately needs to be as reliable or better.
Finally Inc deprecates any cloud infrastructure entirely, and relies entirely on the network. This is the path that Studio went through in the early days, before relying solely on the Livepeer network for transcoding traffic. And it is the path that Daydream and Scope are undergoing as well. Currently Scope is routing traffic through the Livepeer network, and is onboarding select O’s to troubleshoot the integrations for popular workflows.
Livepeer Studio
With the focus on Daydream and the Realtime AI opportunity, Livepeer Studio continues to support existing customers, but is not primarily focused on growing further demand generation through transcoding or streaming. As previously communicated, we’re working with the Frameworks team to carry the torch on transcoding and a modern low latency streaming stack on top of the network, and pursuing demand generation efforts on that track. And Orchestrators will likely see transcoding volumes from Studio ramping down in the coming months..
Orchestrator guidance from a Daydream perspective
Daydream is trying its hardest to find Product-Market-Fit and drive scaled demand to the Livepeer Network! But as we remain early in that process across our ambitious bets, its important to note that many of these GTM efforts are experiments. New models and capabilities drop, each often times requiring different hardware. We are committed to bringing demand to the Livepeer network, and the best way for Orchestrators to support is to flexibly provision hardware in support of these experiments. That may mean spinning resourced capacity up and down as experiments ebb-and-flow. It likely does not mean over-investing in purchased dedicated hardware until it is clear there is scaled demand for a job. Orchestrators should share openly and honestly what pricing they need to charge in support of these experiments, and consider the impact of delegated stake and reward cuts on their P&L when doing so.
Thanks everyone. Looking forward to showing off some of the latest Scope and realtime AI capabilities on the upcoming water cooler chats.
", replyCount: 2, views: 136, likeCount: 12, datePosted: "May 6, 2026", lastActivity: "May 6, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "Pre-Proposal: Network Engineering SPE", href: "https://forum.livepeer.org/t/3240", author: "By honestly_rich (@honestly_rich)", content: "Proposed by: Rich O’Grady (Co-Director, Livepeer Foundation) and Rick Staa (Technical Director, Livepeer Foundation)
Abstract
The Network Engineering SPE is a delegated pool of capital that funds scoped engineering RFPs and retroactive contributor grants, without requiring a standalone on-chain proposal for each initiative. The mission of the SPE is to fund smaller engineering initiatives to make the Livepeer network more observable, performant, and developer-centric. It targets the $2k–$20k range of work that the current SPE process makes too slow to fund. We’ve seen this model work: the Explorer upgrade proved what a vetted contributor with a clear scope and accountable oversight can deliver. This SPE scales that, while exploring a more retroactive model.
Requested duration: 3 month (pilot program) + 2 weeks (retro)
Requested budget: $95,000 USD-equivalent in LPT
The Problem
The Livepeer project needs the ability to execute fast and targeted actions to support users, operators and builders on the network. The current SPE model works well for large, multi-month programmes. It doesn’t work for the $2k–$20k engineering work the network often needs.
The friction is structural:
- A full SPE proposal requires significant time before any work begins
- On-chain vote cycles add weeks of delay — often longer than the work itself
- As AI tooling compresses build cycles, this gap is getting worse, not better
The result: well-supported, clearly-needed work goes unfunded — not because the community doesn’t want it, but because there’s no efficient path to fund it.
This was validated by three public community discussions (March–April 2026) with strong consensus. The Water Cooler on 13 April returned a clear signal: move forward.
The Solution
The aim of this SPE is to build a delegated funding pool with a fast, accountable process which funds critical engineering work fast. This would sit alongside the formal SPE process, which primarily focuses on longer-term (3+ months) initiatives.
This SPE replicates and scales that model across two funding tracks: RFPs dividing up known work and distributing it amongst the community; and retroactive grants funding for work that has already been completed.
Note: Retroactive Grants don’t necessarily go through the Roadmap process.
Eligibility Areas
For the first round of SPE funding, there will be 3 primary focus areas, which are focused on Livepeer’s core stakeholder groups, each with different needs:
Priority 1: [Developers] Developer Portal — The 5-Minute API — Work on the Developer Portal’s critical path: the engineering that takes a developer from docs to first inference call in under five minutes, from any MCP-compatible tool. This includes the Python SDK, BYOC container tooling, payment and auth infrastructure, agentic harness tooling, and any library or scaffolding that removes onboarding friction.
Priority 2: [Delegators] Explorer — Participation & Observability — Work that makes the Explorer a better permissionless participation portal for operators and delegators. This includes staking interfaces, governance participation features, network observability dashboards, and tooling that surfaces real network behaviour to support informed decision-making.
Priority 3: [Orchestrators] Tooling & Infrastructure — Work that helps orchestrators run more reliably, scale capacity, and integrate with the evolving SDK-first architecture. This includes containerisation, orchestration tooling, runtime improvements, go-livepeer contributions, and infrastructure that affects network reliability and operational experience. Note: that this area requires particularly strong community validation before an RFP is promoted
Funding Track 1 — RFPs (~$5k–$20k, 2–8 weeks)
Full proposed process: RFP Process - Network Engineering SPE
Community members post Roadmap Suggestions on the forum, where the suggester drafts initial requirements and deliverables with the community - facilitated by the Livepeer Foundation. After an initial community validation via Discord, the Foundation then publishes a finalised RFP for contributors to apply to, and assigns it to a selected team or contributor within 7 days.
All decisions and disbursements are published with written rationale. Payment is split across three tranches: 25% on signing; 50% on delivery and verification by Review team; and 25% on impact paid at the end of the pilot (in August). Any incomplete work or assessments at the end of the pilot triggers a brief remediation window.
Three Suggestions have already been initially identified and will be scoped with community contributors and then validated by the community to become (or not become) RFPs:
- Roadmap Suggestion 1: Developer Portal & Discoverability platform
- Roadmap Suggestion 2: Improved Explorer as Participation Portal
- Roadmap Suggestion 3: Payment Clearinghouse & Remote Signer
Funding Track 2 — Retroactive Grants (<$5k, retroactive)
Full proposed process: Retro Grants Funding Process - Network Engineering SPE
Build first, then apply. Contributors post a public application on the forum after the work has shipped. The Review Team reviews on a monthly cycle and publishes an approve, partial approve, or decline decision with written rationale. Approved grants are paid in full in a single disbursement.
The primary bar is impact, not completion. Each application must name the problem, who had it, and who is already using the solution. Describe what was built, link to the work, and state the amount requested. Projected usage does not count.
Examples of eligible work and impact:
- OpenRouter integration — 5 developers discovered and integrated with Livepeer via OpenRouter.
- Live video-to-video / BYOC full-stack runner — 3 community members running live video-to-video with BYOC end-to-end — a workflow the network had no viable path for before this.
- Agentic harness tooling — 3 Livepeer solutions cutting time-to-working-agent-loop from days to hours using standardised scripts, tool definitions, and prompts.
Quantifying Impact
Impact means the network becomes more observable, more reliable, or more easy-to-use for Developers, Delegators or Orchestrators. The concrete impact signals that the Review team will look at are all about usage and adoption:
- Named adopter — a specific person or team outside the author is using it in their own work.
- Downstream dependency — another project or contributor is building on top of it.
- Capability confirmed in the wild — someone who wasn’t involved in the build has run it successfully.
It is also expected that the work is maintained and still live by the end of the program. What impact is not: download counts, repo stars, or the builder using their own tool.
What This SPE Isn’t
Not a demand generation fund (coming soon). The Network Engineering SPE funds the engineering substrate: the infrastructure that makes demand solutions like Daydream, Frameworks, Blueclaw, Streamplace possible. Go-to-market, marketing, and end-user services are out of scope.
Not an open-ended bounty pool. Every disbursement requires a verified definition of done. Work must be complete, reviewable, address a recognised need and have verifiable impact.
Replacing the SPE Process. For larger pieces of work network engineering (e.g. 2+ months with multiple contributors), the onchain treasury process will still be used.
SPE Governance Structure
Custody: Funds held by the Livepeer Foundation.
Decision process: All decisions made live in weekly Review Team meetings via a simple 2-of-3 vote, with a written decision log published after each meeting. Any Review Team member with a direct financial interest in a decision must recuse.
| Role | Who | Responsibilities | Paid by SPE? |
|---|---|---|---|
| Review Team Lead & Technical Director | Rick Starr (Livepeer Foundation) | Refines scope of RFPs with Suggester; leads RFP team selection; signs off on technical quality for all RFP Track 1 work - sole gate on technical delivery, no broader Review Team vote required; produces pilot evaluation report | No |
| Reviewer, RFPs | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Reviews and scores RFP applications against evaluation criteria; represents community interests in first-pass scoping; casts an independent vote on Tranche 2 and Tranche 3 payouts; publishes written rationale for any dissent or recusal | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Reviewer, Retro Grants | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Owns first-pass review of retroactive grant applications against the published rubric (supported by AI pre-screening); triages and quality-screens incoming applications; compiles monthly review shortlist; proactively surfaces strong unsubmitted community work; casts an independent vote on retroactive grant approvals | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Roadmap Manager | Rich O’Grady (Livepeer Foundation) | Facilitates community Suggestion sessions; manages the Suggestions pipeline; promotes validated ideas to the roadmap; signals funding path per item | No |
| Program Manager | Mehrdad (Livepeer Foundation) | Runs and records weekly Review Team meetings; maintains the public decision log; tracks milestone status; manages remediation windows | No |
| Contributors | Community | Deliver scoped outputs with full ownership and accountability | Yes |
This SPE will have AI-native workflows embedded from day one, reducing Review Team overhead, keeping the public record current, and ensuring consistent quality control without manual lift.
AI-led tasks include: retro grant pre-screening; automating meeting notes and updates; decision log drafting; application triaging.
Timeline
15 May 2026 — Funding Programs Live
Review Team seated. Weekly cadence established. First 3 RFPs posted publicly. Retroactive grants open. Public tracker live. Key assessment: did we launch on time with the right scope?
30 Jun 2026 — First Deliveries Verified
At least 1 RFP delivered. At least 1 retroactive grant awarded. Key assessment: is the quality bar holding? Is the 14-day selection target being met?
30 Aug 2026 — Pilot Complete
Minimum 3 RFPs delivered, with aspirational goal of 5. All impact assessments done. All spend published. Evaluation report out with a clear recommendation: continue, modify, or stop.
Budget Breakdown
Total requested: $95,000 USD-equivalent (4-month pilot)
| Budget line | Assumption | Amount (USD-equiv.) |
|---|---|---|
| Review Team Member compensation (×2) | 2 × $7,500 / 3 months (~10 hrs/week) | $15,000 |
| Track 1 — RFP pool | Aim: 3 RFPs over pilot at ~$15k average | $45,000 |
| Track 2 — Retroactive Grants pool | Aim: 5 retroactive grants at ~$3k average | $15,000 |
| Funding Buffer — for additional grants or RFP | To either be allocated, returned to the onchain treasury or carried over to future SPE | $20,000 |
| Total | $95,000 (in LPT) |
If uptake for RFPs and/or retroactive grants are lower than expected at the 30 June checkpoint, the Review Team has the opportunity to reallocate between pools based on where community activity is strongest.
Any unspent funds or incomplete RFPs at pilot end are returned to treasury (with a small undefined, remediation window if work near completion).
All amounts sized using the 30-day moving average LPT price at the time of RFP approval.
Deliverables
Pilot success criteria (3 months):
1. Minimum 3 RFPs reach verified impact - At least 3 scoped engineering RFPs complete with a confirmed definition of done, verified by the Technical Director and community Review Team Members. Each delivery is published publicly with a written rationale and outcome assessment.
2. Minimum 5 retroactive grants funded - At least 5 retroactive grant applications reviewed and awarded, covering work that has already shipped and meets the published rubric. Each award is published publicly with written rationale, the amount approved, and the impact evidence submitted by the contributor.
3. Three public SPE updates published during pilot - One per month (June, July, August). Each update covers: RFPs active and delivered, retroactive grants reviewed and awarded, funds disbursed to date, and Review Team decisions with written rationale. Published within 7 days of the monthly Review Team meeting. Zero black-box decisions.
4. Pilot evaluation & impact report published by 30 Aug 2026 - A concise report covering: RFPs funded and delivered, retroactive grants awarded, total spend vs. budget, community signal on delivered work, and a clear recommendation: continue, modify, or stop. Written for a community audience, not an internal one.
Transparency and Accountability
- Every RFP and retroactive grant decision published publicly with written rationale.
- Public tracker RFPs: all RFPs, status, funds allocated and disbursed, Review Team decisions
- Public tracker grants: all retro grant applications, decisions, amounts awarded, and impact evidence
- Review Team Members publish justification for any overrule or recusal
- Monthly written reporting to the community (per SPE norms) plus update at Water Cooler
- All conflicts of interest disclosed and recused
Proposer: FTK Staking
Contact: admin@liveinfraspe.com
ENS: liveinfra.eth
Discord: @ftkuhnsman
Abstract
The LiveInfra SPE requests funding for Q2 2026 to sustain the Community Node service, a free RPC service for the Livepeer community. This proposal covers recurring operational costs for cloud infrastructure, maintenance, and support.
Mission
The LiveInfra SPE is dedicated to empowering the Livepeer community by providing free, reliable blockchain infrastructure services.
Problem and Importance
Livepeer community members depend on accessible blockchain infrastructure to develop decentralized video applications and tools. Operating RPC nodes is costly and complex, and third-party providers charge high fees. The Community Node service delivers free Arbitrum L2 and Ethereum L1 RPC endpoints, removing these barriers.
Rationale
Continued funding for the LiveInfra SPE ensures the Community Node service remains a dependable, cost-free resource for Livepeer builders. Quarterly treasury proposals align with community oversight, minimize market impact on LPT, and allow flexibility to adapt to evolving ecosystem demands.
Current Operations
The LiveInfra SPE provides free Arbitrum L2 and Ethereum L1 RPC endpoints to Livepeer community members (active orchestrators, broadcasters, and delegators with ≥100 LPT staked). It operates with geo-distributed Ethereum L1 nodes (execution and consensus) and Arbitrum Nitro L2 nodes, load-balanced for reliability. A custom proxy layer authenticates user requests via unique URL endpoints, accessible after wallet-based signup. To sign up visit the LiveInfra SPE website and authenticate with your livepeer wallet.
Q2 2026 Operations Plan
This proposal focuses on sustaining service operations for Q2 2026 (April–June). No new features are proposed in the current maintenance period.
Milestones and Timeline
- April–June 2026:
- Maintain to support node operations.
- Perform ongoing maintenance, including software upgrades, node database pruning, and storage expansion as needed.
- Monitor and ensure 99.9% uptime, with transparent reporting via the KPI dashboard.
- Provide community support for RPC service users.
- Ongoing:
- Submit the next quarterly proposal (Q3 2026) to secure continued funding.
Budget Breakdown
The LiveInfra SPE requests $14,000 USD for Q2 2026 to cover recurring operational costs. Funds will be converted to LPT at submission using the current LPT price, with a margin to buffer against price volatility during voting.
- Quarterly Recurring Costs - $14,000
- $9,000 USD - Infrastructure: Quarterly costs for high-quality cloud resources.
- $5,000 USD - Maintenance & Support: Quarterly node upkeep, software upgrades, database pruning, and user support - $2,500 reduction from prior quarter due to improvements in operational efficiency and platform stability.
Total Request USD: $14,000
Total LPT tokens requested: TBD - Determined at submission based on the current LPT price.
Funding Strategy
The LiveInfra SPE will continue submitting quarterly treasury proposals to fund operations, ensuring:
- Minimized Market Impact: Requesting smaller LPT amounts each quarter and selling gradually to reduce price volatility.
- Community Oversight: Quarterly proposals allow the Livepeer community to assess the service’s performance and value, approving continued funding or requesting adjustments as needed.
This approach ensures transparency, sustainability, and alignment with community priorities.
Community Feedback and Suggestions
The LiveInfra SPE values input from the Livepeer community to ensure the RPC Service continues to meet ecosystem needs. We invite community members to suggest enhancements, new features, or additional infrastructure offerings during the pre-proposal review process. Please share your ideas directly in the Livepeer forum as part of the discussion for this proposal. Your feedback will help shape future proposals and ensure the service evolves to support the community’s goals.
", replyCount: 1, views: 55, likeCount: 4, datePosted: "Apr 21, 2026", lastActivity: "Apr 24, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "WEAVE Growth SPE: Updates", href: "https://forum.livepeer.org/t/3239", author: "By DeFine (@DeFine)", content: "Hey everyone,
Wanted to share some updates on WEAVE as we get into Month 1 execution. There’s a team change, a budget adjustment, and some governance work happening.
SPE Naming
To align SPE naming with mission objectives, the WEAVE proposal deliverables are being operated now under WEAVE Growth SPE. Embody SPE stays its own thing, focused on embodied agent workloads. The broader roadmap lives under WEAVE Growth SPE.
Team Structure Updates
Dane decided to move on from WEAVE for personal reasons, and we parted on good terms.
Dane built the Unreal Engine avatars and most of the game UI that powered our PixelStreaming workloads. He was dedicated, hardworking, and consistently showed up when it counted. He overdelivered on his initial Embody deliverables and brought the game to a mature, production-ready state. The game builds he produced are what the Embody workloads ran on. We’re genuinely grateful for his contribution and wish him all the best going forward.
On the IP side, Dane has committed to granting the WEAVE Growth SPE entity a perpetual, royalty-free license to the source code with sub-licensing rights, allowing us to use, modify, and sublicense it as needed. The source can’t be MIT because of third-party plugin restrictions, but the license covers us fully. The packaged game goes MIT, same as all future Embody releases. We will follow up with Dane on the necessary actions and paperwork to make sure this is properly finalized. This development makes sure that the source code will become an other asset for the growth of Livepeer and ensures that Dane’s departure does not compromise our ability to create future workloads using Unreal Engine.
Budget
We will discuss actively with the community to make sure that the SPE acts according to stakeholder intent to decide what will happen to the funds that where earmarked towards Dane’s compensation.
Governance and transparency
We are currently discussing with the team the creation of a lightweight legal entity with non-profit operating provisions, where financial reporting and management obligations would be written into the founding documents themselves. The entity will operate with strict non profit provisions for the benefit of the whole Livepeer ecosystem and will possess ownership of the financial(incentives) and IP assets(unreal engine game, weave website, etc..) of the SPE.
What that looks like: budget, spending, and compensation reported publicly. Governance processes published online, how decisions get made, how workloads get evaluated, how incentive packets get managed. All incentive programs will run in the open with published criteria, schedules, and outcomes.
We’re still working out the exact structure, reporting format, and cadence with the team. Once that’s decided, we’ll share it publicly.
Month 1 Deliverables
You can find the month 1 deliverables spec bellow, we are currently finalizing this before posting the final version. Any feedback welcome.
Deliverables spec doc
WEAVE Growth SPE — Month 1 Deliverables
Version: v0.2 (April 2026)
Owner: DeFine
Technical Reviewer: Rick
Completion Rule: No deliverable is complete until Rick signs off on its evidence pack.
Month 1 Operating Logic
The dependency chain is:
- M1-D1 builds the open-source WEAVE Tool.
- M1-D2 exposes that capability through the DAO-operated hosted WEAVE App + API.
- M1-D3 activates the incentive loop that drives workflow creation and app creation.
- M1-D4 proves publicly what users did, what converted, and what became monetization-ready.
Month 1 completion is based on whether this machine exists, is live, and is measurable. Raw demand volume is a KPI outcome, not the sole approval condition.
M1-D1 — Open-source WEAVE Tool
Description: A public, open-source, self-hostable WEAVE Tool that lets any technical user create Scope .json workflows, run viability research, run QA, and extend the system independently. This is the core product layer, not the hosted WEAVE service.
Outcome: By end of Month 1, a technical user can take the WEAVE Tool repo, follow the docs, generate valid workflows, inspect viability + QA outputs, and adapt the tool for their own API or webapp if they choose.
Excludes: Hosted uptime, DAO-run API reliability, user onboarding/account systems, and incentive logic.
Sub-deliverables
M1-D1.1 — Public repo and licensing live
| Criteria | Done? |
|---|---|
| Repo is public | |
| License file is present | |
| README covers setup, architecture, usage, and extension points | |
| Example assets or example outputs are included or linked |
Evidence: Public repo URL, license file, README, architecture note.
M1-D1.2 — Workflow creation engine works
| Criteria | Done? |
|---|---|
Tool can generate valid Scope .json workflows | |
| At least 3 materially distinct workload classes are supported | |
| Each class has a reproducible example output | |
| Export path for generated workflows is documented |
Evidence: 3 exported .json outputs, supported workload list, reproduction notes.
M1-D1.3 — Commercial viability module integrated
| Criteria | Done? |
|---|---|
| Workflow creation includes an explicit viability-assessment step | |
| Viability output is generated inside the tool | |
| Output includes target user, use case, monetization path, market rationale, and build/no-build reasoning | |
| Viability output is saved or exportable alongside the workflow artifact |
Evidence: UI or CLI artifact showing the viability step, 3 example analyses, output schema.
M1-D1.4 — QA module integrated
| Criteria | Done? |
|---|---|
| QA stage exists inside the tool flow | |
| QA returns pass/fail or a structured issue list | |
Checks cover valid .json structure, required fields, runnable shape, and broken-config detection | |
| At least 1 failed QA case is demonstrated |
Evidence: QA checklist/spec, pass artifacts, fail artifact, output examples.
M1-D1.5 — Self-hostability proven
| Criteria | Done? |
|---|---|
| Fresh setup can be completed from the published docs | |
| Tool runs without requiring the hosted WEAVE App/API | |
| A technical user can extend or wrap the tool for their own API or webapp | |
| No WEAVE-managed account is required to use the core tool |
Evidence: Self-host setup note, fresh-run proof, extension or wrapping example.
Evidence Pack for Rick Review
- Public repo URL
- License file
- README + architecture note
- 3 sample workflow outputs
- 3 viability outputs
- QA pass/fail artifacts
- Self-host proof
M1-D2 — Hosted WEAVE App + API Access Layer
Description: The DAO-operated, free hosted access layer for WEAVE. This is the managed WEAVE App and public API that use the WEAVE Tool underneath so users can access WEAVE services without self-hosting.
Outcome: By end of Month 1, a user can complete the workflow-creation path through the hosted WEAVE App or API, view viability + QA outputs, and move from workflow creation into app creation without local deployment.
Excludes: Open-source licensing proof for the core tool, standalone self-host proof, and incentive policy itself.
Sub-deliverables
M1-D2.1 — Free hosted WEAVE webapp live
| Criteria | Done? |
|---|---|
| Public URL loads successfully | |
| User can complete workflow creation end-to-end through the webapp | |
| Viability and QA outputs are visible in the hosted flow | |
| Workflow output is viewable and exportable |
Evidence: Public URL, screenshots, end-to-end web demo recording.
M1-D2.2 — Public API live
| Criteria | Done? |
|---|---|
| API endpoint(s) are publicly reachable | |
| API docs are published | |
| Workflow creation, viability, and QA are available via API | |
| At least 1 successful API-created workflow is demonstrated |
Evidence: API base URL, API docs, example request/response, API demo artifact.
M1-D2.3 — Hosted surface is clearly downstream of D1
| Criteria | Done? |
|---|---|
| Hosted outputs use the same core workflow format as the WEAVE Tool | |
| Relationship between D1 and D2 is documented publicly | |
| Hosted access policy is stated | |
| Free access terms or limits are stated |
Evidence: Public note on tool vs hosted surface, access policy doc, parity note.
M1-D2.4 — Workflow-to-app creation path live
| Criteria | Done? |
|---|---|
| User can move from workflow creation into an app-creation path through the hosted surface | |
| This path is exposed in the webapp and documented in the API flow | |
| At least 1 example app-creation flow is demonstrated | |
| Output from this step can be used in the incentive system |
Evidence: App-creation demo, UI/API docs, example artifact.
M1-D2.5 — No-self-hosting path demonstrated
| Criteria | Done? |
|---|---|
| A user can complete the hosted flow without local deployment | |
| A web-based end-to-end demo exists | |
| An API-based end-to-end demo exists | |
| The hosted path is usable by a non-technical participant |
Evidence: Web demo, API demo, hosted-path walkthrough.
Evidence Pack for Rick Review
- Public webapp URL
- Public API docs URL
- Tool-to-hosted parity note
- Web demo recording
- API demo recording
- Example workflow artifact
- Example app-creation artifact
M1-D3 — Incentive Program Launch
Description: The live WEAVE incentive system that moves users from registration to workflow creation to app creation, with identity-gated enrollment to reduce bot/sybil spam. Phase 1 rewards support workflow and app creation. Phase 2 rewards unlock only after an app proves quality, monetization, and electronic payment readiness.
Outcome: By end of Month 1, incentive registration is live, users can enroll from both the WEAVE Tool and the WEAVE App, Phase 1 rewards are active, and the Phase 2 unlock rules are explicit and operational.
Sub-deliverables
M1-D3.1 — Incentive rules and governance published
| Criteria | Done? |
|---|---|
| Public incentive rules document exists | |
| Phase 1 and Phase 2 are defined separately | |
| Participant types and eligible actions are defined | |
| Calculation method and cadence are defined | |
| Dispute and exception handling path is defined |
Evidence: Public rules URL, version/date, example calculation, dispute policy.
M1-D3.2 — Worldcoin-gated registration live
| Criteria | Done? |
|---|---|
| Incentive enrollment path is live | |
| Worldcoin verification is required before incentive participation | |
| Anti-spam / anti-sybil rules are published | |
| At least 1 successful registration is evidenced |
Evidence: Enrollment URL, verification screenshots, policy note, first successful registration artifact.
M1-D3.3 — Dual onboarding paths live
| Criteria | Done? |
|---|---|
| User can enter the incentive system from the WEAVE Tool path | |
| User can enter the incentive system from the hosted WEAVE App path | |
| Differences between self-hosted and hosted participants are documented | |
| Both paths feed the same KPI/reporting surface |
Evidence: Tool-path walkthrough, app-path walkthrough, onboarding documentation.
M1-D3.4 — Phase 1 rewards active
| Criteria | Done? |
|---|---|
| Phase 1 rewards are live during Month 1 | |
| Workflow creation is a qualifying action | |
| App creation is a qualifying action | |
| Incentive window and cadence are publicly stated |
Evidence: Launch announcement, rules excerpt, active incentive window proof.
M1-D3.5 — Phase 2 activation gate defined and testable
| Criteria | Done? |
|---|---|
| Phase 2 activation criteria are published | |
| Criteria require proof of quality standards | |
| Criteria require proof of monetization | |
| Criteria require ability to accept electronic payments | |
| A qualifying evidence template or checklist exists |
Evidence: Phase 2 rules section, qualification checklist, sample evidence packet.
M1-D3.6 — First live cycle operational
| Criteria | Done? |
|---|---|
| Weekly calculation or review runbook exists | |
| First cycle calculation artifact is produced | |
| At least 1 real participant moved through registration → action → calculation | |
| Exception/dispute handling is usable |
Evidence: Runbook, first cycle artifact, participant flow proof, exception log template.
Evidence Pack for Rick Review
- Public incentive rules URL
- Worldcoin-gated registration proof
- Tool-path and app-path onboarding proofs
- Phase 1 live-window proof
- Phase 2 qualification checklist
- Weekly runbook
- First cycle calculation artifact
M1-D4 — Public KPI / Reporting Surface
Description: The public reporting layer that shows whether WEAVE is actually acquiring users, helping them create workflows, converting those workflows into apps, and moving those apps toward quality and monetization readiness.
Outcome: By end of Month 1, the public can verify acquisition, production, quality, monetization-readiness, and workflow-to-app stickiness from a live KPI/reporting surface.
Sub-deliverables
M1-D4.1 — Public KPI surface live
| Criteria | Done? |
|---|---|
| Public URL exists | |
| Metric definitions are visible | |
| Update cadence is stated | |
| Current snapshot is visible |
Evidence: Public dashboard/report URL, screenshots, metric definitions.
M1-D4.2 — Acquisition metrics live
| Criteria | Done? |
|---|---|
| New users are counted publicly | |
| Incentive-verified registrations are counted publicly | |
| Tool-path vs app-path acquisition can be distinguished or derived | |
| Reporting window is stated |
Evidence: KPI surface screenshot, acquisition methodology note.
M1-D4.3 — Production and completion metrics live
| Criteria | Done? |
|---|---|
| Workflows started are counted publicly | |
| Workflows completed are counted publicly | |
| Incentive completions are counted publicly | |
| Apps created are counted publicly |
Evidence: KPI surface screenshot, metric definitions, sample snapshot.
M1-D4.4 — Quality and monetization progression metrics live
| Criteria | Done? |
|---|---|
| Apps crossing the quality threshold are counted publicly | |
| Apps that are monetization-ready are counted publicly | |
| Apps that can accept electronic payments are counted publicly | |
| Phase 2-eligible apps are counted publicly |
Evidence: KPI surface screenshot, methodology note, status definitions.
M1-D4.5 — Stickiness / progression metrics live
| Criteria | Done? |
|---|---|
| Workflow-to-app conversion metric is defined | |
| Post-action stickiness metric is defined | |
| Repeat builder activity or return behavior metric is defined | |
| Measurement window and method are published |
Evidence: KPI definitions, methodology note, example snapshot.
M1-D4.6 — Public reporting artifacts published
| Criteria | Done? |
|---|---|
| Weekly report template exists | |
| First public KPI snapshot/report is published | |
| Caveats and methodology are published | |
| Reporting owner/update cadence is named |
Evidence: Report template, first snapshot/report, methodology doc.
Evidence Pack for Rick Review
- Public KPI/dashboard URL
- Metric definitions
- Acquisition, production, and conversion screenshots
- First public report or snapshot
- Methodology / caveat note
Month 1 KPI Targets
These are operating targets, not the sole completion gate. Month 1 approval depends first on whether the system is live, reviewable, and measurable.
| KPI | Month 1 Target |
|---|---|
| New verified incentive users | 10+ |
| Workflows started | 10+ |
| Workflows completed | 5+ |
| Apps created | 3+ |
| Phase 1 incentive completions | 3+ |
| Apps reaching quality review | 1+ |
| Apps reaching monetization readiness | 1+ |
| Workflow-to-app stickiness | 25%+ of workflow completers start an app path |
| Public KPI snapshots/reports published | 1+ live snapshot and weekly cadence defined |
Rick Review Gate
Rick signs off separately on each deliverable:
- M1-D1 technical completeness of the open-source WEAVE Tool
- M1-D2 hosted operability of the WEAVE App + API
- M1-D3 correctness and operability of the incentive mechanism
- M1-D4 correctness and integrity of the public KPI/reporting surface
| Deliverable | Evidence Submitted | Rick Status | Final |
|---|---|---|---|
| M1-D1 Open-source WEAVE Tool | |||
| M1-D2 Hosted WEAVE App + API | |||
| M1-D3 Incentive Program Launch | |||
| M1-D4 Public KPI / Reporting Surface |
Activating the Livepeer Ecosystem Roadmap — What’s Changing and How to Get Involved
The Ecosystem roadmap at roadmap.livepeer.org has never fully satisfied us. It’s basically been a display board rather than a genuine two-way system between the Contributors, Foundation and the broader community.
We’re now fixing that. I’ll explain what’s changing and what we need from everyone in the ecosystem.
What the Roadmap Is For
The roadmap exists to make ecosystem direction visible, coherent, and participatory.
It is not a promise or a project plan. It is a shared and evolving view of where the network is headed. This includes projects being worked on, who is driving them, and where there are opportunities to pick things up or get involved.
Every item on the roadmap defines a problem, a desired outcome, and who owns it. Items previously came from only two sources:
-
Advisory Board Recommendations — captured from the project with domain experts last year
-
Foundation Priorities — strategic improvements identified and funded by the Foundation
And, excitedly we now introduce a third way for things to enter the roadmap:
- Community Suggestions — ideas submitted and validated through our community process
In this way, the Roadmap becomes further signalling for the things people want to see come to the network, and a way for everyone to put forward impactful projects and provide upvotes are genuine input signals — not performative ones — towards what gets prioritised.
Why a Community Intake Process Matters
Until now, there has been no clear path for a community member to propose something and see it taken seriously without testing it with a formal forum post or completing an SPE proposal. A lot of great suggestions and discussions were had in Discord or raised on Watercooler’s, but with no structured process, no feedback loop, and no progress, many were lost.
That’s a problem for two reasons. First, the ecosystem has real expertise distributed across contributors, orchestrators, builders, and delegators. Some of the best ideas about what Livepeer needs to build next will come from people outside Inc and the Foundation. Second, without a visible process, community participation in the roadmap is essentially performative and people have no reason to engage if engagement doesn’t lead anywhere.
A real intake process changes that. It creates accountability on both sides: the community commits to submitting well-formed proposals and raising the standard of what we want to see from suggestions, and the Foundation commits to reviewing them, providing a space and rituals for them to see further discussion, and publishing those discussions and any decisions to help advance items in ways that make sense.
The New Community Suggestions Process
Anyone in the Livepeer ecosystem can now propose a roadmap item at any time. Here’s how it works:
Step 1 — Submit a proposal
Go to roadmap.livepeer.org and click “Suggest an Item” (in future you will be able to simply type /featurebase directly in Discord). A good proposal answers three things: What is the problem? Why does it matter for the ecosystem? What does success look like?
I’ve included two project “proposals” that were recommended as part of the discussions on the emissions system which can act as helpful examples and jumpstart the monthly call:
Step 2 — Community upvoting (ongoing)
All proposals are publicly visible in the roadmap with the tag “Propose Ecosystem Project”. Upvote and comment on proposals you care about at any time. Momentum is tracked — strong community support between monthly cycles can fast-track a proposal into the next review.
Step 3 — Foundation weekly review
We will aim to review the proposal queue every week and provide some feedback about how to prepare for the monthly Discord call. The aim here is to get things well prepared and to knock out early things that are maybe not going to reach a bar that we all feel is needed for high quality suggestions.
Step 4 — Monthly Discord call
Once a month proposals are presented on a community Discord call (if not the Watercooler, another forum). We’ll make a quick intro for each including upvotes and comments, the Proposer can give a short discussion, and then community asks questions and discusses live. After the call, the Foundation will publish key information and based on sentiment aim to reach a decision that can be shared: Promoted to Roadmap, Held for Next Cycle, or Declined with a public explanation.
Proposals that are promoted join the roadmap with status Under Review and from there move forward to planning - most likely as an RFP, a SPE Proposal, or some other mechanism that makes sense (more on this to come).
How to Use the Roadmap
The roadmap will work best when the community is actively engaged. We’ll start to talk about it more effectively on the Watercooler. But here’s what we need from you:
Upvote items you care about. This does two things: it signals priorities to the item owners, and it subscribes you to all future updates on that item. When an item’s status changes, you’ll be notified automatically. Your upvote has a visible consequence.
Comment on items. Share context, ask questions, flag concerns, or offer to contribute. Comments are read by item owners and the Foundation. Good comments surface edge cases and use cases that owners may not have considered. Good feedback here can shut things down before wasting everyones time, but also can give the right spark for a simple idea to be a gamechanger!
Follow the changelog at roadmap.livepeer.org/changelog. Every major milestone on a roadmap item generates a changelog entry. This is the progress reporting mechanism for the ecosystem — if you want to know what’s actually shipping, the changelog is where to look.
Propose new items if you think something important is missing. The bar for submitting is low — a clear problem statement, the reason is matters, and what the future looks like if that proposed item becomes a success. The intake process can take it from there. Items might make it to the roadmap, or be bundled or merged with others “under” an SPE.
For teams shipping roadmap items: update your item’s status when it changes (this auto-notifies everyone who upvoted), and post a changelog entry at each major milestone. The changelog is your public progress report — it replaces ad hoc updates scattered across Discord and forum threads.
A Note on What This Is Not
This is not a governance mechanism. In time this can become a good funnel for the onchain treasury but for now we want this to become a way to surface useful recommendations and priorities and created a clearer, more participatory and better recorded feedback loop. The proposed items and upvotes are strong input signals — not binding votes. This is intentional: it keeps the roadmap strategically coherent while ensuring community voice is genuinely considered and visibly acted upon.
If a proposal is declined, people will know why. Transparency is a key part of this commitment. And people can always still take things to a vote onchain.. this just raises the bar for proposing something if it’s already been tested with the community in this way
Get Started
The roadmap is already live at roadmap.livepeer.org. The suggestions board is open now.
If you’ve had something in mind that Livepeer shoud be building or capitalising on, now is a great time to share it. We will run the first Monthly call at the end of Mark. And if you have questions or feedback just drop them in here.
", replyCount: 0, views: 67, likeCount: 3, datePosted: "Mar 9, 2026", lastActivity: "Mar 9, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "AI capability discovery", href: "https://forum.livepeer.org/t/3233", author: "By chrishobcroft (@chrishobcroft)", content: "Can someone help me learn how to reliably query which AI capabilities and models the network offers?
I’m running a gateway on localhost with 0.065 deposit and 0.03 reserve. I’m managing to get some text-to-image jobs through, which is a great start.
Ideally it would be great to be able to query:
- all available job types,
- which models are available,
- what the O’s pricing is.
It seems like an obvious thing from my limited perspective, that an O will advertise its services to a G.
Any clues?
", replyCount: 0, views: 35, likeCount: 2, datePosted: "Mar 7, 2026", lastActivity: "Mar 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "Embody SPE: Pre-proposal Intelligent Public Pipelines", href: "https://forum.livepeer.org/t/3220", author: "By DeFine (@DeFine)", content: "Pre-proposal v5: WEAVE
Authors: DeFine (Strategy & Engineering), Dane (Virtual Worlds & Avatars)Date: March 15, 2026
1. Abstract
The Embody SPE is an entity dedicated to bringing embodied avatar workloads into the Livepeer ecosystem. Since our inception, we have continuously evolved our technology to meet the needs of the network. Our core drive is to deliver sustained fee growth for Livepeer orchestrators.
Along our journey, we have developed solutions and frameworks that address Livepeer’s core bottleneck: the workload lifecycle. Embody seeks funding to develop and prove these solutions, and to expand them into an open-source public-good toolset fit for every existing and upcoming workload deployed on Livepeer.
2. The Problem
To understand the problem, one must recognize three fundamental actors within the Livepeer ecosystem:
-
Orchestrators, who provide compute for workloads.
-
Workload Facilitators, who engineer and maintain the workloads that orchestrators run.
-
Consumers, who utilize these workloads and generate demand.
The Livepeer network provides adequate tokenomic incentives for orchestrators. However, workload facilitator and consumer incentives are currently funded in a non-standardized way by the Livepeer treasury, with limited success so far. In supply and demand terms, compute suppliers vastly outnumber both demand seekers and demand creators.
Workload facilitators generally fall into two subcategories: startups seeking capital to pay for compute and build a consumer base, and established organizations that already possess compute capital and consumers. Livepeer is attractive to both because orchestrators are incentivized through token inflation to offer compute below standard market costs. Theoretically, workload facilitators should be able to offer better prices to their consumers by selecting Livepeer orchestrators.
Despite this advantage, creating workloads within the Livepeer ecosystem remains exceedingly difficult due to the following barriers:
The Technical and Conceptual Barrier Workload facilitators must deeply understand the Livepeer ecosystem technically and conceptually. Furthermore, manually executing every step of a workload’s lifecycle and managing the handoff to the next stage requires an immense amount of time and effort. This creates an exceptionally high barrier to entry, practically excluding non-technical participants from the creation process.
The Economic and Incentive Barrier Economic incentives for workload creation are virtually non-existent by default. Startups rely on the treasury to incentivize their work. Even if a team possesses the technical capability to deliver workloads, they must invest significant time navigating the community and preparing proposals, hoping for treasury approval. For established organizations, there is no incentive to risk service downtime and consumer dissatisfaction by migrating from centralized providers to Livepeer. To date, there are zero documented successful cases of such organizations making the swap.
The Distribution and Interface Barrier Once a workload is live, startups without established consumer bases face the monumental task of building consumer interfaces and executing outreach. Such organizations typically have low headcounts. The added overhead of maintaining Livepeer-specific infrastructure, building interfaces, and distributing workloads is enough to make Livepeer unattractive, especially given the generous inference subsidies offered by centralized providers.
This culmination of friction leads to a critical question: How can we radically reduce the time it takes to convert intent into workload creation and distribution?
3. The Solution
To resolve this bottleneck, we propose WEAVE; an open-source, semi-autonomous agentic orchestration tool with a human-in-the-loop design. WEAVE is designed to turn stakeholder intent into researched, engineered, tested, maintained, and distributed workloads, compressing the lifecycle from months to mere hours.
WEAVE will be accessible to everyone, resolving lifecycle bottlenecks from initial research to consumer distribution. It allows workload facilitators to create new GPU-powered workloads and rapidly deploy them to orchestrators and consumers.
The human operator’s role is simplified: they prompt the initial intent, review the output at the end of each lifecycle stage, and authorize the agent to proceed to the next step. Embody will develop and provide the first WEAVE workloads, managing consumer and orchestrator incentives to power our own and future WEAVE users.
How WEAVE Solves Each Stage
WEAVE directly addresses each stage of the workload lifecycle:
Research Lifecycle agents help identify promising workloads, synthesize demand, evaluate tooling and feasibility signals, and prepare proposals for Livepeer stakeholder review.
Engineering and Maintenance Lifecycle agents turn approved intent into implemented workloads, updates, fixes, and ongoing maintenance work inside bounded environments.
QA Lifecycle agents validate workloads, catch regressions, and prepare them for release through a repeatable testing path.
Consumer Interface The public entry point is a published SKILL.md—a markdown contract that instructs consumers on how to start, control, and end the workload through a mediated public control surface.
Orchestrator Release Lifecycle agents package workloads, document release requirements, and move them through a clear operator onboarding and rollout path.
Consumer Distribution Lifecycle agents support the distribution work needed to reach consumers, drive adoption, and keep the workload legible as a public interface rather than an obscure private implementation.
From Intent to Live Workload
WEAVE provides a clear path from initial intent to live network execution:
-
Intent Submission: A user submits a workload intent. This can propose a new workload, request an improvement, or point the pipeline toward a concrete opportunity (e.g., real-time camera tracking).
-
Lifecycle Execution: Agents pick up the intent and move it through research, engineering, QA, release preparation, and distribution.
-
Stage Review and Authorization: At the end of each stage, agents publish artifacts and request human review. Agents carry the workflow forward, but human authorization is strictly required to complete a stage.
-
Runtime Release and Distribution: When release-ready, WEAVE distributes the workload to the orchestrator registry. Operators can adopt it through a bounded action. The system simultaneously publishes the consumer-facing
SKILL.mdand begins distribution outreach.
For orchestrators, this creates a faster path to new fee-generating workloads and lowers integration friction.
Economic Incentives
WEAVE resolves the time constraints and technical barriers, but this only solves part of the problem. The other half is the absence of economic incentives for workload facilitators and consumers. Similarly, orchestrators typically do not run workloads for free out of goodwill; there must be clear incentives for them to support WEAVE workloads. To address this, we propose three perpetual financial packets:
1. Workload Facilitator Hackathon Packet A perpetual hackathon powered by an LPT economic packet, where a portion of the accrued inflation value is used to incentivize the weekly creation of new workloads. The remaining value is fed back into the principal, allowing it to compound continuously so that token rewards grow over time. The shape of the hackathon and its economic parameters will be subject to ongoing refinement by the multisig participants. Participants will engage through a SKILL.md contract, and funding will be distributed retroactively upon the completion of intended targets. This creates an asymmetric upside: participants are incentivized with an initial allocation, and upon delivering a high-demand workload, they receive retroactive funding along with the ability to deploy applications on top of the workload.
2. Consumer Incentive PacketThis perpetual financial packet operates similarly to the facilitator packet, utilizing weekly accrued inflation to incentivize consumers of WEAVE workloads to take specific actions. For example, SKILL.md consumer agents holding a blockchain wallet could be eligible for rewards if they deliver a working open-source companion application that reaches five concurrent daily users. Like the facilitator packet, this is designed with an asymmetric risk/reward model: the consumer uses the workload without charge and receives a small initial incentive (subject to terms), while the upside includes retroactive rewards and the ability to profit from an application built on WEAVE’s incentive layer.
3. Orchestrator Incentive PacketAn economic packet dedicated to providing weekly rewards for orchestrators who run WEAVE workloads on their hardware systems, ensuring consistent compute availability and sustained network participation.
4. Where We Are Today
WEAVE is being proposed on top of assets the Embody team already operates: a mature Embody workload, an orchestrator rollout lane, and a working consumer entry point.
-
embody-skill: The published skill-contract path for the workload interface, providing a working consumer-distribution surface.
-
livepeer-ops: The control-plane layer for sessions, policy, and orchestrator allocation.
-
Unreal_Vtuber: The runtime environment for the embodied avatar workload.
-
Registered Orchestrators: 13+ orchestrators have registered to the pipeline and received workloads; seven are currently active, and prior participants can reenter.
-
Rollout Capability: The active lane can already receive auto-updates through the Unreal_Vtuber path.
Together, these assets provide the execution base for the proposal: a mature workload, an existing operator lane, and functioning distribution tooling on which WEAVE can be built, tested, and released.
5. What We Are Delivering (4-Month Scope)
The roadmap advances in three stages: first, deploy Embody as the inaugural workload on WEAVE; second, extend WEAVE to host daydream/scope; third, generalize WEAVE beyond both to support any realtime application, establishing it as a true open-source public good for the Livepeer ecosystem.
The perpetual financial packets are foundational to this progression. All three launch alongside the Embody workload in Month 1, ensuring that workload facilitator and consumer incentives are active from the start and that orchestrator expenses are covered from day one.
Month 1 — Embody Workload, Lifecycle Automation & Incentives Launch
DeFine
Deliverables
-
Establish the first bounded lifecycle-agent runtime.
-
Automate research, engineering, maintenance, and QA flows on the Embody (non game-dependent) proving lane.
-
Release Embody as the first working WEAVE workload, accessible via
SKILL.mdand processing sessions on at least one active orchestrator. -
Deploy all three perpetual incentive packets (Workload Facilitator Hackathon, Consumer, and Orchestrator).
Success Criteria
-
Lifecycle agent runtime operational and processing intents end-to-end on the Embody lane.
-
Embody workload live and accessible via
SKILL.md, processing sessions on at least one active orchestrator. -
All three incentive packets deployed and accepting participants.
-
At least 3 orchestrators enrolled in the WEAVE lane.
Dane
Deliverables
- Automate the Embody/Unreal Engine workload engineering pipeline through DeFine’s agent runtime: plugin automation, adding and removing code and features, and game packaging — covering ≥80% of the engineering workflow end-to-end.
Success Criteria
- Agent runtime can execute Unreal Engine engineering tasks end-to-end (plugin add/remove, code changes, game packaging) with ≥80% workflow coverage.
Month 2 — Daydream/Scope Workload Path
DeFine
Deliverables
-
Adapt WEAVE end to end to accept daydream/scope workloads.
-
Bring the orchestrator rollout path online for daydream/scope workloads.
-
Support the first new community workload generated from the Month 1 Hackathon.
Success Criteria
-
WEAVE adapted end to end for daydream/scope workloads.
-
Orchestrator rollout path operational for daydream/scope workloads.
-
First community hackathon workload supported end-to-end.
Dane
Deliverables
- Deliver a functional prototype of the alternative (non-Unreal Engine) embodied avatar workload demonstrating core session flow.
Success Criteria
- Alternative avatar workload prototype operational and demonstrating end-to-end session handling.
Month 3 — Generalized Path & Alternative Avatar Pipeline
DeFine
Deliverables
-
Expand WEAVE from scope and daydream to support custom-lane workloads built on any framework or technology stack, including those outside the Embody and daydream/scope ecosystem.
-
Package Dane’s alternative embodied avatar workload into WEAVE.
-
Open WEAVE to public orchestrator onboarding.
-
Publish the supported workflow for releasing and maintaining additional workloads through WEAVE.
Success Criteria
-
WEAVE custom lane operational and accepting at least one workload built on a framework outside Embody and daydream/scope.
-
Dane’s alternative workload packaged and accessible through WEAVE.
-
At least one external orchestrator onboarded through the public path.
-
Supported workflow for releasing additional workloads documented and tested.
Dane
Deliverables
-
Deliver the alternative (non-Unreal Engine) avatar pipeline, fully operational and documented, ready for DeFine to integrate and automate.
-
Deploy the ability to add and edit new avatars and game environments in both the Unreal Engine and the alternative avatar pipeline.
Success Criteria
-
Alternative avatar pipeline operational, documented, and handed off to DeFine for WEAVE integration.
-
Avatar and environment creation and editing operational in both pipelines, with at least one new avatar or environment demonstrably added through the system on each pipeline.
Month 4 — Governance and Handover
DeFine
Deliverables
-
Facilitate a public governance discussion with multisig participants and the community on how the incentive packets and lifecycle-agent runtime should be managed post-grant.
-
Strategize and document the operating model for the three perpetual incentive packets going forward — how they will run, who will manage them, and what community input shapes their parameters. This decision passes through the community.
-
Document the agreed governance path: multisig participants may elect to transition to a decentralized on-chain layer, continue multisig management until a decentralized solution is ready, or confirm another path agreed upon by the group.
-
Resolve all pending bugs submitted against WEAVE during the grant period.
-
Publish handover documentation and a residual-risk list regardless of the governance decision.
Success Criteria
-
Governance discussion held and outcome documented publicly.
-
Incentive operating model documented and ratified by community input.
-
One of the following governance paths confirmed and recorded: (a) decentralized governance contracts deployed and management transitioned, or (b) a clear continuation plan agreed upon by multisig participants with an explicit path toward eventual decentralization.
-
All flagged WEAVE bugs resolved or, where blocked by external dependency, documented with root cause and mitigation plan.
-
Handover documentation and residual-risk list published.
Dane
Deliverables
- Resolve all bugs flagged across both pipelines during the grant period (Months 1–3).
Success Criteria
- All flagged bugs resolved or, where resolution is blocked by external dependency, documented with root cause and mitigation plan.
Each monthly tranche is released independently via 3/5 multisig upon confirmation of that month’s criteria — DeFine: $4,000 per month, Dane: $6,000 per month. Month 4 payments for both tracks are advanced upon Month 3 confirmation, with final deliverables confirming grant completion. A delay or gap in one track does not block the other.
6. Budget & Financial Governance
The total amount requested from the on-chain treasury is $100,000 USD, equal to 43,478 LPT at an LPT reference price of $2.30 on March 15, 2026.
Budget Breakdown
-
Team Compensation: 17,391 LPT / $40,000 total.
-
DeFine: $16,000 total ($4,000/month). Strategy, control plane, WEAVE engineering, and governance/runtime delivery.
-
Dane: $24,000 total ($6,000/month). Embodied avatar workload engineering across Unreal Engine and non-Unreal runtime paths.
-
Release mechanism: Each monthly tranche is held in the multisig and released only after the month’s work is complete and its success criteria have been met. Release requires 3/5 multisig confirmation. Each track is independently verified and independently released — a delay in one does not block the other.
-
-
Operational Costs: 4,348 LPT / $10,000. Infrastructure, runtime, measurement, and support costs for the proving workload during the grant window.
- Release mechanism: Funds are released against submitted receipts as expenses are incurred. No advance disbursement; each release requires documentation of the corresponding expense.
-
Network Incentives: 13,043 LPT / $30,000. Principal for the Orchestrator Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participating orchestrators according to the published incentive rules.
-
Workload Facilitator Incentives: 4,348 LPT / $10,000. Principal for the Workload Facilitator Hackathon Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participants who meet the published hackathon criteria.
-
Consumer Hackathon: 4,348 LPT / $10,000. Principal for the Consumer Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to consumers who meet the published incentive terms.
Total: 43,478 LPT / $100,000.
The grant will be managed on Arbitrum through a proposal-facing multisig, incorporating comprehensive receipt spend tracking and structured spending categories.
Multisig Composition
-
Orchestrator Tiebreaker: One signer - Pon.
-
Embody Team: Two signers.
-
Foundation: Two signers, including Rick, the Foundation’s head engineer.
Treasury actions will proceed through a 3/5 signature scheme path. If funds need to be returned, the remaining balance can be converted to LPT and sent back to the Livepeer treasury through the governance process described in the separate wallet governance packet.
7. Addressing Past Feedback
We want to thank the Livepeer stakeholders who gave feedback on earlier versions of this pre-proposal. That feedback improved the proposal materially by surfacing three important issues: the security boundary needed to be clearer, the scope was too abstract, and the budget needed to match the size of the work more credibly.
This revision responds directly to those points. It narrows the first workload claim, explicitly defines the system as an open-source tool rather than a decentralized protocol, makes the public consumer path and governance shape more legible, and ties the four-month ask to reviewable milestone outputs. During the core engineering period, the team will remain responsive to ongoing feedback and incorporate useful improvements.
8. FAQ
1. Who is WEAVE for? WEAVE is designed for both the creation of entirely new workloads and the implementation of changes to existing ones.
2. How much automation exists in WEAVE? A WEAVE user can select their preferred level of automation. They can choose to manually review each stage, leave the review to the agent for auto-authorization, or take a highly hands-on approach in the creation process. The lifecycle agents are capable of automating the entire workload lifecycle, including scanning for novel opportunities.
3. How will WEAVE workloads be deployed to orchestrators? The Embody team will maintain a registry where the lifecycle agents of every WEAVE user can post their workloads. Livepeer orchestrators can then browse this registry and select to deploy these workloads through a single command.
4.How are you sure that workloads will be secure? The security evaluation process naturally sits outside the domain of individual WEAVE users. All workloads will be automatically inspected by centralized lifecycle agents operated by the Embody team. Furthermore, every workload will require a manual review before it is approved for deployment to the registry.
5. Will WEAVE use existing Livepeer components for the workload lifecycle and orchestrator payments? Yes. WEAVE will use Bring Your Own Compute (BYOC) for workload deployment, alongside Livepeer gateways and the clearinghouse for workload delivery and payments. The custom Embody parts that previously fulfilled these functions will be replaced with their mapped Livepeer-specific components.
6. What happens if you aren’t finished in the provided timeframe? All provided funds managed by the multisig will be converted to LPT and sent back to the treasury.
9. References & Technical Appendix
This appendix serves as the deeper review bundle behind the shorter forum post. The post stays high-level; the linked docs carry the architecture, roadmap, budget, and governance detail.
Repositories
-
embody-skill: https://github.com/its-DeFine/embody-skill
-
livepeer-ops: https://github.com/its-DeFine/livepeer-ops
-
Unreal_Vtuber: https://github.com/its-DeFine/Unreal_Vtuber
Packet Docs
note: packet docs are being actively updated for the new version
", replyCount: 21, views: 423, likeCount: 39, datePosted: "Feb 17, 2026", lastActivity: "Apr 1, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Embody Team: Updates", href: "https://forum.livepeer.org/t/3215", author: "By DeFine (@DeFine)", content: "Embody Team: Retrospective
Date: February 9, 2026
This document provides a retrospective of the Embody team’s (DeFine + Dane) workstream, covering the Agent SPE Phase 2 period and post-separation efforts through February 9, 2026. Our focus is on the open-source deliverables and technical contributions made to the Livepeer ecosystem. This retrospective is scoped to the Embody-managed workstream and does not cover the full scope of the Agent SPE Phase 2 grant.
Executive Summary: What We Shipped
•Open-Source VTuber Stack: Shipped and maintained Unreal_Vtuber, a Pixel Streaming stack enabling Livepeer orchestrators to run embodied MetaHuman avatars. Tagged open-source releases from v1.0.0 (December 18, 2025) through v1.3.5 (January 28, 2026).
•Dynamic Customization: Delivered extensive avatar and environment customization, including a character customizer, morph targets, hair, clothing, and camera controls, as documented in the weekly work logs.
•Incentives Pipeline: Delivered and maintained an orchestrator incentives program, funded from Embody-managed inference credits. This work was outside the strict Phase 2 scope.
•Multi-Platform Broadcast Pipeline: Built a broadcast-capable pipeline (WebRTC source with an optional RTMP output for platforms like Twitch and YouTube). Automation of this pipeline is in active development.
•Continued Work Post-Separation: Despite a reduced budget following the separation from Agent SPE, the Embody team continued execution and completed the majority of technical and non-technical deliverables.
Timeline Highlights
•April 14, 2025: Phase 2 begins.
•August 20, 2025: Separation settlement and allocations are publicly posted.
•December 18, 2025: First tagged Unreal_Vtuber open-source release (v1.0.0).
•January 28, 2026: Unreal_Vtuber v1.3.5 is tagged.
•February 7, 2026: On-chain reconciliation packet is produced.
Promised Deliverables vs. Current Status
This section is structured by the Phase 2 proposal’s “Months 1–6” deliverables, with Embody’s current status and evidence pointers. Items Embody did not manage (funds and execution) are explicitly marked as Defer to Agent SPE.
| Deliverable | Status (Embody) | Evidence |
|---|---|---|
| Technical Excellence | Delivered a full embodied-avatar pipeline and operational Pixel Streaming stack. The “sub-100ms” latency target from the proposal is a goal; this document does not include an independent benchmark. | Unreal_Vtuber OSS stack |
| Livepeer Integration | Delivered. Orchestrators can run embodied avatars via the open-source stack, and Phase 2 weekly logs show Livepeer inference integrations and related pipeline work. | Unreal_Vtuber OSS stack, Livepeer-Autogen-Integration, plugin-livepeer-inference, NeuroSync-Core, eliza-livepeer-integration |
| Streamlined Onboarding | Delivered simplified operator onboarding for the OSS stack. The “<5 minutes” figure is a proposal target, not a universally measured setup time. | Unreal_Vtuber OSS stack |
| Comprehensive Analytics | Partially delivered. OSS/runtime telemetry exists, and production-validation analytics were set up via PostHog (not a treasury deliverable). | PostHog work is documented in internal repository files. |
| Dynamic Customization | Delivered. Dane’s Phase 2 work (Animator Handbook) documents extensive customization work. | Animator Handbook |
| Multi-Platform Deployment | Delivered a broadcast-capable pipeline (Pixel Streaming → RTMP) and ongoing operator automation for autonomous streaming. A fully autonomous, interactive VTuber is live and continuously improving, with memory and background tool-use capabilities. Note: the autonomous agent is continuously improving, and its current state represents the baseline of its capabilities. | Livi Embody — Autonomous VTuber (Twitch) |
| Protocol Partnerships | ElizaOS integration plans were paused/deprioritized; the primary execution path pivoted to Embody-managed direct integrations. | eliza-livepeer-integration |
| Startup Integration Program | Defer to Agent SPE. Embody did not manage these funds post-separation. | Separation Post |
| Usage Incentives | Defer to Agent SPE for the original proposal line item. Separately, Embody did operate and maintain an orchestrator incentives program funded from the inference credits allocated to Embody. Note: Livepeer stakeholders requiring the full unredacted financial/accounting pack may contact the Embody team. | Public Financial Audit Pack |
| Use Case Demonstrations | Delivered multiple demonstrations and continues to iterate on use cases, including a live autonomous interactive VTuber stream. | Livi Embody — Autonomous VTuber (Twitch), Livepeer Fireside Appearance, Unreal Vtuber Demo |
| Financial Sovereignty Infrastructure | In progress. Will be released this week with the public release of the OpenClaw agent repository. | Release pending. |
| Diversified Revenue Frameworks | Embody has begun operating in the agent-to-agent economy(see embody.zone). A further community update on this deliverable will follow within the week. | embody.zone |
Sources Used
", replyCount: 1, views: 129, likeCount: 4, datePosted: "Feb 10, 2026", lastActivity: "Mar 25, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Metrics and SLA Foundations for NaaP", href: "https://forum.livepeer.org/t/3189", author: "By speedybird (@speedybird)", content: "Thank you to everyone who reviewed the earlier pre-proposal and shared detailed feedback in the forum and during the Watercooler. The concerns raised around scope, cost, architectural risk, and MVP clarity were well-founded and directly informed this revision.
This updated pre-proposal reflects a deliberate reset toward a smaller, clearer Network-as-a-Product MVP. The scope has been significantly narrowed, the budget reduced, and the architecture simplified to prioritize time-to-value, reuse of existing Livepeer infrastructure, and immediate usefulness to gateways, orchestrators, and ecosystem teams.
Below is the revised pre-proposal. We welcome the community’s review and feedback on the updated scope, design, and framing. We will be present on this coming Monday’s Water Cooler for discussion.
Cloud SPE Pre-Proposal: Network-as-a-Product (NaaP) MVP – SLA Metrics, Analytics, and Public Infrastructure
Abstract
This pre-proposal seeks treasury funding for the Livepeer Cloud Special Purpose Entity (SPE) to design, build, and operate a focused Network-as-a-Product (NaaP) MVP for SLA metrics, analytics, and public visibility.
The objective of this work is to make the Livepeer network measurable, comparable, and trustworthy at a network level by delivering a small but complete set of standardized performance, reliability, and demand metrics. These metrics will be publicly observable and designed to support gateway providers, orchestrators, and ecosystem builders evaluating Livepeer as production infrastructure.
This MVP intentionally prioritizes time-to-value, architectural simplicity, and reuse of existing Livepeer infrastructure, while establishing a durable foundation for future SLA-aware routing, scaling, and productization efforts led by Livepeer Inc, the Livepeer Foundation, and the community.
Rationale
As Livepeer advances toward the Network-as-a-Product vision, predictable service characteristics and transparent performance signals become essential. While the network supports real workloads today, participants lack a shared, network-wide view of performance, reliability, and demand that can be used to assess suitability for production use.
Community discussions around earlier drafts of this initiative strongly aligned on the problem, while raising important concerns around scope, cost, architectural risk, and MVP clarity. This pre-proposal reflects that feedback by narrowing focus to a practical MVP that:
- Demonstrates clear value with minimal complexity
- Leverages existing data sources and pipelines wherever possible
- Avoids protocol changes, enforcement mechanisms, or premature decentralization
- Produces immediately usable outputs for real network participants
Key challenges addressed by this proposal include:
- Fragmented metrics: Existing performance and reliability data is dispersed across systems and difficult for non-core teams to consume.
- Limited network-level visibility: Gateway providers and orchestrators cannot easily compare performance across regions, workloads, or peers.
- Adoption friction: Without transparent, shared metrics, external developers and partners struggle to evaluate Livepeer for serious workloads.
- Missing foundation for NaaP evolution: Future SLA-aware routing, scaling, and automation require a trusted measurement layer first.
The Cloud SPE is well positioned to deliver this work as neutral, public infrastructure, building on its prior experience operating gateways, test tooling, dashboards, and analytics for the Livepeer network.
Importantly, this proposal does not attempt to enforce SLAs, modify protocol incentives, or introduce new routing logic. Its purpose is to establish shared measurement and learning infrastructure as a prerequisite for those future decisions.
Deliverables
The NaaP MVP will deliver a constrained, end-to-end metrics system focused on observability and learning inspired by the NaaP product MVP and Foundation roadmap.
1. Core SLA Metrics (MVP Scope)
- A standardized set of network, performance, and reliability metrics sufficient to evaluate orchestrator and GPU behavior across workflows.
- Metrics sourced primarily from job tester gateway and orchestrator-emitted telemetry, with targeted additions only when other Gateways opt-in.
2. Network Test & Verification Signals
- Operation of one or more reference load-test gateways to generate consistent, reproducible performance signals for live AI video pipelines.
- Public test scenarios (aka test datasets) designed to reflect real workloads while remaining transparent and community-verifiable. These will be captured in Github.
- Test results contributed into the same analytics layer as organic network traffic to enable comparison (when other Gateways participate).
3. Analytics & Aggregation Layer
- Lightweight ETL and aggregation pipelines to transform raw metrics into network-level views.
- Computation of a small number of derived indicators as outlined in the Metrics Catalog
- Data structured for efficient querying without requiring dashboards to load raw job data.
4. Public Dashboard & APIs
- A standalone public dashboard presenting live and historical metrics.
- Public, read-only APIs for aggregate SLA scores and hardware.
- Clear paths for gateways and ecosystem teams to consume the data directly or mirror it into their own analytics systems.
5. Operations & Stewardship
- Ongoing operation of testing, analytics, and dashboard infrastructure.
- Maintenance, monitoring, and community support for the MVP for 1 year.
Any scope not outlined here is not part of the Deliverables and out of the scope of this proposal.
Key Milestones
Milestone 1 – Metrics Collection & Aggregation
- Define and implement the minimal metrics set
- Aggregate existing telemetry into a unified analytics layer
- A basic dashboard showing sample data flowing end to end
Milestone 2 – Test Signals & Derived Analytics
- Deploy reference load-test gateways
- Launch a public dashboard with core views
- APIs for ecosystem consumption
Milestone 3 – Stabilization & Review
- Harden infrastructure for reliability and cost efficiency
- Document metrics, assumptions, and known gaps
- Review outcomes with the community to determine next steps
Timeline
Delivery is anticipated to take approximately six months (and already underway as of November 2025). This is dependent on the team’s development velocity and subject to change. Preliminary design and validation work has begun to reduce delivery risk.
- November 2025 - Works began on original proposal and discovery process
- February 2026 – Milestone 1: Metrics Collection & Aggregation
- March 2026 – Milestone 2 – Test Signals & Derived Analytics
- April 2026 – Milestone 3 – Stabilization & Review
Budget
Total Requested Budget: $90,000
This budget supports:
- Engineering work to aggregate, validate, and expose SLA-relevant metrics
- Development of Load Testing Gateway (AI Job Tester + Gateway enhancements) and Network Data Scraper
- Development of minimal analytics and public-facing dashboards
- Development of DevOps infrastructure and automation
- Operation of testing, analytics, and storage infrastructure for approximately one year
- Ongoing maintenance, documentation, and community support
The budget is intentionally sized for a thin but complete MVP, designed to validate assumptions, inform future investment, and avoid long-term commitments before value is demonstrated.
Closing Note
This pre-proposal reflects extensive community and Livepeer Inc feedback and represents a deliberate step toward a simpler, clearer, and more actionable NaaP MVP.
By focusing on shared measurement rather than enforcement or protocol change, this work aims to give the Livepeer ecosystem a common understanding of network behavior today — and a solid foundation for deciding what to build next.
", replyCount: 12, views: 331, likeCount: 48, datePosted: "Jan 10, 2026", lastActivity: "Apr 14, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Proposal - Protocol R&D Special Purpose Entity", href: "https://forum.livepeer.org/t/3160", author: "By Rick (@rickstaa)", content: "Abstract
All network value depends on protocol security.
Protocol security requires dedicated capacity to detect issues early, resolve them quickly and deploy upgrades with confidence. The current model depends on limited, distributed resources that cannot consistently support these demands. The Protocol R&D Special Purpose Entity (SPE) resolves this by establishing a professional, continuously staffed function responsible for vulnerability triage, safe upgrade preparation, and shipping additional protocol features like a reliable testnet for rigorous validation and development.
This proposal funds the SPE for an initial six-month term. It brings together a contracted security and engineering partner, under the governance of Livepeer Foundation and Livepeer Inc. The SPE creates a single, accountable structure that protects the protocol, reduces operational risk and enables faster, safer delivery of protocol improvements as the network continues to scale.
Mision
The mission of the Protocol R&D SPE is to provide the most secure, resilient and continuously improving protocol foundations possible for Livepeer, at the best possible price-to-value ratio.
Rationale
The protocol supports significant on-chain value which continues to grow through the expansion of services to real-time video AI inference. Protecting this requires consistent access to security and engineering expertise. The current model, while effective at securing the protocol since inception, relies on Livepeer Inc and places a significant load on the security committee. This constrains core feature development and protocol progress. Having a dedicated security partner reduces the load on the security committee and frees them for other obligations, while increasing the speed at which we can improve network security.
Core to this SPE is the engagement of a Protocol Engineering & Security Partner (Sidestream) to provide a dedicated, multi-disciplinary team. They provide first‑response to Immunefi-identified vulnerabilities and implement audited on‑chain patches and upgrades. Immunefi has been a massive success in terms of the mission, keeping the protocol safe at modest cost—historically about $75–100k per year in bounty payouts—while helping protect tens of millions in protocol value. The Partner works in close coordination with the Security Committee, which retains review and execution authority for upgrades and emergency patches.
The steps reduce our reliance on more constrained support, and moves toward a stable, accountable model for protocol security. The SPE creates a durable, well defined structure for protocol stewardship as the network decentralizes. It gives the community a clear point of accountability for security and core maintenance, which reduces operational risk and supports the reliable functioning of the protocol over the long term.
Deliverables
The Protocol R&D SPE improves operational responsibilities, fast and continuous response, ships already‑built but not‑yet‑deployed features in the protocol R&D pipeline, and launches and maintains a public testnet and DevEx toolkit to speed up future development.
(1) Core Protocol Security Operations
Goal: Maintain continuous protocol security coverage and rapid incident response through the Immunefi bounty program and close coordination with the Security Committee.
Outputs: The SPE will manage the Immunefi process as first responder for vulnerability reports. The Partner will reproduce, validate, and propose patches within defined response windows, in coordination with the Foundation Technical Lead and the Security Committee for review and deployment. Quarterly readiness reviews will strengthen detection, response time, and coordination.
Success Indicators: Continuous Immunefi coverage with valid reports acknowledged within 24 hours and triaged within one week. Critical issues are resolved or escalated for deployment within agreed timelines. The SPE operates the response process independently while the Security Committee maintains oversight.
(2) Ship Backlog Features and Build the R&D Pipeline
Goal: Deliver the high-priority protocol upgrades from the existing backlog while building the foundation for a sustainable and iterative R&D process.
Outputs: The SPE will complete and deploy existing features nearing readiness for mainnet release—such as the Reward Call Delegate, Ticket Distinction, and stability patches. The specific upgrades shipped each release cycle will be selected through a lightweight triage process established by the SPE, supported by the Foundation protocol engineer as the role comes online.
Success Indicators: At least one backlog feature or patch deployed to mainnet per release cycle. Lightweight triage and delivery process is established and used to prioritize and ship work. The Foundation protocol engineer is hired and supporting development and coordination by the end of Q1 2026.
(3) Public Testnet and Developer Infrastructure
Goal: Deliver and maintain the testnet and tooling needed for reliable validation, audits, and developer experimentation, supporting both protocol and client development.
Outputs: The SPE will operate a continuously available public testnet with faucet access, CI integration, and simulation tooling. Clear developer documentation and workflows will make it easier to run local or private devnets and test upgrades or integrations before mainnet deployment.
Success Indicators: Public testnet operational with ≥99% uptime and integrated into CI and simulation workflows. Developer and client teams actively use the infrastructure for validation and testing.
Key Milestones
| Milestone | Target Completion | Description |
|---|---|---|
| Partner Onboarding Completed | Q4 2025 | Protocol Engineering & Security Partner contracted and operational, and security and triage procedures aligned with the Security Committee. |
| Continuous Immunefi Vulnerability Response | All of H1 2026 | Maintain full first-response capability for Immunefi reports: reproduce issues, propose fixes, coordinate Security Committee review, and ensure continuous coverage. |
| Public Testnet Live | Q1 2026 | Launch a stable, persistent public testnet with faucet, CI integration, and reproducible deployment tooling. |
| Triage Pipeline Established & First Upgrade Shipped | Q1 2026 | Lightweight triage process established and validated through at least one feature or protocol upgrade shipped to mainnet. |
| Triage Pipeline Updated & Additional Upgrade Shipped | Q2 2026 | Triage pipeline updated, with at least one additional upgrade triaged and deployed to mainnet. |
| Six-Month Review & Renewal Assessment | Q2 2026 | Performance and financial review concluded by the SPE Board,; results shared publicly and renewal proposal prepared. |
SPE Governance Structure
The Protocol R&D SPE is managed and governed by the Livepeer Foundation and Livepeer Security Committee. Through their collaboration, they enable the work of the Protocol Engineering & Security Partner.
The exact operations of security practices are not shared here.
SPE funds are held in a secure multisig SAFE with a threshold of known, trusted signers from the Foundation and the Security Committee, following standard security practices.
The SPE will operate transparently through quarterly public reporting, open development and open access to non-sensitive work.
Roles & Responsibilities
| Body / Role | Responsibilities | Scope | Funding Source |
|---|---|---|---|
| Security Committee | Review and execute upgrades and patches a final security checkpoint | Security oversight; upgrade authorization & execution. | Livepeer Inc. |
| Foundation | Coordinate roadmap and delivery, manage funds and payouts for Immunefi, audits and security partner milestones | Program and roadmap management, coordination and treasury/ops. | Foundation |
| Protocol Engineering & Security Partner | First responder for patches, implementator of new protocol features, audited upgrades, and patches, and build/maintenance of testnet and tooling components | On-chain development, security response, contract CI/tooling, on-chain testnet components. | SPE |
Budget
The Protocol R&D SPE seeks $360,000 equivalent amount. This ensures 24/7 responsiveness from the team in addition to their core security deveopment work.
The budget includes a line item for audits to ensure that significant protocol changes and new implementations receive appropriate security review before deployment. Other necessary costs for executing this SPE, such as the Foundation’s protocol engineer, infrastructure, and operations, are covered separately by the Foundation.
A core responsibility of the SPE is managing the Immunefi bounty program. The Livepeer Foundation will cover Immunefi payouts in the short term to avoid withdrawing capital from the treasury until necessary. This approach allows treasury capital to continue supporting other strategic initiatives across the ecosystem. As part of the Foundation, I can share that we are glad to support this active capital management to advance Livepeer’s collective goals.
Projected Spending:
| Category | LPT | USD | Description |
|---|---|---|---|
| Protocol Engineering & Security Partner (team) | N | $300,000 | Six-month engagement focused on security response, prioritized backlog features, and on-chain testnet ops. |
| Audits & External Reviews | N | $60,000 | Third-party security reviews (reserve-based) |
| Total Initial Request | N | $360,000 |
Key Terms
| Term | Definition |
|---|---|
| Protocol R&D SPE | A Special Purpose Entity funded by the Livepeer Treasury to manage protocol research, development, and security operations. |
| Protocol Engineering & Security Partner | The contracted team responsible for hands-on protocol development, audits, and vulnerability response under the SPE framework. |
| Security Committee | Oversight body responsible for reviewing protocol upgrades, validating critical patches, and guiding decentralization of security responsibilities. |
| Immunefi Program | Livepeer’s bug-bounty initiative that incentivizes whitehat researchers to identify and responsibly disclose vulnerabilities in the protocol. Managed under the SPE to ensure continuous coverage and rapid triage. |
| Triage Pipeline | The structured process for evaluating, prioritizing, and implementing protocol work, including community proposals (LIPs) and vulnerability reports, through coordinated specification, review, and deployment stages. |
| Public Testnet | A continuously maintained network environment mirroring mainnet, used for protocol validation, client testing, and developer experimentation before production deployments. |
| DevEx Tooling | Developer-experience infrastructure, including CI pipelines, simulations, and documentation, enabling contributors to test and validate protocol upgrades efficiently and safely. |
| SPE Board | The governance body composed of representatives from the Foundation, Security Committee, and Livepeer Inc., responsible for approvals, budget oversight, and performance reviews. |
| Audits | Independent security reviews performed by external experts to assess the safety, correctness, and performance of protocol changes before deployment. |
| Multisig SAFE | A secure multi-signature wallet used for custody and management of SPE funds, requiring approval from designated Foundation and Security Committee signers. |
As part of our monthly accountability updates, the Lisar SPE is happy to share our second monthly progress update covering—what we’ve completed, what’s currently in motion, and what’s coming next.
Quick note: This release notes will serve as a way to share what work is going on with Lisar. All future reports will be added under this thread so anyone can easily track progress without hunting for older updates. Dive in to explore what’s happening and please reach out or reply if you have any questions.
October - Status Update
We previously published our first update sharing details of what work was done, if you missed it please find link to the report here
November – Status Update
The Lisar SPE is actively working toward our core deliverable:
unlocking delegation access for everyone globally by enabling fiat-based delegations (USD, NGN, GBP, KES, and more).
Here’s what was completed in November
- Completed a closed beta with users and internal testers
- Switched the transparency dashboard to live mode, enabling real-time community visibility
- Public launch after beta validation
Closed Beta Testing
We kicked off a closed beta in early November with a group of early users. This allowed us to test the entire lifecycle—depositing fiat, converting to LPT, delegating, tracking rewards, and withdrawing back to fiat—with real users.
The beta surfaced minor UX improvements, but overall validation was strong, and all core flows performed as expected.
Live Transparency Dashboard
Our public transparency dashboard is now live.
This means the community can monitor Lisar’s progress in real time—delegators onboarded, total fiat converted, total delegations and more.
Dashboard link: https://lisarstake.com/dashboard
Community transparency is one of our commitments, so getting this live was a major step.
Gearing Up for Public Launch
With beta successfully completed, we’ve shifted into launch mode.
Announcements are ready and will be going out shortly. We’re now entering the final stage outlined in the original four-month proposal with the remaining months focusing on driving adoption and scaling the platform responsibly.
Milestones & Timeline (As Outlined on the proposal)
Check out full proposal on the forum
Build the Core Platform — Completed
- Full fiat → LPT → delegation flow implemented
- Secure fiat on/offramp integrations for multiple currencies
- Gas sponsorship enabled (users never need ETH)
- Delegation + reward tracking in fiat equivalents
- Seamless withdrawals back to fiat
The core platform is stable and production-ready.
Transparency Dashboard — Completed
The dashboard now tracks and displays real-time metrics:
- Number of delegators onboarded
- Total fiat converted
- Total LPT delegated through Lisar
- Delegations per orchestrator
Launch & Scale — In Progress
Up Next
- Launch & Scale - we’re opening access for anyone to delegate on Livepeer through Lisar, with announcements going out across all channels soon. Our next phase focuses on bringing delegators onboard responsibly marking the transition from building → testing → growth.
Find below all relevant links on Lisar, we look forward to sharing more updates soon
Links
-
Begin staking on the Lisar app
-
Track live progress on the dashboard
-
Learn about Lisar, Livepeer, and staking through Lisar Academy
-
Guides on how to stake on livepeer through lisar are up on youtube
-
Follow development on Github
Hey everyone, I wanted to use this post to reinvigorate the inflation discussion led by @dob in this thread earlier this year.
As a member of the Foundation, and as chair of the Capital Markets Advisory board, I think it’s important to keep us moving forward on this as it part of broader perceptions of the Livepeer project, is part of the broader industry focus on ‘fundamentals’, and is a key component of how capital is allocated within our ecosystem.
From previous discussions (and some new ones), it seems there is broad consensus on the need for small and incremental action. I see my role as helping give a little nudge so we take that small but important first step.
The previous draft from Dob got us to the starting line of what a proposal could look like. My personal tldr of the thread was that:
-
There was general alignment that we should start taking some action
-
There’s alignment on using existing parameters, which avoids risks or delays from new protocol or smart contract work
-
But.. the sticking point was whether to do that using
targetBondingRateorinflationChange, or both, and how to do it in a principled, risk aware way rather than using something that might feel a bit arbitrary
Reinforcing all of this, during the Livepeer summit Doug and Arunas /@Jonas_Pixelfield completed a hackathon project that both modeled parameter changes and surveyed a sizeable set of Orchestrators and Delegators on their perceptions. A short summary is that:
-
Simple modeling shows small parameter changes lead to effects over a fairly long time horizon (in the range of 12+ months to reach something that might be considered major change). This gives ample time to start, observe, and learn and adapt as necessary as we go
-
The survey and interviews further reinforced the consensus from Orchestrators and Delegators that they see the need for action, but sometimes struggle to find confidence with any given approach
With all this in mind, I want to share what we plan to do to help the community move forward:
-
Firstly, we want to keep discussing the Inflation topic with Orchestrators and Delegators. Two ways to do this include:
-
Completing a short survey to expand on your thoughts about the topic
-
Book a meeting where we can discuss or asnwer any questions in real time
-
-
Secondly, we intend to try to quantify the risks involved with some additional modeling. I’ve asked Andrew from Shtuka Research (who is a member of the Capital Markets Advisory board) to take the lead on this. Andrew is a mathematician with a long career in academic and applied research, who will help quantify the risks of different change scenarios. He’ll also be helping us build out a framework for continual risk monitoring and adjustment in the future, so that we can all have confidence to move forward to voting on any proposed changes.
Hopefully you agree that these goals are a relatively simple way to make that last important push and build on the broad consensus reached so far. This is not a one-and-done topic so we will share a bit more about what the path ahead could look like as we get more information.
I’m going to sign off here so that Andrew can share a bit more about the survey and modeling, and I’d encourage anyone who wants to chat on this topic to reach out to me direct via DM on Discord or by using my calendar link share above.
", replyCount: 20, views: 1045, likeCount: 50, datePosted: "Nov 5, 2025", lastActivity: "Mar 2, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "RFP — Explorer Maintenance", href: "https://forum.livepeer.org/t/3072", author: "By Rick (@rickstaa)", content: "Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rick Staa
1. Objective
Restore the Livepeer Explorer to a secure, maintainable, and high-performance state while laying the groundwork for new network-wide data and governance dashboards.
2. Problem Statement
The Explorer is the primary entry point for orchestrators, delegators, developers, and gateways. However, since December 2023 lack of ownership has accumulated significant technical debt:
- Outdated dependencies in the Explorer and design system, fragile under Node 20, break on updates and could lead to security risks, undermining long-term maintainability.
- Duplicated/obsolete code and missing contribution infrastructure (guidelines, CI/tests, stubs), making contributions slow and error-prone.
- Inefficient data fetching (e.g. Infura/Graph duplication), creating performance issues.
- A backlog of unmerged PRs and unresolved bugs (e.g., broken migration widget, UI inconsistencies, incorrectly displayed data).
A future roadmap for expanded network data and richer Explorer stakeholder experiences depends on first restoring a stable, secure, and maintainable Explorer. This RFP focuses on that critical first step.
3. Desired Outcome
Success means that within four months the Explorer is:
- Clean, well tested, with automated tests and continuous integration pipelines, providing a healthy, maintainable codebase.
- Free of critical bugs and stale pull requests, with a clearly organized issue backlog.
- Running on up-to-date, secure dependencies (Explorer and design system) fully compatible with the current Node.js LTS.
- Improved in performance, with faster page loads and a simplified, well-documented data layer for developers
- Equipped with a new voting-transparency feature integrated with the voting-tally subgraph.
- Backed by a clear 6-month roadmap and a dedicated maintainer team providing ongoing maintenance and timely support.
In short, the Explorer will be trusted infrastructure and ready to power further iteration of capabilities.
4. Deliverables
Within four months (target completion by February 1, 2026), the selected team will deliver the following milestone-based outcomes.
Each deliverable must be demonstrated in a Livepeer community call, and the team must provide public progress updates at least every two weeks (e.g., forum posts) throughout the project.
Payments are released only after each demo is accepted by the RFP owner.
(i) Establish Healthy Explorer Codebase
Goal: Deliver a clean, maintainable, and well-tested Explorer foundation to enable ongoing community contributions.
Requirements:
- Remove unused and duplicate code.
- Reorganize folder and module structure, where needed, to improve navigation and long-term maintainability.
- Add comprehensive unit and integration tests covering all critical user flows (e.g., staking, delegating, governance), with measurable coverage targets proposed by the vendor.
- Implement CI pipelines for reliable builds and automated checks.
- Ensure all components are fully typed (TypeScript) and all ESLint/TypeScript errors resolved.
- Provide clear contributor documentation and review workflow, with local-development stubs/mocks so the codebase can run without production environment variables.
Outcome: A clean, healthy, well-tested codebase with CI pipelines and local stubs that contributors can run with minimal setup, forming a solid foundation for future improvements.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the cleaned codebase, CI, tests, and contributor docs.
(II) Improve Data-Fetching Efficiency
Goal: Enhance the Explorer’s data layer to reduce latency, eliminate redundant calls, and ensure responsive, reliable performance for end users and contributors.
Requirements:
- Optimize subgraph and RPC data fetching to reduce latency, avoid duplication, and improve responsiveness.
Outcome: A faster, more efficient Explorer with reduced redundant calls and a simplified, well-documented data layer for easier future contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, showcasing faster data fetching and improved data-layer developer documentation.
(III) Resolve Critical UI Issues & Backlog
Goal: Eliminate high-impact bugs and stale pull requests to ensure a stable, accurate, user-friendly Explorer.
Requirements:
- Resolve all current critical UI bugs (GitHub bug list), including the delegator migration widget, data inaccuracies, and major UX defects, and triage/fix any new critical issues during the engagement.
- Review and merge, close, or supersede all open pull requests (GitHub pull requests) other than the voting-transparency feature (covered in Deliverable 5).
- Work with the Foundation and Advisory Boards to prioritize any other high-impact feature requests from the backlog that fit within the agreed budget and timeline.
Outcome: A more stable, accurate, and user-friendly Explorer with all critical issues resolved and a significantly reduced bug backlog, ready for ongoing community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting a detailed report of resolved bugs and key fixes, along with the cleaned and updated issue board.
(IV) Deliver Voting-Transparency Feature & Subgraph Integration
Goal: Provide clear, real-time visibility into on-chain governance participation.
Requirements:
- Finalize and deploy the voting-transparency feature, incorporating requested UI refinements and migrating data fetching to the voting-tally subgraph for improved performance, using feedback from the Foundation and Advisory Boards.
Outcome: A fully deployed voting-transparency feature integrated with the voting-tally subgraph and refined UI, offering accurate, real-time governance data.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the live voting-transparency feature.
(V) Establish Maintainability & Roadmap
Goal: Ensure the Explorer remains easy to maintain with a clear 6-month plan.
Requirements:
- Publish a 6-month feature/bug roadmap aligned with the Foundation’s Data Gap Analysis and community feedback.
- Provide contributor docs, maintenance practices, and an issue-tracking process (including a clean, well-labeled issue board).
Outcome: A documented maintenance framework and forward roadmap enabling smooth ongoing development and community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting the final roadmap and contributor maintenance guide.
(VI) Provide Ongoing Support & Post-Delivery Responsibility
Goal: Ensure professional post-launch support and continuity of maintenance, whether the same team continues or future maintainers take over.
Requirements:
- During the project, acknowledge critical bugs within 24–48 hours and resolve or mitigate them within a few business days (or faster per the proposer’s SLA).
- After delivery, provide at least a 60-day support window for critical fixes, security incidents, and knowledge transfer, meeting the proposer’s SLA.
Outcome: Stable post-launch operations with timely critical-issue resolution and clear processes for continued maintenance, regardless of who maintains the Explorer.
Payment: The team must present a support-readiness plan with defined SLA commitments, to be agreed with the RFP owner. Ninety percent of each milestone payment is released after acceptance of that milestone’s demo. The remaining ten percent of the total contract is held until the 60-day support period concludes and SLA commitments and resolution targets are met.
Out of Scope
To avoid confusion, the following items are not part of this RFP:
- A full UI/UX redesign or new visual styling of the Explorer.
- Major new product features beyond the initial voting-transparency integration.
- Broader data-gap mapping (handled by separate workstreams).
- Protocol/client changes or on-chain improvements to surface new data (managed through separate RFPs within the same workstream).
5 Capabilities required
Skills
- Strong front-end engineering in modern JavaScript/TypeScript (React/Next.js), including implementing and refining accessible UI components within an existing component library or design system.
- Proven experience with codebase modernization and maintainability—refactoring, setting up CI/CD pipelines, adding automated unit and integration tests, and enforcing TypeScript and ESLint standards.
- Ability to update and manage complex dependency stacks, including Node.js and modern package managers, while resolving breaking changes and configuring automated update tooling (e.g., Dependabot or Renovate).
- Proficiency in performance optimization and efficient data-fetching techniques, particularly with GraphQL/subgraph and RPC endpoints.
- Experience reviewing, triaging, and merging open-source pull requests and managing a clean, well-labeled issue backlog.
- Familiarity with monitoring and incident-response tools (e.g., Sentry, Bugsnag) to ensure production reliability.
Knowledge
- Understanding of the Ethereum/Web3 stack, including wallet flows, transactions, RPC providers, and common front-end pitfalls.
- Awareness of accessibility (a11y) best practices and secure front-end patterns such as dependency risk management and safe secret handling.
- Experience with open-source project governance, including contributor guidelines, code review workflows, semantic versioning, and changelogs.
- Familiarity with The Graph/subgraph architecture and GraphQL schemas (nice to have).
- Familiarity with the Livepeer protocol and current Explorer repository (nice to have).
Attitude
- Community-oriented and collaborative, engaging proactively with contributors, Advisory Boards, and Foundation stakeholders.
- Accountable and responsive, acknowledging critical bugs within 24–48 hours and working toward mitigation or resolution within a few business days.
- Documentation-first mindset, maintaining clear READMEs, runbooks, and migration notes to enable future contributors.
- Quality-driven and pragmatic, balancing rigorous testing, CI, and security with on-time delivery.
- Long-term stewardship, treating the Explorer as trusted infrastructure and designing for multi-year maintainability.
- Supportive and open, encouraging new contributors and fostering an inclusive contributor community.
- Mission-aligned, motivated to strengthen the Explorer as a cornerstone of the Livepeer ecosystem.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience – examples of large front-end refactors, dependency upgrades, CI/CD setup, performance optimization, or open-source project maintenance.
- Milestone Breakdown – a plan aligned with Section 2 deliverables, with proposer-set milestone dates and demo day schedules, each including clear outputs and payment tied to demo acceptance.
- Support & Maintenance Plan – proposed SLA commitments (e.g., response and resolution times), 60-day post-delivery support approach, and handover/knowledge-transfer strategy.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template.
7. RFP Timeline
Proposal Deadline: Wednesday 24th September 2025
Decision Announced: Friday 26th September 2025
Project Start: Wednesday 1 October 2025
Project Completion: Sunday 1 Feb 2026
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
@rickstaaon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rich O’Grady
1. Objective
Restructure, refresh, and modernize Livepeer’s documentation so that it is stakeholder-focused, AI-first, and future-proofed. It should cater to the core personas of the Livepeer project: developers, delegators, gateway operators and orchestrators.
2. Problem Statement
Current Livepeer docs suffer from:
- Complicated onboarding: User journeys (node operators, app builders, delegators, gateway providers) are hidden behind toggles instead of clear entry points.
- Outdated or inconsistent content: Deprecated APIs, stale references, incomplete AI coverage, and fragmented changelogs.
- Brand & duplication: Studio-specific guidance is mixed into core docs; AI SDKs and APIs are duplicated across gateways.
- Weak site integration: Poor linkage between website, explorer, governance portal, and docs. Too many Studio dashboard references.
3. Desired Outcome
Success is a single-source-of-truth documentation system that:
- Leads with clear stakeholder-focused onboarding and goal-oriented entry points.
- Cleanly separates AI Jobs vs Transcoding Jobs while still surfacing cross-cutting resources (SDKs, APIs, CLI, on-chain/network).
- Fully deprecates Studio content with redirects and zero broken links.
- Provides AI-first documentation: semantically structured, LLM-readable, with embedded natural language search/assistant.
- Consolidates changelogs and introduces versioning / deprecation tracking.
- Establishes a style guide, contribution model, and ownership playbook for consistency.
- Integrates seamlessly with the broader Livepeer ecosystem (website, explorer, governance, dashboards).
4. Deliverables
(i) Present New Documentation Strategy
Goal: Create a new outline for Livepeer documentation, including full map of current documentation, a clear information architecture and timeline for writing new documents.
Requirements:
- Identify core stakeholder groups (Livepeer Foundation, Livepeer Inc, AI SPE, Cloud SPE, Streamplace, Frameworks and more)
- Conduct of all docs pages with status recommendations across the 4 categories (Developers, Delegators, Orchestrators, Gateway Operators)
- Developers: clean up deprecated sections and plan integrations with new gateway products (Streamplace, Frameworks, Daydream and more)
- Orchestrators: simplify documentation to easy onboarding with plan for support in Discord.
- Delegators: integrate new video content to make it easy to delegate.
- Gateways: streamline documentation and workflows with support from the Foundation.
- Create plan for an updated sidebar, taxonomy, and breadcrumb structure.
- Consolidation of multiple changelogs into a single canonical feed.
- Onboard stakeholders to project management process
Outcome: A forum post detailing the new documentation to the community with a 1-week window RFC.
Demo Due Date: Friday 17th October
(ii) Re-Write Documentation
Goal: Systematically edit and rewrite new content to meet stakeholder needs with consistent accuracy and depth.
Requirements:
- Work with core stakeholders to rewrite documentation
- Make the documentation easily consumable by AI systems and empower users with an embedded assistant ( semantic headings, structured metadata, and machine-readable references (OpenAPI specs, JSON examples).
- Integrate embedded natural-language search or AI assistant (leveraging Mintlify features) and ensure clear explanations and concise summaries for LLM parsing.
- Rewrite quickstarts for both AI Jobs and Transcoding Jobs.
- Migration guides for Studio users.
- Integrate goal-based tutorials for each stakeholder type where possible.
- Work with existing groups to incorporate starter repos, examples, and copy-paste snippets and full API/SDK/CLI references with updated coverage (including realtime + BYOC APIs).
- Conduct review with core stakeholders with a clear RFC.
Outcome: First written draft of clear, accurate, and goal-oriented documentation that accelerates adoption and reduces support overhead.
Demo Due Date: Friday 7th November
(iii) V1 Documentation Live
Goal: Deliver a technically sound and reliable documentation site.
Requirements:
- Implement redesigned IA and content in the current docs stack (Mintlify/Docusaurus).
- Set up redirects, SEO and AEO optimization, and accessibility compliance (WCAG).
- Integrate multilingual readiness and analytics tracking.
- Integrate the documentation into the website.
Outcome: A responsive and performant documentation site with zero broken links, measurable engagement, and improved accessibility.
Demo Due Date: Friday 14th November
(iv) Public Workflow For Maintenance & Community Contributions
Goal: Create a consistent tone and a scalable contribution process.
Requirements:
- Work with the Livepeer Foundation’s Technical Director to establish a unified voice and style guide (tone, terminology, formatting, accessibility).
- Create contribution guidelines and PR workflow for community involvement.
- Define and handover ownership and review process for maintaining quality.
- Integrate multilingual readiness and analytics tracking.
- Provide a clear ticketing system for reporting problems and patching fixes.
Outcome: A sustainable documentation process with consistent voice, tone, and governance.
Demo Due Date: Friday 5th December
5. Capabilities Required
Skills
- Developer documentation strategy, IA design, technical writing.
- Static site tooling, redirect management, docs CI pipelines.
- SEO, accessibility, multilingual documentation workflows.
Knowledge
- 1+ years experience with Livepeer ecosystem
- Streaming/transcoding basics (FFmpeg, GPU workloads).
- AI inference workflows basics, particularly working with APIs.
- Open-source contribution models and GitHub-based workflows.
- Comparative familiarity with best-in-class docs (e.g., Chainlink, Base, Solana).
Attitude
- Community-first, collaborative, pragmatic.
- Strong eye for clarity, consistency, and long-term maintainability.
- Willingness to challenge outdated patterns and propose future-proof solutions.
- Enjoyment in distilling complex technical concepts into minimal, user-focused documentation.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience - examples of docs restructures, especially for developer platforms.
- Milestone Breakdown - giving a week-by-week breakdown of the project in line with the due dates and requirements above.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template
7. RFP Timeline
- Proposal Deadline: Wednesday 24th September 2025
- Decision Announced: Friday 26th September 2025
- Project Start: Monday 29th September 2025
- Project Completion: Friday 5th December 2025
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
Rich | Livepeer Foundationon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
- Payments: when thinking through your total budget, be mindful that payments will be paid out on milestone completion.
Hi everyone! I’m running a Livepeer transcoder based in Slovenia since 2022, focused on reliability, sustainability, and geographical diversity in the network. I truly believe Livepeer has huge room to grow, and I’m in it for the long run.
Hardware setup:
- 2× NVIDIA GTX 1070 GPUs for rock-solid transcoding
- 1× NVIDIA RTX 3090 dedicated to the AI network
- Solar-powered when available
Current fee structure:
- Reward cut: 8%
- Fee cut: 49%
Cuts may lower as more LPT is staked — early delegators are rewarded!
If you’re looking to support a trustworthy, green, and diverse node, consider staking with me:
Delegate here
Got questions or just want to connect? Join me on Discord: @gasper5466
", replyCount: 12, views: 482, likeCount: 6, datePosted: "May 30, 2025", lastActivity: "Mar 4, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "Streamplace 2.0: Solving Video for Everybody Forever", href: "https://forum.livepeer.org/t/2847", author: "By Eli Mallon (@iameli)", content: "EDIT: Updated proposal later in the thread.
Hey everyone. I’ve been tinkering with this draft all week but just wanted to get it out there ASAP to kick off the process. For more context, check out my presentation to the treasury last Monday - Part 1 and Part 2.
STREAMPLACE 2.0: SOLVING VIDEO FOR EVERYBODY FOREVER
Summary
We’re requesting 250,000 LPT to continue building the video layer for the next generation of decentralized social. In less than a year, Streamplace (née Aquareum) has evolved from a concept to a functional platform powering thousands of hours of livestreaming, securing partnership with Skylight (a TikTok alternative that reached #1 in entertainment on the App Store), and establishing itself as the go-to solution for live video on the AT Protocol.
The Livepeer treasury made all of that happen, and we’re thrilled to be continuing to fund the project as a shared public good. With your support, we’ll expand our infrastructure, hire specialized talent, enhance moderation capabilities, deepen AT Protocol integration, develop VOD functionality, and explore monetization options—all while maintaining our commitment to open-source development and building public infrastructure.
What We’ve Accomplished
Technical Achievements
- The Protocol: Streamplace has invented a novel form of decentralized livestreaming. Our technique, utilizing C2PA-powered Ethereum signatures over one-second MP4 files, is both cryptographically secure and easy to work with.
- The Node: The Streamplace node runs on all major platforms — Windows, macOS, and Linux, and supports AMD and ARM64 architectures. The node is a single file - deployment is the easiest thing in the world. It’s available for download at Stream.place!
- The App: We shipped the Streamplace mobile app to the App Store and Play Store; Streamplace Desktop is also available for download on Windows, Mac, and Linux. Grab it at https://app.stream.place!
- Implemented WHIP and WHEP protocols The Streamplace node utilizes WebRTC for the entire stack — this makes it super easy to support streaming from browsers and phones while delivering low-latency video playback for viewers.
- Libraries: We shipped c2pa-go, the first library for using C2PA primitives in Go. We implemented Ethereum key support in c2pa-rs and shipped the first library for AT Protocol Oauth using React Native, which is in production in multiple atproto applications.
- Livepeer transcoding: All streams through stream.place are transcoded on the Livepeer network, establishing LIvepeer as a key component in the next generation of decentralized social.
Community & Market Traction
- Sponsored ATmosphereConf livestreaming - Streamplace sponsored the first ATmosphereConf; we both operated the livestream and produced the stream on-site. It went really, really well!
- As a direct consequence, we were featured in TechCrunch as a part of a roundup of next-generation apps building on atproto — we were all by ourselves in the livestreaming category!
- Skylight Social partnership - Also as a direct consequence of the conference, we’re bringing livestreaming to Skylight Social, a Mark Cuban-backed TikTok alternative that recently reached #1 in entertainment and #7 overall on the iOS App Store. Skylight surpassed 150,000 users in the first three days after launch and users are consistently pinging their team asking to go live. As soon as this feature ships, all of this livestreaming will be going through the Livepeer network!
- Established ownership of the live video niche on the AT Protocol. Not only that, but Streamplace will be one of the earliest projects to launch significant video content outside of Bluesky’s infrastructure, contributing to the decentralization of the protocol.
All of this has been achieved while keeping every single line of code open-source and freely licensed.
The Opportunity
We’re at a critical inflection point. We’ve proven the concept works, secured key partnerships, and demonstrated clear product-market fit. Rather than pursuing venture capital with its inherent pressure toward extractive business models, we’re seeking continued support from the Livepeer treasury to pioneer a new public goods funding model—one focused on solving hard technical problems for the benefit of an entire ecosystem.
Funding Allocation (250,000 LPT)
Team Expansion
We need to bring on more people full-time to actually deliver on this dream; to start off we’ll be hiring a designer/front-end engineer and a video expert for hardening the node. Additionally, we’re planning on contracting out bounties and collaborating with other projects in the ATProto and Livepeer ecosystems on projects like code generation and SDK development to start to make Streamplace technology as accessible as possible.
Infrastructure Enhancement
- Servers and Scaling: It’s imperative that we deliver a great first impression to this community, and that means scaling up to handle demand and expanding our server infrastructure.
- Performance Hardening: Veterans of Livepeer Studio know there’s a huge gulf between something that mostly works and a battle-hardened piece of video infrastructure. It’s imperative that we deliver a great first impression; decentralized social needs to work at least as well as existing.
- Reliability Testing: Ensure consistent performance under varying network conditions
Core Technology Development
- AT Protocol Integration: Develop deeper, more native integration with AT Protocol. Currently the integration is relatively shallow; a signing key on a users’ PDS links the two accounts. We’re aiming to assist in the development of the protocol.
- NPM Packages: Streamplace has been architected from the ground up to be embeddable in other apps but we haven’t yet actually shipped this capability. With the Skylight partnership we’ll be building out the capabilities to embed broadcast and playback within other apps and websites; other atproto apps have also expressed interest.
- Clipping and VOD: Build decentralized video-on-demand capabilities (beyond Bluesky’s current 3-minute limit)
- Transcoding Infrastructure: Support increased transcoding demand from Skylight users via Livepeer Network
Trust & Safety
- Moderation Systems: As part of the Skylight launch, we will be building out a full content moderation infrastructure, utilizing AI models backed with human moderators. This kind of thing isn’t always emphasized in the Web3 space, but it’s essential to comply with mass market adoption.
- Community Standards: We plan on developing transparent guidelines aligned with decentralized values.
Growth & Sustainability
- Stream Incentives: Programs to encourage creators to use the platform
- Monetization Framework: Explore micropayment systems and creator revenue models in collaboration with others in the atproto space.
- Custom App Development: Our pitch to big Twitch streamers isn’t “switch from Twitch to Streamplace,” it’s “switch from Twitch to your own app, powered by Streamplace infrastructure.” This facilitates a direct relationship between creators and their fans, while the Streamplace layer still enables all the social features of a rich livestreaming platform - chat, hosting, and such.
Vision
We’re not just building a livestreaming platform—we’re establishing the infrastructure and primitives for an entire generation of video applications on decentralized social networks. Our ultimate goal remains unchanged: solving video for everybody, forever.
With your continued support, we can create something truly revolutionary: a creator-sovereign, open-source video layer that enables experiences on par with centralized platforms but aligned with the values of decentralization.
Thank you for considering this proposal. Let’s continue building the future of decentralized video together.
", replyCount: 28, views: 1472, likeCount: 77, datePosted: "Apr 12, 2025", lastActivity: "Apr 28, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Pre-proposal: Livepeer FrameWorks SPE Pilot phase", href: "https://forum.livepeer.org/t/2773", author: "By Marco van Dijk (@stronk)", content: "Livepeer FrameWorks SPE: Pilot phase
Author(s): The MistServer Team
Contact: developers@mistserver.org
Abstract
The FrameWorks SPE proposes to strengthen the Livepeer protocol by bridging the gap between transcoding infrastructure and real-world media applications.
This includes:
- Providing dedicated engineering resources to ensure stability, feature enhancements, automated testing and a clear & complete documentation.
- Providing onboarding and infrastructure support for teams building on Livepeer.
- Operating an independent, Livepeer-powered E2E media pipeline that validates new transcoding features in real-world deployments.
By focusing on low operating costs, easy integration and strategic partnerships, FrameWorks aims to provide a viable, scalable alternative to traditional full-service video providers.
This first phase serves as a pilot to build trust and credibility within the Livepeer ecosystem while keeping the initial funding request modest.
Mission
The media industry is highly complex. Building reliable, scalable streaming applications requires complex deployments and industry expertise.
Livepeer Inc has laid a robust foundation for decentralized video infrastructure. However, there remains a gap between what the network offers versus what video applications need.
This proposal builds on their achievements by addressing key areas where we can contribute with our expertise.
The MistServer team proposes a Special Purpose Entity to take ownership of maintaining and enhancing the transcoding pipeline, ensuring that node operators have the support, documentation, and features they need.
FrameWorks will also bridge the DevOps gap by offering an E2E media pipeline that businesses can directly integrate or self-host, rather than relying on Livepeer Studio for infrastructure, support or custom features.
Instead of replicating Studios’ high-complexity, full-service model, FrameWorks aims to build a scalable, low-overhead alternative aimed at easy integration with external business logic.
Result: A more stable, performant, and accessible transcoding pipeline for node operators and Livepeer-powered media applications.
Terminology
Some of these terms are not present in this pre-proposal, but can be helpful when browsing through the feature board.
- E2E media pipeline: Provides the core infrastructure for a full media pipeline. Including but not limited to: ingesting, processing, storing, and delivering video.
- Transcoding: The process of decoding a video stream, transforming it (resolution, bitrate, etc.), and encoding it for delivery or storage.
- Segmented Workflow: A process of breaking video streams into discrete segments for transcoding. A full segment is required before it can be transcoded by the network.
- Streaming Workflow: A continuous processing method where the video stream is sent in small chunks and immediately transcoded.
- Intel QSV: Intel’s “Quick Sync Video” hardware for video encoding/decoding, allowing efficient transcoding on Intel CPUs and GPUs.
- AV1: A royalty-free, high-efficiency video coding format which is gaining in popularity.
- Latency: In the context of Livepeer we consider the delay between the stream ingest at a Gateway node and receiving the transcoded frames back.
- Netint: Specialized hardware device for video transcoding.
- LPMS: Livepeer Media Server, the core transcoding library used within the Livepeer stack.
- FTE: Full Time Equivalent, indicates the amount of hours dedicated to a project. 1 FTE equals one fulltime employee, but could also be two people each contributing 0.5 FTEs worth of effort.
Structure
The MistServer Team leads the SPE, with Marco (stronk-tech.eth) acting as the primary decision-maker and point of contact.
The SPE is open to expand the core SPE team with additional applications from outside the MistServer team.
Structure
- Lead: Marco, long-time Orchestrator and MistServer maintainer.
- Core Team: MistServer maintainers with expertise in transcoding and live streaming.
- Open-Source Contributors: Developers in the Livepeer community who take on bounties.
- Advisors:
- Rick (
transcode.eth): AI SPE Lead. - Brad (
ad-astra-video.eth): AI SPE Engineer, also familiar with the transcoding codebase. - Josh: Livepeer Inc engineer with extensive experience with relevant code repositories (
LPMSandgo-livepeer). - Rich: Livepeer Ecosystem Growth Team
- Rick (
Responsibilities
- Core Team: Scoping out tasks, assigning bounties, conducting code reviews, and core development of the transcoding pipeline.
- DDVTech: The business entity of the MistServer team, responsible for hiring, team coordination, and administrative processes.
- Advisors: Provide strategic & operational guidance and brainstorming about potential solutions.
About the MistServer Team
The MistServer team is composed of experts in live streaming and media server technology. Our journey began in 2009 when we set out to build a better media server following the failure of a media-related project due to unreliable software. Since then, MistServer has become our core business, and we’ve dedicated our professional lives to advancing live streaming technology.
We bring over half a century of combined hands-on experience in live streaming and media server development, including experience managing streaming infrastructure (like Picarto).
This hands-on expertise positions us uniquely to lead the FrameWorks SPE and contribute meaningfully to the ecosystem.
Scope
The core responsibilities of this SPE include:
- Making the Livepeer transcoding pipeline more robust and competitive.
Adding codecs, adding device support, reducing latency and enhancing transcoding jobs with more parameters.
- Supporting node operators.
Identifying & addressing common pain points, like replacing the static session limit with smarter GPU load balancing and improving Gateway Documentation.
- Ongoing core maintenance
This is a task which also sees ownership from existing core contributors. The Transcoding SPE intends to jump in (wherever required) to assist with tasks like keeping the build pipelines up-to-date, rebasing the LPMS FFMPEG patches and fixing bugs or crashes.
- Research & integrations
The media industry landscape changes over time (slowly evolving). WebRTC and SRT are now common methods to transport media, but are unsupported by Gateway nodes.
These kind of features could also be supported by siderunning applications, like how WebRTC has limited support through go-livepeer’s MediaMTX integration.
This topic covers exploring enhancements to the Gateway with additional protocols or improving integrations with external applications.
- Expanding testing & QA practices
Implementing automated testing to ensure network stability and prevent regressions.
This includes writing feature-specific tests for each change we make, while also expanding coverage with additional regression or benchmark tests.
- Bridging the DevOps gap for media applications
Providing support to entities looking to build on the network as well as setting up an E2E media pipeline, making it easier for applications to integrate Livepeer-powered streaming without reliance on Livepeer Studio.
Any development work will of course be published open-source and under the Unlicense.
Phase 1: Pilot
Goals
- Gather pain points from Gateway and Orchestrator operators.
- Prioritize roadmap items to address critical gaps in the transcoding pipeline.
- Set up a transcoding bounty program.
- Scope out the E2E media pipeline.
- Cross off the first few items from the roadmap.
Timeline
March 2025:
- Set up operations and governance structure.
- Identify and re-prioritize key tasks for this quarter.
- Launch a bounty board for community contributions.
- Initial discussions on FrameWorks infrastructure.
April – July 2025:
- Engineering work on Q2 key tasks, explained in the roadmap below.
- Next phase planning: Identifying FTE needs and define the FrameWorks infrastructure roadmap.
Roadmap
We have published a feature board where anyone can request items, vote on priorities, and comment on issues.
The roadmap will be prioritized based on continuous conversations with node operators, as well as the needs of inbound opportunities for our E2E media pipeline.
Initial Q2 goals are:
- Improve documentation for Gateway operators.
- Pull Netint integration over the finish line.
- Pull AV1 codec support over the finish line.
- Add Intel QSV support.
- Smarter session limits & load balancing for transcoders.
This roadmap indicates our short-term goals. Not all of these features might see completion in Q2.
Future Phases
If the pilot phase succeeds future requests may include:
- Expanding the core SPE team to increase engineering capacity.
- Addressing long-term goals and more complex tasks, including transitioning to a streaming workflow or expanding the Transcoding job type with more parameters (for example: allowing non-realtime, high quality transcodes for VoD processing).
- Further development & deployment of the FrameWorks E2E media pipeline.
Budget Breakdown
Funding Period: March – June 2025
Total Ask: 15,000 LPT
Breakdown:
| Item | Amount | Explanation |
|---|---|---|
| March: SPE Kickoff & onboarding | Free | Structuring the SPE, setting up communication channels, onboarding contributors, gathering feedback from Gateway & Orchestrator operators, initial design work on the E2E media pipeline. |
| April – June: Core Development | 12000 LPT | Managing bounties, active community participation, feature development, testing, and infrastructure work. |
| Community Incentives | 3000 LPT | Open-source contributor incentives to drive external contributions. |
Rate Justification
For 4,000 LPT per month, the MistServer team operates the SPE while providing 1 FTE of dedicated engineering work. At $5 per LPT, this equates to $20,000 a month (~$115/hr), which is a reduced bulk rate for long-term commitments. This ensures that developers assigned to the SPE remain fully committed, without being pulled into other commercial projects.
If future proposals require additional engineers, we can use the DDVTech entity to hire freelancers or full-timers. This approach allows us to:
- Offer security & guarantees to SPE hires through an established legal entity, of course with access to our office and team’s expertise for onboarding.
- Provide additional engineering capacity at a lower cost, ensuring efficient use of treasury funds.
We are open to adjusting the LPT request or FTE commitment based on community feedback, but believe the amounts are fair given the technical expertise required and in comparison with common rates in the media industry.
Success Metrics:
Defining success metrics for a broad core-development SPE like this is difficult. We encourage feedback on what we can do to measure impact and ensure accountability.
-
Core Contributions:
- Completed bounties.
- PRs submitted and merged into the Livepeer codebase.
- Increase in test coverage.
-
Feedback & Adoption:
- Positive feedback from Gateway & Orchestrator operators.
- Growth in the number of Gateway operators on the network, onboarded through the FrameWorks SPE.
- Transcoded minutes on the E2E media pipeline.
Transparency and Accountability
Engagement with protocol participants is an important part of this SPE. We will work closely with Gateway & Orchestrator operators to collect issues or requests to put on the feature board. We gather community input through multiple channels:
- Discord threads & forum discussions.
- a Canny task board to track development progress, request items or discuss tasks.
- Titan’s weekly water cooler sessions.
Leftover LPT will roll over into future proposals or return to the treasury if the SPE disbands for any reason.
Reporting:
- Quarterly progress reports will include:
- Amount of LPT spent, staked, or held.
- Progress on any of the success metrics.
", replyCount: 18, views: 842, likeCount: 52, datePosted: "Feb 22, 2025", lastActivity: "Mar 17, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Telegram Bot: Transcoder-Watcher", href: "https://forum.livepeer.org/t/609", author: "By vires-in-numeris (@vires-in-numeris)", content: "
Over the past few days, I’ve been further developing the Transcoder Watcher Bot running in my 0x525 Transcoder Telegram Channel. It was my goal to create a tool that everyone can use to get notified about transcoder events and here it is:
The Telegram Transcoder-Watcher Bot!
You can find the bot here: https://t.me/TranscoderWatcher_bot
What does it do?
By writing “/start”, the bot will give you an introduction and informs about the available commands:
- subscribe
- remove
- subscriptions
- history
details here: Telegram Bot: Transcoder-Watcher
If you subscribe to a transcoder (or multiple, there is no limit), you will get notified about the following events:
- reward calls
- missing reward calls
- reward cut changes
- transcoder becomes inactive
Whenever possible, I include the transaction link so you can be sure that no incorrect information is sent. However, please note that the bot is still in the testing phase and of course it’s always possible that the script crashes and the bot stops working.
How does it look like?
Here are some screenshots for the various events.
- Reward Calls:
- Missing Reward Calls:
- Reward Cut changes:
- Transcoder becomes inactive:
If you discover any error or have feature requests, you can reply here or send me a message on discord!
", replyCount: 16, views: 5777, likeCount: 16, datePosted: "Mar 21, 2019", lastActivity: "Mar 8, 2026", categoryId: 7, categoryName: "Transcoders", categoryColor: "#25AAE2" }]; export const forumData = [{ title: "RFP — Delegator UX Analysis (Self-Custody vs. Custodial Staking)", href: "https://forum.livepeer.org/t/3254", author: "By Rick (@rickstaa)", content: "Budget Envelope: Up to $10,000 USD equivalent
Date Issued: 2026-05-14
Issued By: Rick Staa
1. Purpose
Objective
Analyse the Explorer’s delegation UX against the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) and comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX sets the bar for user expectations. Produce a design-ready specification for a self-custody delegation experience that could compete or pull users away from the path of least resistance of holding on an exchange, thus preserving the direct protocol participation that makes self-custody valuable: governance rights, earnings transparency, and independence from custodial intermediaries.
Problem Statement
Livepeer’s on-chain delegator count has fallen ~36% over two years, but total staked LPT and participation rate have held steady or grown. The gap is explained by a structural shift: centralised exchanges are delegating growing pools of custodial LPT without any user-facing staking product. No major exchange such as Binance, Coinbase, or Kraken offers LPT staking. The delegation is happening without user involvement.
The Explorer’s delegation flow needs to be compelling. Simply holding LPT on an exchange while the exchange stakes it without their involvement results in centralisation that undermines the network. We want actively grow delegators and direct governance participation.
We need to:
- Precisely quantify the UX gap between the Explorer’s delegation flow and the top staking UX standard set by major exchanges and comparable PoS tokens
- Identify the specific design and information-architecture changes that would improve self-custody delegation
- Produce a shippable design brief the Foundation can convert directly into build work (retro grants or follow-on RFP)
Desired Outcome
Within 3–4 weeks, we have:
- A competitive teardown showing exactly where and why the Explorer’s delegation experience falls short of the standard set by exchange staking UX or other ecosystems at each step of the journey
- A design-ready specification for a “minimum competitive staking experience” in the Explorer
- A prioritised backlog of improvements with expected impact and effort that can be shipped as follow-on work
2. Requirements
Key Deliverables
- Competitive teardown
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
Dimensions: steps-to-stake, time-to-stake, information architecture, trust signals, yield presentation, risk framing, reward monitoring, and unstaking/exit experience (including offboarding from custodial products to self-custody: withdraw/transfer out). Each comparison should include annotated screenshots or screen recordings documenting the full flow. - Secondary analysis (decentralised staking UX): Review of the best delegation and staking experiences across decentralised protocols, including but not limited to Lido, Rocket Pool, Cosmos/Keplr and/or other PoS ecosystems with strong delegator UX. This analysis should identify the UX patterns, information design, and onboarding flows that make these experiences work. What can we learn from the best decentralised staking UX?
- Primary analysis (external competitive frame): Side-by-side comparison of the Explorer delegation flow vs. the staking experiences offered by major exchanges (Binance, Coinbase, Kraken) for comparable PoS tokens. No major exchange currently offers a user-facing LPT staking product, but their staking UX for other tokens sets a standard users expect.
- Standardised baseline scenarios (for comparable measurement)
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Scenario A (Fiat start): new user starting from fiat → staked/delegated
- Scenario B (Funds already on exchange): user already has funds on exchange → staked/delegated
- Include at least one concrete comparison like “What does it take to get $100 → staked LPT?” (time, steps, fees, failure points) across platforms.
- Use the same comparison dimensions as in the Competitive Teardown above, and explicitly quantify total fees, under consistent starting states:
- Gap specification
- Map each identified UX gap to a specific Explorer screen, flow, or missing feature
- Classify gaps by severity (blocking, friction, polish) and estimated effort (small / medium / large)
- Highlight the gaps that most plausibly explain the shift toward custodial staking
- Design brief: “Permissionless staking experience”
- What would a new user need to see and do in the Explorer to choose self-custody delegation over leaving LPT on an exchange?
- Wireframes or annotated flow diagrams (not just a written list) for the redesigned delegation journey
- Cover: discovery/landing, orchestrator selection, delegation execution, earnings monitoring, and re-delegation/exit
- Address the specific trust and clarity signals that custodial services provide and the Explorer currently lacks (yield clarity, risk framing, earnings visibility)
- Instrumentation plan
- What events and metrics need to be tracked to measure delegation conversion going forward
- Minimal and implementable, scoped to what can be added to the Explorer’s existing codebase without major infrastructure changes
- Propose a baseline measurement approach so future UX improvements can be evaluated
- Prioritised backlog
- Top 10–15 improvements ranked by: expected impact on self-custody delegation competitiveness, implementation effort, and dependency chain
- Clear split: quick wins (shippable via retro grants) vs. larger items (follow-on build RFP)
- Each item should reference the competitive teardown evidence that motivates it
Out of Scope
- Diagnosing why delegator count is declining (recent analysis confirms stake is centralising because exchanges are delegating custodial holdings, not because users are opting into custodial staking products)
- Implementing UX changes (this is an analysis + design specification scope)
- Protocol-level changes to staking mechanics (separate governance process)
- Large-scale design-system restyle work
- General-purpose user research unconnected to the competitive comparison
- Outreach / conversion strategy to migrate exchange-delegated LPT toward Explorer-based self-custody delegation (higher earnings, voting rights, orchestrator choice).
- Arbitrum liquidity readiness for sustained new stake originating from fiat — does the contributor see any concerns from the journey/teardown research?
Definition of Done — by Tranche
| Tranche | % Budget | Unlocks On |
|---|---|---|
| 1 — Signing | 25% | Audit plan agreed, competitive teardown scope confirmed (which services, which dimensions), kickoff doc filed |
| 2 — Delivery | 50% | Competitive teardown delivered, gap specification delivered, design brief with wireframes delivered, instrumentation plan delivered |
| 3 — Impact | 25% | Prioritised backlog accepted by Review Team after a public comment window (≥7 days) on the forum, with community feedback/reaction explicitly weighed as part of acceptance. At least 3 items converted into follow-on work (retro grants or RFP scope) within 30 days of acceptance. |
3. Capabilities Required
Skills
- Product design and UX analysis (competitive teardowns, information architecture)
- Ability to produce wireframes or annotated flow diagrams (Figma, or equivalent)
- Familiarity with web3 wallet interaction patterns and staking UX conventions
- Experience analysing decentralised protocol UX (delegation flows, validator/orchestrator selection, reward mechanics)
- Ability to read a modern web codebase (Explorer is React/Next.js) enough to assess instrumentation feasibility
Knowledge
- How centralised staking services (Binance, Coinbase, Kraken) present yield, risk, and onboarding to retail users for comparable PoS tokens
- How decentralised staking ecosystems (Cosmos/Keplr, Lido, Rocket Pool or others) handle delegator onboarding, validator discovery, and earnings transparency
- Livepeer delegator mechanics (L1/L2 bridging, orchestrator selection, reward cuts, bonding/unbonding)
- Web3 onboarding friction points and trust/risk communication patterns
Attitude
- Evidence-first: every recommendation grounded in the competitive comparison, not opinion
- Design-oriented: outputs should be visual and specification-ready, not just written analysis
- Comfortable working in public and with async feedback from the Foundation team
4. Proposal Requirements
Please include:
- Contributor / Team Overview
- Why you’re a fit (prior UX competitive analysis, staking product design, or delegation UX work)
- Approach & Timeline (mapped to tranches above)
- Which competitive services you will analyse (primary: Binance, Coinbase, Kraken staking UX for comparable PoS tokens; secondary: best-in-class decentralised staking/delegation experiences, e.g. Lido, Rocket Pool, Cosmos/Keplr or others you propose)
- Design output format (Figma, annotated screenshots, other)
- Pricing breakdown
- Conflict of interest disclosure
5. RFP Timeline
| Milestone | Date |
|---|---|
| RFP Posted | 2026-05-18 |
| Application Deadline | 2026-05-24 |
| Decision Announced | 2026-05-29 |
| Project Start | 2026-06-01 |
| Expected Completion | 2026-07-03 |
6. Proposal Submission Instructions
Reply to this forum post in the comments with your proposal (linking a doc or including it inline).
Questions: reach out to @rickstaa on Discord.
7. Decision & Governance
Selection criteria:
- Quality and specificity of competitive analysis approach, and do they understand what makes exchange staking UX set user expectations, and why users default to holding on exchanges?
- Demonstrated ability to produce design-ready specifications (wireframes, annotated flows), not just written reports
- Practical instrumentation plan that respects the Explorer’s current technical constraints
- Speed and clarity of execution
Introduction
With the Clarity Act getting closer to realization I’ve been pondering which protocols will benefit the most. Obviously the act has not passed and therefore, nothing is guaranteed or set in stone. However, based on the current language of the act, tokens with real utility, high levels of decentralization, and strong community will be categorized as digital commodities. Based on this language I believe Livepeer is safe. Livepeer’s utility is undeniable and may serve as a solution to the technology industry’s biggest problem. Resource intensive infrastructure.
The Problem
Centralized compute providers are relying on massive datacenters that require a ton of energy and cooling that only increase with demand. This creates negative sentiment around not only the data centers, but the deployments those data centers support, which right now leans heavily into AI and ML.
The Solution
Livepeer NaaP could potentially be the industry’s saving grace. While we don’t think about it every day, because of our immediate access to it, fresh water, energy, and land are all critical resources. As demand for compute continues to grow, so does the need for efficient ways to handle that demand.
Livepeer’s ability to provide compute for resource intensive use cases can help redistribute some of that demand across node operators that don’t necessarily rely on water intensive cooling infrastructure. If centralized providers continue to scale data centers aggressively, especially in drought stricken areas, governments may eventually step in to regulate resource usage, forcing providers to think differently about how cloud based software is deployed.
Decentralized networks like Livepeer offer a solution. Instead of concentrating compute in a few large facilities, workloads can be distributed across orchestrators using existing hardware that is far less reliant on our extremely valuable land, lakes, and rivers.
Conclusion
I am not saying decentralized compute or Livepeer replaces data centers, but acts as an environmentally friendly solution to handle growing demand through decentralized compute distribution. If Livepeer can capitalize on this specific issue, the protocol may help offset resource consumption. Potentially reducing the need for hundreds of millions to billions of gallons of water usage, and hundreds of acres of would-be datacenter land over time.
The Clarity Act favors real utility and decentralization. Livepeer is the definition of real utility and decentralization. With engineers working hard around the clock to increase the network’s accessibility, capabilities, and transparency, Livepeer is well positioned to solve or help alleviate the biggest problem our future generations will face.
GO LIVEPEER!
", replyCount: 0, views: 42, likeCount: 3, datePosted: "May 21, 2026", lastActivity: "May 21, 2026", categoryId: 6, categoryName: "Protocol", categoryColor: "#BF1E2E" }, { title: "WEAVE Growth SPE: Updates", href: "https://forum.livepeer.org/t/3239", author: "By DeFine (@DeFine)", content: "Hey everyone,
Wanted to share some updates on WEAVE as we get into Month 1 execution. There’s a team change, a budget adjustment, and some governance work happening.
SPE Naming
To align SPE naming with mission objectives, the WEAVE proposal deliverables are being operated now under WEAVE Growth SPE. Embody SPE stays its own thing, focused on embodied agent workloads. The broader roadmap lives under WEAVE Growth SPE.
Team Structure Updates
Dane decided to move on from WEAVE for personal reasons, and we parted on good terms.
Dane built the Unreal Engine avatars and most of the game UI that powered our PixelStreaming workloads. He was dedicated, hardworking, and consistently showed up when it counted. He overdelivered on his initial Embody deliverables and brought the game to a mature, production-ready state. The game builds he produced are what the Embody workloads ran on. We’re genuinely grateful for his contribution and wish him all the best going forward.
On the IP side, Dane has committed to granting the WEAVE Growth SPE entity a perpetual, royalty-free license to the source code with sub-licensing rights, allowing us to use, modify, and sublicense it as needed. The source can’t be MIT because of third-party plugin restrictions, but the license covers us fully. The packaged game goes MIT, same as all future Embody releases. We will follow up with Dane on the necessary actions and paperwork to make sure this is properly finalized. This development makes sure that the source code will become an other asset for the growth of Livepeer and ensures that Dane’s departure does not compromise our ability to create future workloads using Unreal Engine.
Budget
We will discuss actively with the community to make sure that the SPE acts according to stakeholder intent to decide what will happen to the funds that where earmarked towards Dane’s compensation.
Governance and transparency
We are currently discussing with the team the creation of a lightweight legal entity with non-profit operating provisions, where financial reporting and management obligations would be written into the founding documents themselves. The entity will operate with strict non profit provisions for the benefit of the whole Livepeer ecosystem and will possess ownership of the financial(incentives) and IP assets(unreal engine game, weave website, etc..) of the SPE.
What that looks like: budget, spending, and compensation reported publicly. Governance processes published online, how decisions get made, how workloads get evaluated, how incentive packets get managed. All incentive programs will run in the open with published criteria, schedules, and outcomes.
We’re still working out the exact structure, reporting format, and cadence with the team. Once that’s decided, we’ll share it publicly.
Month 1 Deliverables
You can find the month 1 deliverables spec bellow, we are currently finalizing this before posting the final version. Any feedback welcome.
Deliverables spec doc
WEAVE Growth SPE — Month 1 Deliverables
Version: v0.2 (April 2026)
Owner: DeFine
Technical Reviewer: Rick
Completion Rule: No deliverable is complete until Rick signs off on its evidence pack.
Month 1 Operating Logic
The dependency chain is:
- M1-D1 builds the open-source WEAVE Tool.
- M1-D2 exposes that capability through the DAO-operated hosted WEAVE App + API.
- M1-D3 activates the incentive loop that drives workflow creation and app creation.
- M1-D4 proves publicly what users did, what converted, and what became monetization-ready.
Month 1 completion is based on whether this machine exists, is live, and is measurable. Raw demand volume is a KPI outcome, not the sole approval condition.
M1-D1 — Open-source WEAVE Tool
Description: A public, open-source, self-hostable WEAVE Tool that lets any technical user create Scope .json workflows, run viability research, run QA, and extend the system independently. This is the core product layer, not the hosted WEAVE service.
Outcome: By end of Month 1, a technical user can take the WEAVE Tool repo, follow the docs, generate valid workflows, inspect viability + QA outputs, and adapt the tool for their own API or webapp if they choose.
Excludes: Hosted uptime, DAO-run API reliability, user onboarding/account systems, and incentive logic.
Sub-deliverables
M1-D1.1 — Public repo and licensing live
| Criteria | Done? |
|---|---|
| Repo is public | |
| License file is present | |
| README covers setup, architecture, usage, and extension points | |
| Example assets or example outputs are included or linked |
Evidence: Public repo URL, license file, README, architecture note.
M1-D1.2 — Workflow creation engine works
| Criteria | Done? |
|---|---|
Tool can generate valid Scope .json workflows | |
| At least 3 materially distinct workload classes are supported | |
| Each class has a reproducible example output | |
| Export path for generated workflows is documented |
Evidence: 3 exported .json outputs, supported workload list, reproduction notes.
M1-D1.3 — Commercial viability module integrated
| Criteria | Done? |
|---|---|
| Workflow creation includes an explicit viability-assessment step | |
| Viability output is generated inside the tool | |
| Output includes target user, use case, monetization path, market rationale, and build/no-build reasoning | |
| Viability output is saved or exportable alongside the workflow artifact |
Evidence: UI or CLI artifact showing the viability step, 3 example analyses, output schema.
M1-D1.4 — QA module integrated
| Criteria | Done? |
|---|---|
| QA stage exists inside the tool flow | |
| QA returns pass/fail or a structured issue list | |
Checks cover valid .json structure, required fields, runnable shape, and broken-config detection | |
| At least 1 failed QA case is demonstrated |
Evidence: QA checklist/spec, pass artifacts, fail artifact, output examples.
M1-D1.5 — Self-hostability proven
| Criteria | Done? |
|---|---|
| Fresh setup can be completed from the published docs | |
| Tool runs without requiring the hosted WEAVE App/API | |
| A technical user can extend or wrap the tool for their own API or webapp | |
| No WEAVE-managed account is required to use the core tool |
Evidence: Self-host setup note, fresh-run proof, extension or wrapping example.
Evidence Pack for Rick Review
- Public repo URL
- License file
- README + architecture note
- 3 sample workflow outputs
- 3 viability outputs
- QA pass/fail artifacts
- Self-host proof
M1-D2 — Hosted WEAVE App + API Access Layer
Description: The DAO-operated, free hosted access layer for WEAVE. This is the managed WEAVE App and public API that use the WEAVE Tool underneath so users can access WEAVE services without self-hosting.
Outcome: By end of Month 1, a user can complete the workflow-creation path through the hosted WEAVE App or API, view viability + QA outputs, and move from workflow creation into app creation without local deployment.
Excludes: Open-source licensing proof for the core tool, standalone self-host proof, and incentive policy itself.
Sub-deliverables
M1-D2.1 — Free hosted WEAVE webapp live
| Criteria | Done? |
|---|---|
| Public URL loads successfully | |
| User can complete workflow creation end-to-end through the webapp | |
| Viability and QA outputs are visible in the hosted flow | |
| Workflow output is viewable and exportable |
Evidence: Public URL, screenshots, end-to-end web demo recording.
M1-D2.2 — Public API live
| Criteria | Done? |
|---|---|
| API endpoint(s) are publicly reachable | |
| API docs are published | |
| Workflow creation, viability, and QA are available via API | |
| At least 1 successful API-created workflow is demonstrated |
Evidence: API base URL, API docs, example request/response, API demo artifact.
M1-D2.3 — Hosted surface is clearly downstream of D1
| Criteria | Done? |
|---|---|
| Hosted outputs use the same core workflow format as the WEAVE Tool | |
| Relationship between D1 and D2 is documented publicly | |
| Hosted access policy is stated | |
| Free access terms or limits are stated |
Evidence: Public note on tool vs hosted surface, access policy doc, parity note.
M1-D2.4 — Workflow-to-app creation path live
| Criteria | Done? |
|---|---|
| User can move from workflow creation into an app-creation path through the hosted surface | |
| This path is exposed in the webapp and documented in the API flow | |
| At least 1 example app-creation flow is demonstrated | |
| Output from this step can be used in the incentive system |
Evidence: App-creation demo, UI/API docs, example artifact.
M1-D2.5 — No-self-hosting path demonstrated
| Criteria | Done? |
|---|---|
| A user can complete the hosted flow without local deployment | |
| A web-based end-to-end demo exists | |
| An API-based end-to-end demo exists | |
| The hosted path is usable by a non-technical participant |
Evidence: Web demo, API demo, hosted-path walkthrough.
Evidence Pack for Rick Review
- Public webapp URL
- Public API docs URL
- Tool-to-hosted parity note
- Web demo recording
- API demo recording
- Example workflow artifact
- Example app-creation artifact
M1-D3 — Incentive Program Launch
Description: The live WEAVE incentive system that moves users from registration to workflow creation to app creation, with identity-gated enrollment to reduce bot/sybil spam. Phase 1 rewards support workflow and app creation. Phase 2 rewards unlock only after an app proves quality, monetization, and electronic payment readiness.
Outcome: By end of Month 1, incentive registration is live, users can enroll from both the WEAVE Tool and the WEAVE App, Phase 1 rewards are active, and the Phase 2 unlock rules are explicit and operational.
Sub-deliverables
M1-D3.1 — Incentive rules and governance published
| Criteria | Done? |
|---|---|
| Public incentive rules document exists | |
| Phase 1 and Phase 2 are defined separately | |
| Participant types and eligible actions are defined | |
| Calculation method and cadence are defined | |
| Dispute and exception handling path is defined |
Evidence: Public rules URL, version/date, example calculation, dispute policy.
M1-D3.2 — Worldcoin-gated registration live
| Criteria | Done? |
|---|---|
| Incentive enrollment path is live | |
| Worldcoin verification is required before incentive participation | |
| Anti-spam / anti-sybil rules are published | |
| At least 1 successful registration is evidenced |
Evidence: Enrollment URL, verification screenshots, policy note, first successful registration artifact.
M1-D3.3 — Dual onboarding paths live
| Criteria | Done? |
|---|---|
| User can enter the incentive system from the WEAVE Tool path | |
| User can enter the incentive system from the hosted WEAVE App path | |
| Differences between self-hosted and hosted participants are documented | |
| Both paths feed the same KPI/reporting surface |
Evidence: Tool-path walkthrough, app-path walkthrough, onboarding documentation.
M1-D3.4 — Phase 1 rewards active
| Criteria | Done? |
|---|---|
| Phase 1 rewards are live during Month 1 | |
| Workflow creation is a qualifying action | |
| App creation is a qualifying action | |
| Incentive window and cadence are publicly stated |
Evidence: Launch announcement, rules excerpt, active incentive window proof.
M1-D3.5 — Phase 2 activation gate defined and testable
| Criteria | Done? |
|---|---|
| Phase 2 activation criteria are published | |
| Criteria require proof of quality standards | |
| Criteria require proof of monetization | |
| Criteria require ability to accept electronic payments | |
| A qualifying evidence template or checklist exists |
Evidence: Phase 2 rules section, qualification checklist, sample evidence packet.
M1-D3.6 — First live cycle operational
| Criteria | Done? |
|---|---|
| Weekly calculation or review runbook exists | |
| First cycle calculation artifact is produced | |
| At least 1 real participant moved through registration → action → calculation | |
| Exception/dispute handling is usable |
Evidence: Runbook, first cycle artifact, participant flow proof, exception log template.
Evidence Pack for Rick Review
- Public incentive rules URL
- Worldcoin-gated registration proof
- Tool-path and app-path onboarding proofs
- Phase 1 live-window proof
- Phase 2 qualification checklist
- Weekly runbook
- First cycle calculation artifact
M1-D4 — Public KPI / Reporting Surface
Description: The public reporting layer that shows whether WEAVE is actually acquiring users, helping them create workflows, converting those workflows into apps, and moving those apps toward quality and monetization readiness.
Outcome: By end of Month 1, the public can verify acquisition, production, quality, monetization-readiness, and workflow-to-app stickiness from a live KPI/reporting surface.
Sub-deliverables
M1-D4.1 — Public KPI surface live
| Criteria | Done? |
|---|---|
| Public URL exists | |
| Metric definitions are visible | |
| Update cadence is stated | |
| Current snapshot is visible |
Evidence: Public dashboard/report URL, screenshots, metric definitions.
M1-D4.2 — Acquisition metrics live
| Criteria | Done? |
|---|---|
| New users are counted publicly | |
| Incentive-verified registrations are counted publicly | |
| Tool-path vs app-path acquisition can be distinguished or derived | |
| Reporting window is stated |
Evidence: KPI surface screenshot, acquisition methodology note.
M1-D4.3 — Production and completion metrics live
| Criteria | Done? |
|---|---|
| Workflows started are counted publicly | |
| Workflows completed are counted publicly | |
| Incentive completions are counted publicly | |
| Apps created are counted publicly |
Evidence: KPI surface screenshot, metric definitions, sample snapshot.
M1-D4.4 — Quality and monetization progression metrics live
| Criteria | Done? |
|---|---|
| Apps crossing the quality threshold are counted publicly | |
| Apps that are monetization-ready are counted publicly | |
| Apps that can accept electronic payments are counted publicly | |
| Phase 2-eligible apps are counted publicly |
Evidence: KPI surface screenshot, methodology note, status definitions.
M1-D4.5 — Stickiness / progression metrics live
| Criteria | Done? |
|---|---|
| Workflow-to-app conversion metric is defined | |
| Post-action stickiness metric is defined | |
| Repeat builder activity or return behavior metric is defined | |
| Measurement window and method are published |
Evidence: KPI definitions, methodology note, example snapshot.
M1-D4.6 — Public reporting artifacts published
| Criteria | Done? |
|---|---|
| Weekly report template exists | |
| First public KPI snapshot/report is published | |
| Caveats and methodology are published | |
| Reporting owner/update cadence is named |
Evidence: Report template, first snapshot/report, methodology doc.
Evidence Pack for Rick Review
- Public KPI/dashboard URL
- Metric definitions
- Acquisition, production, and conversion screenshots
- First public report or snapshot
- Methodology / caveat note
Month 1 KPI Targets
These are operating targets, not the sole completion gate. Month 1 approval depends first on whether the system is live, reviewable, and measurable.
| KPI | Month 1 Target |
|---|---|
| New verified incentive users | 10+ |
| Workflows started | 10+ |
| Workflows completed | 5+ |
| Apps created | 3+ |
| Phase 1 incentive completions | 3+ |
| Apps reaching quality review | 1+ |
| Apps reaching monetization readiness | 1+ |
| Workflow-to-app stickiness | 25%+ of workflow completers start an app path |
| Public KPI snapshots/reports published | 1+ live snapshot and weekly cadence defined |
Rick Review Gate
Rick signs off separately on each deliverable:
- M1-D1 technical completeness of the open-source WEAVE Tool
- M1-D2 hosted operability of the WEAVE App + API
- M1-D3 correctness and operability of the incentive mechanism
- M1-D4 correctness and integrity of the public KPI/reporting surface
| Deliverable | Evidence Submitted | Rick Status | Final |
|---|---|---|---|
| M1-D1 Open-source WEAVE Tool | |||
| M1-D2 Hosted WEAVE App + API | |||
| M1-D3 Incentive Program Launch | |||
| M1-D4 Public KPI / Reporting Surface |
Livepeer Inc Daydream Product Update
Hi all. I wanted to provide a product update from Livepeer Inc so that the community could see all that’s being built as we focus on Livepeer’s Realtime AI infrastructure opportunity.
Much of this information is available by following along on the Daydream X Account, the Daydream Discord, and the Scope release notes, but is summarized here for the Livepeer community.
Daydream
As you know, Livepeer Inc is primarily focused on finding demand for the Livepeer Network’s realtime AI capabilities through the Daydream brand. Realtime AI video is an early space where Livepeer is suited to offer unique value because of its GPUs and low latency streaming stack, expertise, and ecosystem alignment - however the arrival of the market remains dependent upon when key open source model capabilities drop that are acceptable to enterprise grade commercial use cases.
Because of the early state of the market, Daydream has developed an open source community oriented workflow management tool called Scope.
Scope is a local-first, open-source engine for real-time AI generation across video, audio, and computer vision. Creators compose custom pipelines visually, plug into their existing tools, and run inference on their machine or in the cloud via the Livepeer Network.
It incorporates the latest realtime AI models, lets users configure them into custom workflows we pre-and-post-processors, LORAs, audio + video input sources and outputs, and more. The early tinkerers and researchers in this market are using Scope to get access to, and control, the latest innovations in the space. And as more mainstream usable models arrive, this foundation will be the best control plane to get the outputs that users want. Here are some of the latest features to ship.
- Real-time video compositing powered by VACE. Edit and transform live video with inpainting, outpainting, and style transfer running at interactive framerates. This is continuous inference, not asynchronous generation. Every frame goes through the pipeline.
- Node-based workflow builder. Build custom AI pipelines by connecting nodes visually, spanning generative video, audio, and computer vision. A new scheduler node lets you fire timed triggers across the graph, and the canvas UX is designed to get you from zero to running workflow fast.
- Remote inference via the Livepeer Network. Scope offloads GPU-heavy workloads to the cloud rather than requiring a local 4090. Artists and developers without high-end hardware become direct network consumers. This is the link between Scope adoption and Livepeer demand.
- Plugin architecture for community-built nodes. The v0.2.4 release introduced a node abstraction system that lets anyone ship a custom Scope plugin. Initial examples include a YouTube input source and a local LLM prompt enhancer. The ecosystem is just getting started.
- LoRA style control. Apply and blend LoRAs for fine-grained aesthetic control, from subtle adjustments to full style transforms. Scope handles LoRA manifest resolution as part of workflow configuration.
- Shareable, importable workflows. Export and import full pipeline configurations, including LoRA manifests and dependency resolution. This makes community sharing practical and lowers onboarding friction for new users finding Scope through Daydream.live.
- Beat-synced parameter modulation. Parameters sync to Ableton Link and MIDI clock, making Scope viable for live performance where timing matters. OSC support extends reactive control to any tool that speaks the protocol.
- Integrations for professional creative tools. Scope connects to TouchDesigner (including the StreamDiffusionTD plugin by dotsimulate’s Lyell Hintz), Resolume, and other creative software via NDI, Spout, Syphon, OSC, and MIDI. This is where Scope reaches the communities most likely to run persistent, high-throughput inference on the network.
- Audio generation alongside video. Pipelines can return audio alongside video output, streamed over WebRTC. Scope is no longer a video-only tool.
- LTX-2 video model with ~18x faster loading. The latest LTX-2 integration ships with real-time pacing controls, faster model loading, faster prompt changes, and Ampere GPU compatibility. New users get text-to-video out of the box.
- MCP server for agentic workflows. Scope exposes an MCP server interface, connecting it to AI agent frameworks. Early infrastructure for a category of agentic, real-time AI applications that could drive sustained inference demand on the network.
Realtime Audio Generation
While realtime AI video and world models remain interesting early prototypes, many of the users who are getting value out of Scope are overlapping with the audio space. Often times performers, VJs, musicians are using scope to generate visuals for live performances, concerts, or event installations, because Scope enables the AI outputs to respond to the audio inputs themselves. Naturally, this is leading to a lot of interest in integrations with audio tools (Resolume), and even generative audio generation itself.
More to come on this in a future update (or join the upcoming water cooler chats to see live demos), but the team has worked on some research breakthroughs to get audio generating in realtime using one of the previously batch-only open source models. This is a big break through that lets creators actually configure AI as an instrument that plays along or modifies songs in real time, responding to many different input or prompt changes instantly.
Video is early and requires some model and workthrough breakthroughs before being widely adopted, however this realtime audio generation is compelling and high quality enough to make an impact today. Look for some proof of concept applications coming soon to test driving demand to Livepeer through these channels.
The Path to the Livepeer Network
As with all new capabilities developed by within Inc, typically we first work on validating demand with early users through prototypes and early productionization of our products. Typically the fastest path here is using cloud infrastructure at low volumes so that the community doesn’t have to incur the work of adding support for new experimental capabilities if there’s no actual demand or market fit.
The next phase typically consists of Livepeer Network pilots, using self-run infrastructure on the network and working with select orchestrators willing to run these job types early as they’re developed, so that they can be built the right way.
Next you typically see scaled load testing and redudnancy/backup service provided by the network. The Inc products typically use the cloud for some traffic, and duplicate it to the network to evaluate its performance and realiability. Eventually shifting more and more to the network as its primary source of traffic. Why? Because the Livepeer network is typically far more cost effective than the cloud - and ultimately needs to be as reliable or better.
Finally Inc deprecates any cloud infrastructure entirely, and relies entirely on the network. This is the path that Studio went through in the early days, before relying solely on the Livepeer network for transcoding traffic. And it is the path that Daydream and Scope are undergoing as well. Currently Scope is routing traffic through the Livepeer network, and is onboarding select O’s to troubleshoot the integrations for popular workflows.
Livepeer Studio
With the focus on Daydream and the Realtime AI opportunity, Livepeer Studio continues to support existing customers, but is not primarily focused on growing further demand generation through transcoding or streaming. As previously communicated, we’re working with the Frameworks team to carry the torch on transcoding and a modern low latency streaming stack on top of the network, and pursuing demand generation efforts on that track. And Orchestrators will likely see transcoding volumes from Studio ramping down in the coming months..
Orchestrator guidance from a Daydream perspective
Daydream is trying its hardest to find Product-Market-Fit and drive scaled demand to the Livepeer Network! But as we remain early in that process across our ambitious bets, its important to note that many of these GTM efforts are experiments. New models and capabilities drop, each often times requiring different hardware. We are committed to bringing demand to the Livepeer network, and the best way for Orchestrators to support is to flexibly provision hardware in support of these experiments. That may mean spinning resourced capacity up and down as experiments ebb-and-flow. It likely does not mean over-investing in purchased dedicated hardware until it is clear there is scaled demand for a job. Orchestrators should share openly and honestly what pricing they need to charge in support of these experiments, and consider the impact of delegated stake and reward cuts on their P&L when doing so.
Thanks everyone. Looking forward to showing off some of the latest Scope and realtime AI capabilities on the upcoming water cooler chats.
", replyCount: 2, views: 136, likeCount: 12, datePosted: "May 6, 2026", lastActivity: "May 6, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "RFP — Explorer Maintenance", href: "https://forum.livepeer.org/t/3072", author: "By Rick (@rickstaa)", content: "Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rick Staa
1. Objective
Restore the Livepeer Explorer to a secure, maintainable, and high-performance state while laying the groundwork for new network-wide data and governance dashboards.
2. Problem Statement
The Explorer is the primary entry point for orchestrators, delegators, developers, and gateways. However, since December 2023 lack of ownership has accumulated significant technical debt:
- Outdated dependencies in the Explorer and design system, fragile under Node 20, break on updates and could lead to security risks, undermining long-term maintainability.
- Duplicated/obsolete code and missing contribution infrastructure (guidelines, CI/tests, stubs), making contributions slow and error-prone.
- Inefficient data fetching (e.g. Infura/Graph duplication), creating performance issues.
- A backlog of unmerged PRs and unresolved bugs (e.g., broken migration widget, UI inconsistencies, incorrectly displayed data).
A future roadmap for expanded network data and richer Explorer stakeholder experiences depends on first restoring a stable, secure, and maintainable Explorer. This RFP focuses on that critical first step.
3. Desired Outcome
Success means that within four months the Explorer is:
- Clean, well tested, with automated tests and continuous integration pipelines, providing a healthy, maintainable codebase.
- Free of critical bugs and stale pull requests, with a clearly organized issue backlog.
- Running on up-to-date, secure dependencies (Explorer and design system) fully compatible with the current Node.js LTS.
- Improved in performance, with faster page loads and a simplified, well-documented data layer for developers
- Equipped with a new voting-transparency feature integrated with the voting-tally subgraph.
- Backed by a clear 6-month roadmap and a dedicated maintainer team providing ongoing maintenance and timely support.
In short, the Explorer will be trusted infrastructure and ready to power further iteration of capabilities.
4. Deliverables
Within four months (target completion by February 1, 2026), the selected team will deliver the following milestone-based outcomes.
Each deliverable must be demonstrated in a Livepeer community call, and the team must provide public progress updates at least every two weeks (e.g., forum posts) throughout the project.
Payments are released only after each demo is accepted by the RFP owner.
(i) Establish Healthy Explorer Codebase
Goal: Deliver a clean, maintainable, and well-tested Explorer foundation to enable ongoing community contributions.
Requirements:
- Remove unused and duplicate code.
- Reorganize folder and module structure, where needed, to improve navigation and long-term maintainability.
- Add comprehensive unit and integration tests covering all critical user flows (e.g., staking, delegating, governance), with measurable coverage targets proposed by the vendor.
- Implement CI pipelines for reliable builds and automated checks.
- Ensure all components are fully typed (TypeScript) and all ESLint/TypeScript errors resolved.
- Provide clear contributor documentation and review workflow, with local-development stubs/mocks so the codebase can run without production environment variables.
Outcome: A clean, healthy, well-tested codebase with CI pipelines and local stubs that contributors can run with minimal setup, forming a solid foundation for future improvements.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the cleaned codebase, CI, tests, and contributor docs.
(II) Improve Data-Fetching Efficiency
Goal: Enhance the Explorer’s data layer to reduce latency, eliminate redundant calls, and ensure responsive, reliable performance for end users and contributors.
Requirements:
- Optimize subgraph and RPC data fetching to reduce latency, avoid duplication, and improve responsiveness.
Outcome: A faster, more efficient Explorer with reduced redundant calls and a simplified, well-documented data layer for easier future contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, showcasing faster data fetching and improved data-layer developer documentation.
(III) Resolve Critical UI Issues & Backlog
Goal: Eliminate high-impact bugs and stale pull requests to ensure a stable, accurate, user-friendly Explorer.
Requirements:
- Resolve all current critical UI bugs (GitHub bug list), including the delegator migration widget, data inaccuracies, and major UX defects, and triage/fix any new critical issues during the engagement.
- Review and merge, close, or supersede all open pull requests (GitHub pull requests) other than the voting-transparency feature (covered in Deliverable 5).
- Work with the Foundation and Advisory Boards to prioritize any other high-impact feature requests from the backlog that fit within the agreed budget and timeline.
Outcome: A more stable, accurate, and user-friendly Explorer with all critical issues resolved and a significantly reduced bug backlog, ready for ongoing community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting a detailed report of resolved bugs and key fixes, along with the cleaned and updated issue board.
(IV) Deliver Voting-Transparency Feature & Subgraph Integration
Goal: Provide clear, real-time visibility into on-chain governance participation.
Requirements:
- Finalize and deploy the voting-transparency feature, incorporating requested UI refinements and migrating data fetching to the voting-tally subgraph for improved performance, using feedback from the Foundation and Advisory Boards.
Outcome: A fully deployed voting-transparency feature integrated with the voting-tally subgraph and refined UI, offering accurate, real-time governance data.
Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the live voting-transparency feature.
(V) Establish Maintainability & Roadmap
Goal: Ensure the Explorer remains easy to maintain with a clear 6-month plan.
Requirements:
- Publish a 6-month feature/bug roadmap aligned with the Foundation’s Data Gap Analysis and community feedback.
- Provide contributor docs, maintenance practices, and an issue-tracking process (including a clean, well-labeled issue board).
Outcome: A documented maintenance framework and forward roadmap enabling smooth ongoing development and community contributions.
Demo Day: To be proposed by the team and agreed with the RFP owner, presenting the final roadmap and contributor maintenance guide.
(VI) Provide Ongoing Support & Post-Delivery Responsibility
Goal: Ensure professional post-launch support and continuity of maintenance, whether the same team continues or future maintainers take over.
Requirements:
- During the project, acknowledge critical bugs within 24–48 hours and resolve or mitigate them within a few business days (or faster per the proposer’s SLA).
- After delivery, provide at least a 60-day support window for critical fixes, security incidents, and knowledge transfer, meeting the proposer’s SLA.
Outcome: Stable post-launch operations with timely critical-issue resolution and clear processes for continued maintenance, regardless of who maintains the Explorer.
Payment: The team must present a support-readiness plan with defined SLA commitments, to be agreed with the RFP owner. Ninety percent of each milestone payment is released after acceptance of that milestone’s demo. The remaining ten percent of the total contract is held until the 60-day support period concludes and SLA commitments and resolution targets are met.
Out of Scope
To avoid confusion, the following items are not part of this RFP:
- A full UI/UX redesign or new visual styling of the Explorer.
- Major new product features beyond the initial voting-transparency integration.
- Broader data-gap mapping (handled by separate workstreams).
- Protocol/client changes or on-chain improvements to surface new data (managed through separate RFPs within the same workstream).
5 Capabilities required
Skills
- Strong front-end engineering in modern JavaScript/TypeScript (React/Next.js), including implementing and refining accessible UI components within an existing component library or design system.
- Proven experience with codebase modernization and maintainability—refactoring, setting up CI/CD pipelines, adding automated unit and integration tests, and enforcing TypeScript and ESLint standards.
- Ability to update and manage complex dependency stacks, including Node.js and modern package managers, while resolving breaking changes and configuring automated update tooling (e.g., Dependabot or Renovate).
- Proficiency in performance optimization and efficient data-fetching techniques, particularly with GraphQL/subgraph and RPC endpoints.
- Experience reviewing, triaging, and merging open-source pull requests and managing a clean, well-labeled issue backlog.
- Familiarity with monitoring and incident-response tools (e.g., Sentry, Bugsnag) to ensure production reliability.
Knowledge
- Understanding of the Ethereum/Web3 stack, including wallet flows, transactions, RPC providers, and common front-end pitfalls.
- Awareness of accessibility (a11y) best practices and secure front-end patterns such as dependency risk management and safe secret handling.
- Experience with open-source project governance, including contributor guidelines, code review workflows, semantic versioning, and changelogs.
- Familiarity with The Graph/subgraph architecture and GraphQL schemas (nice to have).
- Familiarity with the Livepeer protocol and current Explorer repository (nice to have).
Attitude
- Community-oriented and collaborative, engaging proactively with contributors, Advisory Boards, and Foundation stakeholders.
- Accountable and responsive, acknowledging critical bugs within 24–48 hours and working toward mitigation or resolution within a few business days.
- Documentation-first mindset, maintaining clear READMEs, runbooks, and migration notes to enable future contributors.
- Quality-driven and pragmatic, balancing rigorous testing, CI, and security with on-time delivery.
- Long-term stewardship, treating the Explorer as trusted infrastructure and designing for multi-year maintainability.
- Supportive and open, encouraging new contributors and fostering an inclusive contributor community.
- Mission-aligned, motivated to strengthen the Explorer as a cornerstone of the Livepeer ecosystem.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience – examples of large front-end refactors, dependency upgrades, CI/CD setup, performance optimization, or open-source project maintenance.
- Milestone Breakdown – a plan aligned with Section 2 deliverables, with proposer-set milestone dates and demo day schedules, each including clear outputs and payment tied to demo acceptance.
- Support & Maintenance Plan – proposed SLA commitments (e.g., response and resolution times), 60-day post-delivery support approach, and handover/knowledge-transfer strategy.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template.
7. RFP Timeline
Proposal Deadline: Wednesday 24th September 2025
Decision Announced: Friday 26th September 2025
Project Start: Wednesday 1 October 2025
Project Completion: Sunday 1 Feb 2026
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
@rickstaaon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rich O’Grady
1. Objective
Restructure, refresh, and modernize Livepeer’s documentation so that it is stakeholder-focused, AI-first, and future-proofed. It should cater to the core personas of the Livepeer project: developers, delegators, gateway operators and orchestrators.
2. Problem Statement
Current Livepeer docs suffer from:
- Complicated onboarding: User journeys (node operators, app builders, delegators, gateway providers) are hidden behind toggles instead of clear entry points.
- Outdated or inconsistent content: Deprecated APIs, stale references, incomplete AI coverage, and fragmented changelogs.
- Brand & duplication: Studio-specific guidance is mixed into core docs; AI SDKs and APIs are duplicated across gateways.
- Weak site integration: Poor linkage between website, explorer, governance portal, and docs. Too many Studio dashboard references.
3. Desired Outcome
Success is a single-source-of-truth documentation system that:
- Leads with clear stakeholder-focused onboarding and goal-oriented entry points.
- Cleanly separates AI Jobs vs Transcoding Jobs while still surfacing cross-cutting resources (SDKs, APIs, CLI, on-chain/network).
- Fully deprecates Studio content with redirects and zero broken links.
- Provides AI-first documentation: semantically structured, LLM-readable, with embedded natural language search/assistant.
- Consolidates changelogs and introduces versioning / deprecation tracking.
- Establishes a style guide, contribution model, and ownership playbook for consistency.
- Integrates seamlessly with the broader Livepeer ecosystem (website, explorer, governance, dashboards).
4. Deliverables
(i) Present New Documentation Strategy
Goal: Create a new outline for Livepeer documentation, including full map of current documentation, a clear information architecture and timeline for writing new documents.
Requirements:
- Identify core stakeholder groups (Livepeer Foundation, Livepeer Inc, AI SPE, Cloud SPE, Streamplace, Frameworks and more)
- Conduct of all docs pages with status recommendations across the 4 categories (Developers, Delegators, Orchestrators, Gateway Operators)
- Developers: clean up deprecated sections and plan integrations with new gateway products (Streamplace, Frameworks, Daydream and more)
- Orchestrators: simplify documentation to easy onboarding with plan for support in Discord.
- Delegators: integrate new video content to make it easy to delegate.
- Gateways: streamline documentation and workflows with support from the Foundation.
- Create plan for an updated sidebar, taxonomy, and breadcrumb structure.
- Consolidation of multiple changelogs into a single canonical feed.
- Onboard stakeholders to project management process
Outcome: A forum post detailing the new documentation to the community with a 1-week window RFC.
Demo Due Date: Friday 17th October
(ii) Re-Write Documentation
Goal: Systematically edit and rewrite new content to meet stakeholder needs with consistent accuracy and depth.
Requirements:
- Work with core stakeholders to rewrite documentation
- Make the documentation easily consumable by AI systems and empower users with an embedded assistant ( semantic headings, structured metadata, and machine-readable references (OpenAPI specs, JSON examples).
- Integrate embedded natural-language search or AI assistant (leveraging Mintlify features) and ensure clear explanations and concise summaries for LLM parsing.
- Rewrite quickstarts for both AI Jobs and Transcoding Jobs.
- Migration guides for Studio users.
- Integrate goal-based tutorials for each stakeholder type where possible.
- Work with existing groups to incorporate starter repos, examples, and copy-paste snippets and full API/SDK/CLI references with updated coverage (including realtime + BYOC APIs).
- Conduct review with core stakeholders with a clear RFC.
Outcome: First written draft of clear, accurate, and goal-oriented documentation that accelerates adoption and reduces support overhead.
Demo Due Date: Friday 7th November
(iii) V1 Documentation Live
Goal: Deliver a technically sound and reliable documentation site.
Requirements:
- Implement redesigned IA and content in the current docs stack (Mintlify/Docusaurus).
- Set up redirects, SEO and AEO optimization, and accessibility compliance (WCAG).
- Integrate multilingual readiness and analytics tracking.
- Integrate the documentation into the website.
Outcome: A responsive and performant documentation site with zero broken links, measurable engagement, and improved accessibility.
Demo Due Date: Friday 14th November
(iv) Public Workflow For Maintenance & Community Contributions
Goal: Create a consistent tone and a scalable contribution process.
Requirements:
- Work with the Livepeer Foundation’s Technical Director to establish a unified voice and style guide (tone, terminology, formatting, accessibility).
- Create contribution guidelines and PR workflow for community involvement.
- Define and handover ownership and review process for maintaining quality.
- Integrate multilingual readiness and analytics tracking.
- Provide a clear ticketing system for reporting problems and patching fixes.
Outcome: A sustainable documentation process with consistent voice, tone, and governance.
Demo Due Date: Friday 5th December
5. Capabilities Required
Skills
- Developer documentation strategy, IA design, technical writing.
- Static site tooling, redirect management, docs CI pipelines.
- SEO, accessibility, multilingual documentation workflows.
Knowledge
- 1+ years experience with Livepeer ecosystem
- Streaming/transcoding basics (FFmpeg, GPU workloads).
- AI inference workflows basics, particularly working with APIs.
- Open-source contribution models and GitHub-based workflows.
- Comparative familiarity with best-in-class docs (e.g., Chainlink, Base, Solana).
Attitude
- Community-first, collaborative, pragmatic.
- Strong eye for clarity, consistency, and long-term maintainability.
- Willingness to challenge outdated patterns and propose future-proof solutions.
- Enjoyment in distilling complex technical concepts into minimal, user-focused documentation.
6. Proposal Requirements
Please include in your proposal:
- Executive Summary - give an overview of the proposal and why you are suited.
- Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
- Past Work & Experience - examples of docs restructures, especially for developer platforms.
- Milestone Breakdown - giving a week-by-week breakdown of the project in line with the due dates and requirements above.
- Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.
Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template
7. RFP Timeline
- Proposal Deadline: Wednesday 24th September 2025
- Decision Announced: Friday 26th September 2025
- Project Start: Monday 29th September 2025
- Project Completion: Friday 5th December 2025
8. Proposal Submission Instructions
- Format: PDF or Notion page (share with view access).
- Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
- Questions: reach out to
Rich | Livepeer Foundationon the Livepeer Discord. - Proposal Updates: if you submit an early draft of the proposal, you are welcome to update your original proposal until the final deadline.
- Payments: when thinking through your total budget, be mindful that payments will be paid out on milestone completion.
Abstract
All network value depends on protocol security.
Protocol security requires dedicated capacity to detect issues early, resolve them quickly and deploy upgrades with confidence. The current model depends on limited, distributed resources that cannot consistently support these demands. The Protocol R&D Special Purpose Entity (SPE) resolves this by establishing a professional, continuously staffed function responsible for vulnerability triage, safe upgrade preparation, and shipping additional protocol features like a reliable testnet for rigorous validation and development.
This proposal funds the SPE for an initial six-month term. It brings together a contracted security and engineering partner, under the governance of Livepeer Foundation and Livepeer Inc. The SPE creates a single, accountable structure that protects the protocol, reduces operational risk and enables faster, safer delivery of protocol improvements as the network continues to scale.
Mision
The mission of the Protocol R&D SPE is to provide the most secure, resilient and continuously improving protocol foundations possible for Livepeer, at the best possible price-to-value ratio.
Rationale
The protocol supports significant on-chain value which continues to grow through the expansion of services to real-time video AI inference. Protecting this requires consistent access to security and engineering expertise. The current model, while effective at securing the protocol since inception, relies on Livepeer Inc and places a significant load on the security committee. This constrains core feature development and protocol progress. Having a dedicated security partner reduces the load on the security committee and frees them for other obligations, while increasing the speed at which we can improve network security.
Core to this SPE is the engagement of a Protocol Engineering & Security Partner (Sidestream) to provide a dedicated, multi-disciplinary team. They provide first‑response to Immunefi-identified vulnerabilities and implement audited on‑chain patches and upgrades. Immunefi has been a massive success in terms of the mission, keeping the protocol safe at modest cost—historically about $75–100k per year in bounty payouts—while helping protect tens of millions in protocol value. The Partner works in close coordination with the Security Committee, which retains review and execution authority for upgrades and emergency patches.
The steps reduce our reliance on more constrained support, and moves toward a stable, accountable model for protocol security. The SPE creates a durable, well defined structure for protocol stewardship as the network decentralizes. It gives the community a clear point of accountability for security and core maintenance, which reduces operational risk and supports the reliable functioning of the protocol over the long term.
Deliverables
The Protocol R&D SPE improves operational responsibilities, fast and continuous response, ships already‑built but not‑yet‑deployed features in the protocol R&D pipeline, and launches and maintains a public testnet and DevEx toolkit to speed up future development.
(1) Core Protocol Security Operations
Goal: Maintain continuous protocol security coverage and rapid incident response through the Immunefi bounty program and close coordination with the Security Committee.
Outputs: The SPE will manage the Immunefi process as first responder for vulnerability reports. The Partner will reproduce, validate, and propose patches within defined response windows, in coordination with the Foundation Technical Lead and the Security Committee for review and deployment. Quarterly readiness reviews will strengthen detection, response time, and coordination.
Success Indicators: Continuous Immunefi coverage with valid reports acknowledged within 24 hours and triaged within one week. Critical issues are resolved or escalated for deployment within agreed timelines. The SPE operates the response process independently while the Security Committee maintains oversight.
(2) Ship Backlog Features and Build the R&D Pipeline
Goal: Deliver the high-priority protocol upgrades from the existing backlog while building the foundation for a sustainable and iterative R&D process.
Outputs: The SPE will complete and deploy existing features nearing readiness for mainnet release—such as the Reward Call Delegate, Ticket Distinction, and stability patches. The specific upgrades shipped each release cycle will be selected through a lightweight triage process established by the SPE, supported by the Foundation protocol engineer as the role comes online.
Success Indicators: At least one backlog feature or patch deployed to mainnet per release cycle. Lightweight triage and delivery process is established and used to prioritize and ship work. The Foundation protocol engineer is hired and supporting development and coordination by the end of Q1 2026.
(3) Public Testnet and Developer Infrastructure
Goal: Deliver and maintain the testnet and tooling needed for reliable validation, audits, and developer experimentation, supporting both protocol and client development.
Outputs: The SPE will operate a continuously available public testnet with faucet access, CI integration, and simulation tooling. Clear developer documentation and workflows will make it easier to run local or private devnets and test upgrades or integrations before mainnet deployment.
Success Indicators: Public testnet operational with ≥99% uptime and integrated into CI and simulation workflows. Developer and client teams actively use the infrastructure for validation and testing.
Key Milestones
| Milestone | Target Completion | Description |
|---|---|---|
| Partner Onboarding Completed | Q4 2025 | Protocol Engineering & Security Partner contracted and operational, and security and triage procedures aligned with the Security Committee. |
| Continuous Immunefi Vulnerability Response | All of H1 2026 | Maintain full first-response capability for Immunefi reports: reproduce issues, propose fixes, coordinate Security Committee review, and ensure continuous coverage. |
| Public Testnet Live | Q1 2026 | Launch a stable, persistent public testnet with faucet, CI integration, and reproducible deployment tooling. |
| Triage Pipeline Established & First Upgrade Shipped | Q1 2026 | Lightweight triage process established and validated through at least one feature or protocol upgrade shipped to mainnet. |
| Triage Pipeline Updated & Additional Upgrade Shipped | Q2 2026 | Triage pipeline updated, with at least one additional upgrade triaged and deployed to mainnet. |
| Six-Month Review & Renewal Assessment | Q2 2026 | Performance and financial review concluded by the SPE Board,; results shared publicly and renewal proposal prepared. |
SPE Governance Structure
The Protocol R&D SPE is managed and governed by the Livepeer Foundation and Livepeer Security Committee. Through their collaboration, they enable the work of the Protocol Engineering & Security Partner.
The exact operations of security practices are not shared here.
SPE funds are held in a secure multisig SAFE with a threshold of known, trusted signers from the Foundation and the Security Committee, following standard security practices.
The SPE will operate transparently through quarterly public reporting, open development and open access to non-sensitive work.
Roles & Responsibilities
| Body / Role | Responsibilities | Scope | Funding Source |
|---|---|---|---|
| Security Committee | Review and execute upgrades and patches a final security checkpoint | Security oversight; upgrade authorization & execution. | Livepeer Inc. |
| Foundation | Coordinate roadmap and delivery, manage funds and payouts for Immunefi, audits and security partner milestones | Program and roadmap management, coordination and treasury/ops. | Foundation |
| Protocol Engineering & Security Partner | First responder for patches, implementator of new protocol features, audited upgrades, and patches, and build/maintenance of testnet and tooling components | On-chain development, security response, contract CI/tooling, on-chain testnet components. | SPE |
Budget
The Protocol R&D SPE seeks $360,000 equivalent amount. This ensures 24/7 responsiveness from the team in addition to their core security deveopment work.
The budget includes a line item for audits to ensure that significant protocol changes and new implementations receive appropriate security review before deployment. Other necessary costs for executing this SPE, such as the Foundation’s protocol engineer, infrastructure, and operations, are covered separately by the Foundation.
A core responsibility of the SPE is managing the Immunefi bounty program. The Livepeer Foundation will cover Immunefi payouts in the short term to avoid withdrawing capital from the treasury until necessary. This approach allows treasury capital to continue supporting other strategic initiatives across the ecosystem. As part of the Foundation, I can share that we are glad to support this active capital management to advance Livepeer’s collective goals.
Projected Spending:
| Category | LPT | USD | Description |
|---|---|---|---|
| Protocol Engineering & Security Partner (team) | N | $300,000 | Six-month engagement focused on security response, prioritized backlog features, and on-chain testnet ops. |
| Audits & External Reviews | N | $60,000 | Third-party security reviews (reserve-based) |
| Total Initial Request | N | $360,000 |
Key Terms
| Term | Definition |
|---|---|
| Protocol R&D SPE | A Special Purpose Entity funded by the Livepeer Treasury to manage protocol research, development, and security operations. |
| Protocol Engineering & Security Partner | The contracted team responsible for hands-on protocol development, audits, and vulnerability response under the SPE framework. |
| Security Committee | Oversight body responsible for reviewing protocol upgrades, validating critical patches, and guiding decentralization of security responsibilities. |
| Immunefi Program | Livepeer’s bug-bounty initiative that incentivizes whitehat researchers to identify and responsibly disclose vulnerabilities in the protocol. Managed under the SPE to ensure continuous coverage and rapid triage. |
| Triage Pipeline | The structured process for evaluating, prioritizing, and implementing protocol work, including community proposals (LIPs) and vulnerability reports, through coordinated specification, review, and deployment stages. |
| Public Testnet | A continuously maintained network environment mirroring mainnet, used for protocol validation, client testing, and developer experimentation before production deployments. |
| DevEx Tooling | Developer-experience infrastructure, including CI pipelines, simulations, and documentation, enabling contributors to test and validate protocol upgrades efficiently and safely. |
| SPE Board | The governance body composed of representatives from the Foundation, Security Committee, and Livepeer Inc., responsible for approvals, budget oversight, and performance reviews. |
| Audits | Independent security reviews performed by external experts to assess the safety, correctness, and performance of protocol changes before deployment. |
| Multisig SAFE | A secure multi-signature wallet used for custody and management of SPE funds, requiring approval from designated Foundation and Security Committee signers. |
Proposed by: Rich O’Grady (Co-Director, Livepeer Foundation) and Rick Staa (Technical Director, Livepeer Foundation)
Abstract
The Network Engineering SPE is a delegated pool of capital that funds scoped engineering RFPs and retroactive contributor grants, without requiring a standalone on-chain proposal for each initiative. The mission of the SPE is to fund smaller engineering initiatives to make the Livepeer network more observable, performant, and developer-centric. It targets the $2k–$20k range of work that the current SPE process makes too slow to fund. We’ve seen this model work: the Explorer upgrade proved what a vetted contributor with a clear scope and accountable oversight can deliver. This SPE scales that, while exploring a more retroactive model.
Requested duration: 3 month (pilot program) + 2 weeks (retro)
Requested budget: $95,000 USD-equivalent in LPT
The Problem
The Livepeer project needs the ability to execute fast and targeted actions to support users, operators and builders on the network. The current SPE model works well for large, multi-month programmes. It doesn’t work for the $2k–$20k engineering work the network often needs.
The friction is structural:
- A full SPE proposal requires significant time before any work begins
- On-chain vote cycles add weeks of delay — often longer than the work itself
- As AI tooling compresses build cycles, this gap is getting worse, not better
The result: well-supported, clearly-needed work goes unfunded — not because the community doesn’t want it, but because there’s no efficient path to fund it.
This was validated by three public community discussions (March–April 2026) with strong consensus. The Water Cooler on 13 April returned a clear signal: move forward.
The Solution
The aim of this SPE is to build a delegated funding pool with a fast, accountable process which funds critical engineering work fast. This would sit alongside the formal SPE process, which primarily focuses on longer-term (3+ months) initiatives.
This SPE replicates and scales that model across two funding tracks: RFPs dividing up known work and distributing it amongst the community; and retroactive grants funding for work that has already been completed.
Note: Retroactive Grants don’t necessarily go through the Roadmap process.
Eligibility Areas
For the first round of SPE funding, there will be 3 primary focus areas, which are focused on Livepeer’s core stakeholder groups, each with different needs:
Priority 1: [Developers] Developer Portal — The 5-Minute API — Work on the Developer Portal’s critical path: the engineering that takes a developer from docs to first inference call in under five minutes, from any MCP-compatible tool. This includes the Python SDK, BYOC container tooling, payment and auth infrastructure, agentic harness tooling, and any library or scaffolding that removes onboarding friction.
Priority 2: [Delegators] Explorer — Participation & Observability — Work that makes the Explorer a better permissionless participation portal for operators and delegators. This includes staking interfaces, governance participation features, network observability dashboards, and tooling that surfaces real network behaviour to support informed decision-making.
Priority 3: [Orchestrators] Tooling & Infrastructure — Work that helps orchestrators run more reliably, scale capacity, and integrate with the evolving SDK-first architecture. This includes containerisation, orchestration tooling, runtime improvements, go-livepeer contributions, and infrastructure that affects network reliability and operational experience. Note: that this area requires particularly strong community validation before an RFP is promoted
Funding Track 1 — RFPs (~$5k–$20k, 2–8 weeks)
Full proposed process: RFP Process - Network Engineering SPE
Community members post Roadmap Suggestions on the forum, where the suggester drafts initial requirements and deliverables with the community - facilitated by the Livepeer Foundation. After an initial community validation via Discord, the Foundation then publishes a finalised RFP for contributors to apply to, and assigns it to a selected team or contributor within 7 days.
All decisions and disbursements are published with written rationale. Payment is split across three tranches: 25% on signing; 50% on delivery and verification by Review team; and 25% on impact paid at the end of the pilot (in August). Any incomplete work or assessments at the end of the pilot triggers a brief remediation window.
Three Suggestions have already been initially identified and will be scoped with community contributors and then validated by the community to become (or not become) RFPs:
- Roadmap Suggestion 1: Developer Portal & Discoverability platform
- Roadmap Suggestion 2: Improved Explorer as Participation Portal
- Roadmap Suggestion 3: Payment Clearinghouse & Remote Signer
Funding Track 2 — Retroactive Grants (<$5k, retroactive)
Full proposed process: Retro Grants Funding Process - Network Engineering SPE
Build first, then apply. Contributors post a public application on the forum after the work has shipped. The Review Team reviews on a monthly cycle and publishes an approve, partial approve, or decline decision with written rationale. Approved grants are paid in full in a single disbursement.
The primary bar is impact, not completion. Each application must name the problem, who had it, and who is already using the solution. Describe what was built, link to the work, and state the amount requested. Projected usage does not count.
Examples of eligible work and impact:
- OpenRouter integration — 5 developers discovered and integrated with Livepeer via OpenRouter.
- Live video-to-video / BYOC full-stack runner — 3 community members running live video-to-video with BYOC end-to-end — a workflow the network had no viable path for before this.
- Agentic harness tooling — 3 Livepeer solutions cutting time-to-working-agent-loop from days to hours using standardised scripts, tool definitions, and prompts.
Quantifying Impact
Impact means the network becomes more observable, more reliable, or more easy-to-use for Developers, Delegators or Orchestrators. The concrete impact signals that the Review team will look at are all about usage and adoption:
- Named adopter — a specific person or team outside the author is using it in their own work.
- Downstream dependency — another project or contributor is building on top of it.
- Capability confirmed in the wild — someone who wasn’t involved in the build has run it successfully.
It is also expected that the work is maintained and still live by the end of the program. What impact is not: download counts, repo stars, or the builder using their own tool.
What This SPE Isn’t
Not a demand generation fund (coming soon). The Network Engineering SPE funds the engineering substrate: the infrastructure that makes demand solutions like Daydream, Frameworks, Blueclaw, Streamplace possible. Go-to-market, marketing, and end-user services are out of scope.
Not an open-ended bounty pool. Every disbursement requires a verified definition of done. Work must be complete, reviewable, address a recognised need and have verifiable impact.
Replacing the SPE Process. For larger pieces of work network engineering (e.g. 2+ months with multiple contributors), the onchain treasury process will still be used.
SPE Governance Structure
Custody: Funds held by the Livepeer Foundation.
Decision process: All decisions made live in weekly Review Team meetings via a simple 2-of-3 vote, with a written decision log published after each meeting. Any Review Team member with a direct financial interest in a decision must recuse.
| Role | Who | Responsibilities | Paid by SPE? |
|---|---|---|---|
| Review Team Lead & Technical Director | Rick Starr (Livepeer Foundation) | Refines scope of RFPs with Suggester; leads RFP team selection; signs off on technical quality for all RFP Track 1 work - sole gate on technical delivery, no broader Review Team vote required; produces pilot evaluation report | No |
| Reviewer, RFPs | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Reviews and scores RFP applications against evaluation criteria; represents community interests in first-pass scoping; casts an independent vote on Tranche 2 and Tranche 3 payouts; publishes written rationale for any dissent or recusal | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Reviewer, Retro Grants | TBD — Nominated by Orchestrators. Selected by Review Team Lead. | Owns first-pass review of retroactive grant applications against the published rubric (supported by AI pre-screening); triages and quality-screens incoming applications; compiles monthly review shortlist; proactively surfaces strong unsubmitted community work; casts an independent vote on retroactive grant approvals | Yes ($7,500 / 3 months, ~10 hrs/week) |
| Roadmap Manager | Rich O’Grady (Livepeer Foundation) | Facilitates community Suggestion sessions; manages the Suggestions pipeline; promotes validated ideas to the roadmap; signals funding path per item | No |
| Program Manager | Mehrdad (Livepeer Foundation) | Runs and records weekly Review Team meetings; maintains the public decision log; tracks milestone status; manages remediation windows | No |
| Contributors | Community | Deliver scoped outputs with full ownership and accountability | Yes |
This SPE will have AI-native workflows embedded from day one, reducing Review Team overhead, keeping the public record current, and ensuring consistent quality control without manual lift.
AI-led tasks include: retro grant pre-screening; automating meeting notes and updates; decision log drafting; application triaging.
Timeline
15 May 2026 — Funding Programs Live
Review Team seated. Weekly cadence established. First 3 RFPs posted publicly. Retroactive grants open. Public tracker live. Key assessment: did we launch on time with the right scope?
30 Jun 2026 — First Deliveries Verified
At least 1 RFP delivered. At least 1 retroactive grant awarded. Key assessment: is the quality bar holding? Is the 14-day selection target being met?
30 Aug 2026 — Pilot Complete
Minimum 3 RFPs delivered, with aspirational goal of 5. All impact assessments done. All spend published. Evaluation report out with a clear recommendation: continue, modify, or stop.
Budget Breakdown
Total requested: $95,000 USD-equivalent (4-month pilot)
| Budget line | Assumption | Amount (USD-equiv.) |
|---|---|---|
| Review Team Member compensation (×2) | 2 × $7,500 / 3 months (~10 hrs/week) | $15,000 |
| Track 1 — RFP pool | Aim: 3 RFPs over pilot at ~$15k average | $45,000 |
| Track 2 — Retroactive Grants pool | Aim: 5 retroactive grants at ~$3k average | $15,000 |
| Funding Buffer — for additional grants or RFP | To either be allocated, returned to the onchain treasury or carried over to future SPE | $20,000 |
| Total | $95,000 (in LPT) |
If uptake for RFPs and/or retroactive grants are lower than expected at the 30 June checkpoint, the Review Team has the opportunity to reallocate between pools based on where community activity is strongest.
Any unspent funds or incomplete RFPs at pilot end are returned to treasury (with a small undefined, remediation window if work near completion).
All amounts sized using the 30-day moving average LPT price at the time of RFP approval.
Deliverables
Pilot success criteria (3 months):
1. Minimum 3 RFPs reach verified impact - At least 3 scoped engineering RFPs complete with a confirmed definition of done, verified by the Technical Director and community Review Team Members. Each delivery is published publicly with a written rationale and outcome assessment.
2. Minimum 5 retroactive grants funded - At least 5 retroactive grant applications reviewed and awarded, covering work that has already shipped and meets the published rubric. Each award is published publicly with written rationale, the amount approved, and the impact evidence submitted by the contributor.
3. Three public SPE updates published during pilot - One per month (June, July, August). Each update covers: RFPs active and delivered, retroactive grants reviewed and awarded, funds disbursed to date, and Review Team decisions with written rationale. Published within 7 days of the monthly Review Team meeting. Zero black-box decisions.
4. Pilot evaluation & impact report published by 30 Aug 2026 - A concise report covering: RFPs funded and delivered, retroactive grants awarded, total spend vs. budget, community signal on delivered work, and a clear recommendation: continue, modify, or stop. Written for a community audience, not an internal one.
Transparency and Accountability
- Every RFP and retroactive grant decision published publicly with written rationale.
- Public tracker RFPs: all RFPs, status, funds allocated and disbursed, Review Team decisions
- Public tracker grants: all retro grant applications, decisions, amounts awarded, and impact evidence
- Review Team Members publish justification for any overrule or recusal
- Monthly written reporting to the community (per SPE norms) plus update at Water Cooler
- All conflicts of interest disclosed and recused
EDIT: Updated proposal later in the thread.
Hey everyone. I’ve been tinkering with this draft all week but just wanted to get it out there ASAP to kick off the process. For more context, check out my presentation to the treasury last Monday - Part 1 and Part 2.
STREAMPLACE 2.0: SOLVING VIDEO FOR EVERYBODY FOREVER
Summary
We’re requesting 250,000 LPT to continue building the video layer for the next generation of decentralized social. In less than a year, Streamplace (née Aquareum) has evolved from a concept to a functional platform powering thousands of hours of livestreaming, securing partnership with Skylight (a TikTok alternative that reached #1 in entertainment on the App Store), and establishing itself as the go-to solution for live video on the AT Protocol.
The Livepeer treasury made all of that happen, and we’re thrilled to be continuing to fund the project as a shared public good. With your support, we’ll expand our infrastructure, hire specialized talent, enhance moderation capabilities, deepen AT Protocol integration, develop VOD functionality, and explore monetization options—all while maintaining our commitment to open-source development and building public infrastructure.
What We’ve Accomplished
Technical Achievements
- The Protocol: Streamplace has invented a novel form of decentralized livestreaming. Our technique, utilizing C2PA-powered Ethereum signatures over one-second MP4 files, is both cryptographically secure and easy to work with.
- The Node: The Streamplace node runs on all major platforms — Windows, macOS, and Linux, and supports AMD and ARM64 architectures. The node is a single file - deployment is the easiest thing in the world. It’s available for download at Stream.place!
- The App: We shipped the Streamplace mobile app to the App Store and Play Store; Streamplace Desktop is also available for download on Windows, Mac, and Linux. Grab it at https://app.stream.place!
- Implemented WHIP and WHEP protocols The Streamplace node utilizes WebRTC for the entire stack — this makes it super easy to support streaming from browsers and phones while delivering low-latency video playback for viewers.
- Libraries: We shipped c2pa-go, the first library for using C2PA primitives in Go. We implemented Ethereum key support in c2pa-rs and shipped the first library for AT Protocol Oauth using React Native, which is in production in multiple atproto applications.
- Livepeer transcoding: All streams through stream.place are transcoded on the Livepeer network, establishing LIvepeer as a key component in the next generation of decentralized social.
Community & Market Traction
- Sponsored ATmosphereConf livestreaming - Streamplace sponsored the first ATmosphereConf; we both operated the livestream and produced the stream on-site. It went really, really well!
- As a direct consequence, we were featured in TechCrunch as a part of a roundup of next-generation apps building on atproto — we were all by ourselves in the livestreaming category!
- Skylight Social partnership - Also as a direct consequence of the conference, we’re bringing livestreaming to Skylight Social, a Mark Cuban-backed TikTok alternative that recently reached #1 in entertainment and #7 overall on the iOS App Store. Skylight surpassed 150,000 users in the first three days after launch and users are consistently pinging their team asking to go live. As soon as this feature ships, all of this livestreaming will be going through the Livepeer network!
- Established ownership of the live video niche on the AT Protocol. Not only that, but Streamplace will be one of the earliest projects to launch significant video content outside of Bluesky’s infrastructure, contributing to the decentralization of the protocol.
All of this has been achieved while keeping every single line of code open-source and freely licensed.
The Opportunity
We’re at a critical inflection point. We’ve proven the concept works, secured key partnerships, and demonstrated clear product-market fit. Rather than pursuing venture capital with its inherent pressure toward extractive business models, we’re seeking continued support from the Livepeer treasury to pioneer a new public goods funding model—one focused on solving hard technical problems for the benefit of an entire ecosystem.
Funding Allocation (250,000 LPT)
Team Expansion
We need to bring on more people full-time to actually deliver on this dream; to start off we’ll be hiring a designer/front-end engineer and a video expert for hardening the node. Additionally, we’re planning on contracting out bounties and collaborating with other projects in the ATProto and Livepeer ecosystems on projects like code generation and SDK development to start to make Streamplace technology as accessible as possible.
Infrastructure Enhancement
- Servers and Scaling: It’s imperative that we deliver a great first impression to this community, and that means scaling up to handle demand and expanding our server infrastructure.
- Performance Hardening: Veterans of Livepeer Studio know there’s a huge gulf between something that mostly works and a battle-hardened piece of video infrastructure. It’s imperative that we deliver a great first impression; decentralized social needs to work at least as well as existing.
- Reliability Testing: Ensure consistent performance under varying network conditions
Core Technology Development
- AT Protocol Integration: Develop deeper, more native integration with AT Protocol. Currently the integration is relatively shallow; a signing key on a users’ PDS links the two accounts. We’re aiming to assist in the development of the protocol.
- NPM Packages: Streamplace has been architected from the ground up to be embeddable in other apps but we haven’t yet actually shipped this capability. With the Skylight partnership we’ll be building out the capabilities to embed broadcast and playback within other apps and websites; other atproto apps have also expressed interest.
- Clipping and VOD: Build decentralized video-on-demand capabilities (beyond Bluesky’s current 3-minute limit)
- Transcoding Infrastructure: Support increased transcoding demand from Skylight users via Livepeer Network
Trust & Safety
- Moderation Systems: As part of the Skylight launch, we will be building out a full content moderation infrastructure, utilizing AI models backed with human moderators. This kind of thing isn’t always emphasized in the Web3 space, but it’s essential to comply with mass market adoption.
- Community Standards: We plan on developing transparent guidelines aligned with decentralized values.
Growth & Sustainability
- Stream Incentives: Programs to encourage creators to use the platform
- Monetization Framework: Explore micropayment systems and creator revenue models in collaboration with others in the atproto space.
- Custom App Development: Our pitch to big Twitch streamers isn’t “switch from Twitch to Streamplace,” it’s “switch from Twitch to your own app, powered by Streamplace infrastructure.” This facilitates a direct relationship between creators and their fans, while the Streamplace layer still enables all the social features of a rich livestreaming platform - chat, hosting, and such.
Vision
We’re not just building a livestreaming platform—we’re establishing the infrastructure and primitives for an entire generation of video applications on decentralized social networks. Our ultimate goal remains unchanged: solving video for everybody, forever.
With your continued support, we can create something truly revolutionary: a creator-sovereign, open-source video layer that enables experiences on par with centralized platforms but aligned with the values of decentralization.
Thank you for considering this proposal. Let’s continue building the future of decentralized video together.
", replyCount: 28, views: 1472, likeCount: 77, datePosted: "Apr 12, 2025", lastActivity: "Apr 28, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Lisar SPE Release Notes", href: "https://forum.livepeer.org/t/3159", author: "By serial_winner (@serial_winner)", content: "As part of our monthly accountability updates, the Lisar SPE is happy to share our second monthly progress update covering—what we’ve completed, what’s currently in motion, and what’s coming next.
Quick note: This release notes will serve as a way to share what work is going on with Lisar. All future reports will be added under this thread so anyone can easily track progress without hunting for older updates. Dive in to explore what’s happening and please reach out or reply if you have any questions.
October - Status Update
We previously published our first update sharing details of what work was done, if you missed it please find link to the report here
November – Status Update
The Lisar SPE is actively working toward our core deliverable:
unlocking delegation access for everyone globally by enabling fiat-based delegations (USD, NGN, GBP, KES, and more).
Here’s what was completed in November
- Completed a closed beta with users and internal testers
- Switched the transparency dashboard to live mode, enabling real-time community visibility
- Public launch after beta validation
Closed Beta Testing
We kicked off a closed beta in early November with a group of early users. This allowed us to test the entire lifecycle—depositing fiat, converting to LPT, delegating, tracking rewards, and withdrawing back to fiat—with real users.
The beta surfaced minor UX improvements, but overall validation was strong, and all core flows performed as expected.
Live Transparency Dashboard
Our public transparency dashboard is now live.
This means the community can monitor Lisar’s progress in real time—delegators onboarded, total fiat converted, total delegations and more.
Dashboard link: https://lisarstake.com/dashboard
Community transparency is one of our commitments, so getting this live was a major step.
Gearing Up for Public Launch
With beta successfully completed, we’ve shifted into launch mode.
Announcements are ready and will be going out shortly. We’re now entering the final stage outlined in the original four-month proposal with the remaining months focusing on driving adoption and scaling the platform responsibly.
Milestones & Timeline (As Outlined on the proposal)
Check out full proposal on the forum
Build the Core Platform — Completed
- Full fiat → LPT → delegation flow implemented
- Secure fiat on/offramp integrations for multiple currencies
- Gas sponsorship enabled (users never need ETH)
- Delegation + reward tracking in fiat equivalents
- Seamless withdrawals back to fiat
The core platform is stable and production-ready.
Transparency Dashboard — Completed
The dashboard now tracks and displays real-time metrics:
- Number of delegators onboarded
- Total fiat converted
- Total LPT delegated through Lisar
- Delegations per orchestrator
Launch & Scale — In Progress
Up Next
- Launch & Scale - we’re opening access for anyone to delegate on Livepeer through Lisar, with announcements going out across all channels soon. Our next phase focuses on bringing delegators onboard responsibly marking the transition from building → testing → growth.
Find below all relevant links on Lisar, we look forward to sharing more updates soon
Links
-
Begin staking on the Lisar app
-
Track live progress on the dashboard
-
Learn about Lisar, Livepeer, and staking through Lisar Academy
-
Guides on how to stake on livepeer through lisar are up on youtube
-
Follow development on Github
Proposer: FTK Staking
Contact: admin@liveinfraspe.com
ENS: liveinfra.eth
Discord: @ftkuhnsman
Abstract
The LiveInfra SPE requests funding for Q2 2026 to sustain the Community Node service, a free RPC service for the Livepeer community. This proposal covers recurring operational costs for cloud infrastructure, maintenance, and support.
Mission
The LiveInfra SPE is dedicated to empowering the Livepeer community by providing free, reliable blockchain infrastructure services.
Problem and Importance
Livepeer community members depend on accessible blockchain infrastructure to develop decentralized video applications and tools. Operating RPC nodes is costly and complex, and third-party providers charge high fees. The Community Node service delivers free Arbitrum L2 and Ethereum L1 RPC endpoints, removing these barriers.
Rationale
Continued funding for the LiveInfra SPE ensures the Community Node service remains a dependable, cost-free resource for Livepeer builders. Quarterly treasury proposals align with community oversight, minimize market impact on LPT, and allow flexibility to adapt to evolving ecosystem demands.
Current Operations
The LiveInfra SPE provides free Arbitrum L2 and Ethereum L1 RPC endpoints to Livepeer community members (active orchestrators, broadcasters, and delegators with ≥100 LPT staked). It operates with geo-distributed Ethereum L1 nodes (execution and consensus) and Arbitrum Nitro L2 nodes, load-balanced for reliability. A custom proxy layer authenticates user requests via unique URL endpoints, accessible after wallet-based signup. To sign up visit the LiveInfra SPE website and authenticate with your livepeer wallet.
Q2 2026 Operations Plan
This proposal focuses on sustaining service operations for Q2 2026 (April–June). No new features are proposed in the current maintenance period.
Milestones and Timeline
- April–June 2026:
- Maintain to support node operations.
- Perform ongoing maintenance, including software upgrades, node database pruning, and storage expansion as needed.
- Monitor and ensure 99.9% uptime, with transparent reporting via the KPI dashboard.
- Provide community support for RPC service users.
- Ongoing:
- Submit the next quarterly proposal (Q3 2026) to secure continued funding.
Budget Breakdown
The LiveInfra SPE requests $14,000 USD for Q2 2026 to cover recurring operational costs. Funds will be converted to LPT at submission using the current LPT price, with a margin to buffer against price volatility during voting.
- Quarterly Recurring Costs - $14,000
- $9,000 USD - Infrastructure: Quarterly costs for high-quality cloud resources.
- $5,000 USD - Maintenance & Support: Quarterly node upkeep, software upgrades, database pruning, and user support - $2,500 reduction from prior quarter due to improvements in operational efficiency and platform stability.
Total Request USD: $14,000
Total LPT tokens requested: TBD - Determined at submission based on the current LPT price.
Funding Strategy
The LiveInfra SPE will continue submitting quarterly treasury proposals to fund operations, ensuring:
- Minimized Market Impact: Requesting smaller LPT amounts each quarter and selling gradually to reduce price volatility.
- Community Oversight: Quarterly proposals allow the Livepeer community to assess the service’s performance and value, approving continued funding or requesting adjustments as needed.
This approach ensures transparency, sustainability, and alignment with community priorities.
Community Feedback and Suggestions
The LiveInfra SPE values input from the Livepeer community to ensure the RPC Service continues to meet ecosystem needs. We invite community members to suggest enhancements, new features, or additional infrastructure offerings during the pre-proposal review process. Please share your ideas directly in the Livepeer forum as part of the discussion for this proposal. Your feedback will help shape future proposals and ensure the service evolves to support the community’s goals.
", replyCount: 1, views: 55, likeCount: 4, datePosted: "Apr 21, 2026", lastActivity: "Apr 24, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Metrics and SLA Foundations for NaaP", href: "https://forum.livepeer.org/t/3189", author: "By speedybird (@speedybird)", content: "Thank you to everyone who reviewed the earlier pre-proposal and shared detailed feedback in the forum and during the Watercooler. The concerns raised around scope, cost, architectural risk, and MVP clarity were well-founded and directly informed this revision.
This updated pre-proposal reflects a deliberate reset toward a smaller, clearer Network-as-a-Product MVP. The scope has been significantly narrowed, the budget reduced, and the architecture simplified to prioritize time-to-value, reuse of existing Livepeer infrastructure, and immediate usefulness to gateways, orchestrators, and ecosystem teams.
Below is the revised pre-proposal. We welcome the community’s review and feedback on the updated scope, design, and framing. We will be present on this coming Monday’s Water Cooler for discussion.
Cloud SPE Pre-Proposal: Network-as-a-Product (NaaP) MVP – SLA Metrics, Analytics, and Public Infrastructure
Abstract
This pre-proposal seeks treasury funding for the Livepeer Cloud Special Purpose Entity (SPE) to design, build, and operate a focused Network-as-a-Product (NaaP) MVP for SLA metrics, analytics, and public visibility.
The objective of this work is to make the Livepeer network measurable, comparable, and trustworthy at a network level by delivering a small but complete set of standardized performance, reliability, and demand metrics. These metrics will be publicly observable and designed to support gateway providers, orchestrators, and ecosystem builders evaluating Livepeer as production infrastructure.
This MVP intentionally prioritizes time-to-value, architectural simplicity, and reuse of existing Livepeer infrastructure, while establishing a durable foundation for future SLA-aware routing, scaling, and productization efforts led by Livepeer Inc, the Livepeer Foundation, and the community.
Rationale
As Livepeer advances toward the Network-as-a-Product vision, predictable service characteristics and transparent performance signals become essential. While the network supports real workloads today, participants lack a shared, network-wide view of performance, reliability, and demand that can be used to assess suitability for production use.
Community discussions around earlier drafts of this initiative strongly aligned on the problem, while raising important concerns around scope, cost, architectural risk, and MVP clarity. This pre-proposal reflects that feedback by narrowing focus to a practical MVP that:
- Demonstrates clear value with minimal complexity
- Leverages existing data sources and pipelines wherever possible
- Avoids protocol changes, enforcement mechanisms, or premature decentralization
- Produces immediately usable outputs for real network participants
Key challenges addressed by this proposal include:
- Fragmented metrics: Existing performance and reliability data is dispersed across systems and difficult for non-core teams to consume.
- Limited network-level visibility: Gateway providers and orchestrators cannot easily compare performance across regions, workloads, or peers.
- Adoption friction: Without transparent, shared metrics, external developers and partners struggle to evaluate Livepeer for serious workloads.
- Missing foundation for NaaP evolution: Future SLA-aware routing, scaling, and automation require a trusted measurement layer first.
The Cloud SPE is well positioned to deliver this work as neutral, public infrastructure, building on its prior experience operating gateways, test tooling, dashboards, and analytics for the Livepeer network.
Importantly, this proposal does not attempt to enforce SLAs, modify protocol incentives, or introduce new routing logic. Its purpose is to establish shared measurement and learning infrastructure as a prerequisite for those future decisions.
Deliverables
The NaaP MVP will deliver a constrained, end-to-end metrics system focused on observability and learning inspired by the NaaP product MVP and Foundation roadmap.
1. Core SLA Metrics (MVP Scope)
- A standardized set of network, performance, and reliability metrics sufficient to evaluate orchestrator and GPU behavior across workflows.
- Metrics sourced primarily from job tester gateway and orchestrator-emitted telemetry, with targeted additions only when other Gateways opt-in.
2. Network Test & Verification Signals
- Operation of one or more reference load-test gateways to generate consistent, reproducible performance signals for live AI video pipelines.
- Public test scenarios (aka test datasets) designed to reflect real workloads while remaining transparent and community-verifiable. These will be captured in Github.
- Test results contributed into the same analytics layer as organic network traffic to enable comparison (when other Gateways participate).
3. Analytics & Aggregation Layer
- Lightweight ETL and aggregation pipelines to transform raw metrics into network-level views.
- Computation of a small number of derived indicators as outlined in the Metrics Catalog
- Data structured for efficient querying without requiring dashboards to load raw job data.
4. Public Dashboard & APIs
- A standalone public dashboard presenting live and historical metrics.
- Public, read-only APIs for aggregate SLA scores and hardware.
- Clear paths for gateways and ecosystem teams to consume the data directly or mirror it into their own analytics systems.
5. Operations & Stewardship
- Ongoing operation of testing, analytics, and dashboard infrastructure.
- Maintenance, monitoring, and community support for the MVP for 1 year.
Any scope not outlined here is not part of the Deliverables and out of the scope of this proposal.
Key Milestones
Milestone 1 – Metrics Collection & Aggregation
- Define and implement the minimal metrics set
- Aggregate existing telemetry into a unified analytics layer
- A basic dashboard showing sample data flowing end to end
Milestone 2 – Test Signals & Derived Analytics
- Deploy reference load-test gateways
- Launch a public dashboard with core views
- APIs for ecosystem consumption
Milestone 3 – Stabilization & Review
- Harden infrastructure for reliability and cost efficiency
- Document metrics, assumptions, and known gaps
- Review outcomes with the community to determine next steps
Timeline
Delivery is anticipated to take approximately six months (and already underway as of November 2025). This is dependent on the team’s development velocity and subject to change. Preliminary design and validation work has begun to reduce delivery risk.
- November 2025 - Works began on original proposal and discovery process
- February 2026 – Milestone 1: Metrics Collection & Aggregation
- March 2026 – Milestone 2 – Test Signals & Derived Analytics
- April 2026 – Milestone 3 – Stabilization & Review
Budget
Total Requested Budget: $90,000
This budget supports:
- Engineering work to aggregate, validate, and expose SLA-relevant metrics
- Development of Load Testing Gateway (AI Job Tester + Gateway enhancements) and Network Data Scraper
- Development of minimal analytics and public-facing dashboards
- Development of DevOps infrastructure and automation
- Operation of testing, analytics, and storage infrastructure for approximately one year
- Ongoing maintenance, documentation, and community support
The budget is intentionally sized for a thin but complete MVP, designed to validate assumptions, inform future investment, and avoid long-term commitments before value is demonstrated.
Closing Note
This pre-proposal reflects extensive community and Livepeer Inc feedback and represents a deliberate step toward a simpler, clearer, and more actionable NaaP MVP.
By focusing on shared measurement rather than enforcement or protocol change, this work aims to give the Livepeer ecosystem a common understanding of network behavior today — and a solid foundation for deciding what to build next.
", replyCount: 12, views: 331, likeCount: 48, datePosted: "Jan 10, 2026", lastActivity: "Apr 14, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Embody SPE: Pre-proposal Intelligent Public Pipelines", href: "https://forum.livepeer.org/t/3220", author: "By DeFine (@DeFine)", content: "Pre-proposal v5: WEAVE
Authors: DeFine (Strategy & Engineering), Dane (Virtual Worlds & Avatars)Date: March 15, 2026
1. Abstract
The Embody SPE is an entity dedicated to bringing embodied avatar workloads into the Livepeer ecosystem. Since our inception, we have continuously evolved our technology to meet the needs of the network. Our core drive is to deliver sustained fee growth for Livepeer orchestrators.
Along our journey, we have developed solutions and frameworks that address Livepeer’s core bottleneck: the workload lifecycle. Embody seeks funding to develop and prove these solutions, and to expand them into an open-source public-good toolset fit for every existing and upcoming workload deployed on Livepeer.
2. The Problem
To understand the problem, one must recognize three fundamental actors within the Livepeer ecosystem:
-
Orchestrators, who provide compute for workloads.
-
Workload Facilitators, who engineer and maintain the workloads that orchestrators run.
-
Consumers, who utilize these workloads and generate demand.
The Livepeer network provides adequate tokenomic incentives for orchestrators. However, workload facilitator and consumer incentives are currently funded in a non-standardized way by the Livepeer treasury, with limited success so far. In supply and demand terms, compute suppliers vastly outnumber both demand seekers and demand creators.
Workload facilitators generally fall into two subcategories: startups seeking capital to pay for compute and build a consumer base, and established organizations that already possess compute capital and consumers. Livepeer is attractive to both because orchestrators are incentivized through token inflation to offer compute below standard market costs. Theoretically, workload facilitators should be able to offer better prices to their consumers by selecting Livepeer orchestrators.
Despite this advantage, creating workloads within the Livepeer ecosystem remains exceedingly difficult due to the following barriers:
The Technical and Conceptual Barrier Workload facilitators must deeply understand the Livepeer ecosystem technically and conceptually. Furthermore, manually executing every step of a workload’s lifecycle and managing the handoff to the next stage requires an immense amount of time and effort. This creates an exceptionally high barrier to entry, practically excluding non-technical participants from the creation process.
The Economic and Incentive Barrier Economic incentives for workload creation are virtually non-existent by default. Startups rely on the treasury to incentivize their work. Even if a team possesses the technical capability to deliver workloads, they must invest significant time navigating the community and preparing proposals, hoping for treasury approval. For established organizations, there is no incentive to risk service downtime and consumer dissatisfaction by migrating from centralized providers to Livepeer. To date, there are zero documented successful cases of such organizations making the swap.
The Distribution and Interface Barrier Once a workload is live, startups without established consumer bases face the monumental task of building consumer interfaces and executing outreach. Such organizations typically have low headcounts. The added overhead of maintaining Livepeer-specific infrastructure, building interfaces, and distributing workloads is enough to make Livepeer unattractive, especially given the generous inference subsidies offered by centralized providers.
This culmination of friction leads to a critical question: How can we radically reduce the time it takes to convert intent into workload creation and distribution?
3. The Solution
To resolve this bottleneck, we propose WEAVE; an open-source, semi-autonomous agentic orchestration tool with a human-in-the-loop design. WEAVE is designed to turn stakeholder intent into researched, engineered, tested, maintained, and distributed workloads, compressing the lifecycle from months to mere hours.
WEAVE will be accessible to everyone, resolving lifecycle bottlenecks from initial research to consumer distribution. It allows workload facilitators to create new GPU-powered workloads and rapidly deploy them to orchestrators and consumers.
The human operator’s role is simplified: they prompt the initial intent, review the output at the end of each lifecycle stage, and authorize the agent to proceed to the next step. Embody will develop and provide the first WEAVE workloads, managing consumer and orchestrator incentives to power our own and future WEAVE users.
How WEAVE Solves Each Stage
WEAVE directly addresses each stage of the workload lifecycle:
Research Lifecycle agents help identify promising workloads, synthesize demand, evaluate tooling and feasibility signals, and prepare proposals for Livepeer stakeholder review.
Engineering and Maintenance Lifecycle agents turn approved intent into implemented workloads, updates, fixes, and ongoing maintenance work inside bounded environments.
QA Lifecycle agents validate workloads, catch regressions, and prepare them for release through a repeatable testing path.
Consumer Interface The public entry point is a published SKILL.md—a markdown contract that instructs consumers on how to start, control, and end the workload through a mediated public control surface.
Orchestrator Release Lifecycle agents package workloads, document release requirements, and move them through a clear operator onboarding and rollout path.
Consumer Distribution Lifecycle agents support the distribution work needed to reach consumers, drive adoption, and keep the workload legible as a public interface rather than an obscure private implementation.
From Intent to Live Workload
WEAVE provides a clear path from initial intent to live network execution:
-
Intent Submission: A user submits a workload intent. This can propose a new workload, request an improvement, or point the pipeline toward a concrete opportunity (e.g., real-time camera tracking).
-
Lifecycle Execution: Agents pick up the intent and move it through research, engineering, QA, release preparation, and distribution.
-
Stage Review and Authorization: At the end of each stage, agents publish artifacts and request human review. Agents carry the workflow forward, but human authorization is strictly required to complete a stage.
-
Runtime Release and Distribution: When release-ready, WEAVE distributes the workload to the orchestrator registry. Operators can adopt it through a bounded action. The system simultaneously publishes the consumer-facing
SKILL.mdand begins distribution outreach.
For orchestrators, this creates a faster path to new fee-generating workloads and lowers integration friction.
Economic Incentives
WEAVE resolves the time constraints and technical barriers, but this only solves part of the problem. The other half is the absence of economic incentives for workload facilitators and consumers. Similarly, orchestrators typically do not run workloads for free out of goodwill; there must be clear incentives for them to support WEAVE workloads. To address this, we propose three perpetual financial packets:
1. Workload Facilitator Hackathon Packet A perpetual hackathon powered by an LPT economic packet, where a portion of the accrued inflation value is used to incentivize the weekly creation of new workloads. The remaining value is fed back into the principal, allowing it to compound continuously so that token rewards grow over time. The shape of the hackathon and its economic parameters will be subject to ongoing refinement by the multisig participants. Participants will engage through a SKILL.md contract, and funding will be distributed retroactively upon the completion of intended targets. This creates an asymmetric upside: participants are incentivized with an initial allocation, and upon delivering a high-demand workload, they receive retroactive funding along with the ability to deploy applications on top of the workload.
2. Consumer Incentive PacketThis perpetual financial packet operates similarly to the facilitator packet, utilizing weekly accrued inflation to incentivize consumers of WEAVE workloads to take specific actions. For example, SKILL.md consumer agents holding a blockchain wallet could be eligible for rewards if they deliver a working open-source companion application that reaches five concurrent daily users. Like the facilitator packet, this is designed with an asymmetric risk/reward model: the consumer uses the workload without charge and receives a small initial incentive (subject to terms), while the upside includes retroactive rewards and the ability to profit from an application built on WEAVE’s incentive layer.
3. Orchestrator Incentive PacketAn economic packet dedicated to providing weekly rewards for orchestrators who run WEAVE workloads on their hardware systems, ensuring consistent compute availability and sustained network participation.
4. Where We Are Today
WEAVE is being proposed on top of assets the Embody team already operates: a mature Embody workload, an orchestrator rollout lane, and a working consumer entry point.
-
embody-skill: The published skill-contract path for the workload interface, providing a working consumer-distribution surface.
-
livepeer-ops: The control-plane layer for sessions, policy, and orchestrator allocation.
-
Unreal_Vtuber: The runtime environment for the embodied avatar workload.
-
Registered Orchestrators: 13+ orchestrators have registered to the pipeline and received workloads; seven are currently active, and prior participants can reenter.
-
Rollout Capability: The active lane can already receive auto-updates through the Unreal_Vtuber path.
Together, these assets provide the execution base for the proposal: a mature workload, an existing operator lane, and functioning distribution tooling on which WEAVE can be built, tested, and released.
5. What We Are Delivering (4-Month Scope)
The roadmap advances in three stages: first, deploy Embody as the inaugural workload on WEAVE; second, extend WEAVE to host daydream/scope; third, generalize WEAVE beyond both to support any realtime application, establishing it as a true open-source public good for the Livepeer ecosystem.
The perpetual financial packets are foundational to this progression. All three launch alongside the Embody workload in Month 1, ensuring that workload facilitator and consumer incentives are active from the start and that orchestrator expenses are covered from day one.
Month 1 — Embody Workload, Lifecycle Automation & Incentives Launch
DeFine
Deliverables
-
Establish the first bounded lifecycle-agent runtime.
-
Automate research, engineering, maintenance, and QA flows on the Embody (non game-dependent) proving lane.
-
Release Embody as the first working WEAVE workload, accessible via
SKILL.mdand processing sessions on at least one active orchestrator. -
Deploy all three perpetual incentive packets (Workload Facilitator Hackathon, Consumer, and Orchestrator).
Success Criteria
-
Lifecycle agent runtime operational and processing intents end-to-end on the Embody lane.
-
Embody workload live and accessible via
SKILL.md, processing sessions on at least one active orchestrator. -
All three incentive packets deployed and accepting participants.
-
At least 3 orchestrators enrolled in the WEAVE lane.
Dane
Deliverables
- Automate the Embody/Unreal Engine workload engineering pipeline through DeFine’s agent runtime: plugin automation, adding and removing code and features, and game packaging — covering ≥80% of the engineering workflow end-to-end.
Success Criteria
- Agent runtime can execute Unreal Engine engineering tasks end-to-end (plugin add/remove, code changes, game packaging) with ≥80% workflow coverage.
Month 2 — Daydream/Scope Workload Path
DeFine
Deliverables
-
Adapt WEAVE end to end to accept daydream/scope workloads.
-
Bring the orchestrator rollout path online for daydream/scope workloads.
-
Support the first new community workload generated from the Month 1 Hackathon.
Success Criteria
-
WEAVE adapted end to end for daydream/scope workloads.
-
Orchestrator rollout path operational for daydream/scope workloads.
-
First community hackathon workload supported end-to-end.
Dane
Deliverables
- Deliver a functional prototype of the alternative (non-Unreal Engine) embodied avatar workload demonstrating core session flow.
Success Criteria
- Alternative avatar workload prototype operational and demonstrating end-to-end session handling.
Month 3 — Generalized Path & Alternative Avatar Pipeline
DeFine
Deliverables
-
Expand WEAVE from scope and daydream to support custom-lane workloads built on any framework or technology stack, including those outside the Embody and daydream/scope ecosystem.
-
Package Dane’s alternative embodied avatar workload into WEAVE.
-
Open WEAVE to public orchestrator onboarding.
-
Publish the supported workflow for releasing and maintaining additional workloads through WEAVE.
Success Criteria
-
WEAVE custom lane operational and accepting at least one workload built on a framework outside Embody and daydream/scope.
-
Dane’s alternative workload packaged and accessible through WEAVE.
-
At least one external orchestrator onboarded through the public path.
-
Supported workflow for releasing additional workloads documented and tested.
Dane
Deliverables
-
Deliver the alternative (non-Unreal Engine) avatar pipeline, fully operational and documented, ready for DeFine to integrate and automate.
-
Deploy the ability to add and edit new avatars and game environments in both the Unreal Engine and the alternative avatar pipeline.
Success Criteria
-
Alternative avatar pipeline operational, documented, and handed off to DeFine for WEAVE integration.
-
Avatar and environment creation and editing operational in both pipelines, with at least one new avatar or environment demonstrably added through the system on each pipeline.
Month 4 — Governance and Handover
DeFine
Deliverables
-
Facilitate a public governance discussion with multisig participants and the community on how the incentive packets and lifecycle-agent runtime should be managed post-grant.
-
Strategize and document the operating model for the three perpetual incentive packets going forward — how they will run, who will manage them, and what community input shapes their parameters. This decision passes through the community.
-
Document the agreed governance path: multisig participants may elect to transition to a decentralized on-chain layer, continue multisig management until a decentralized solution is ready, or confirm another path agreed upon by the group.
-
Resolve all pending bugs submitted against WEAVE during the grant period.
-
Publish handover documentation and a residual-risk list regardless of the governance decision.
Success Criteria
-
Governance discussion held and outcome documented publicly.
-
Incentive operating model documented and ratified by community input.
-
One of the following governance paths confirmed and recorded: (a) decentralized governance contracts deployed and management transitioned, or (b) a clear continuation plan agreed upon by multisig participants with an explicit path toward eventual decentralization.
-
All flagged WEAVE bugs resolved or, where blocked by external dependency, documented with root cause and mitigation plan.
-
Handover documentation and residual-risk list published.
Dane
Deliverables
- Resolve all bugs flagged across both pipelines during the grant period (Months 1–3).
Success Criteria
- All flagged bugs resolved or, where resolution is blocked by external dependency, documented with root cause and mitigation plan.
Each monthly tranche is released independently via 3/5 multisig upon confirmation of that month’s criteria — DeFine: $4,000 per month, Dane: $6,000 per month. Month 4 payments for both tracks are advanced upon Month 3 confirmation, with final deliverables confirming grant completion. A delay or gap in one track does not block the other.
6. Budget & Financial Governance
The total amount requested from the on-chain treasury is $100,000 USD, equal to 43,478 LPT at an LPT reference price of $2.30 on March 15, 2026.
Budget Breakdown
-
Team Compensation: 17,391 LPT / $40,000 total.
-
DeFine: $16,000 total ($4,000/month). Strategy, control plane, WEAVE engineering, and governance/runtime delivery.
-
Dane: $24,000 total ($6,000/month). Embodied avatar workload engineering across Unreal Engine and non-Unreal runtime paths.
-
Release mechanism: Each monthly tranche is held in the multisig and released only after the month’s work is complete and its success criteria have been met. Release requires 3/5 multisig confirmation. Each track is independently verified and independently released — a delay in one does not block the other.
-
-
Operational Costs: 4,348 LPT / $10,000. Infrastructure, runtime, measurement, and support costs for the proving workload during the grant window.
- Release mechanism: Funds are released against submitted receipts as expenses are incurred. No advance disbursement; each release requires documentation of the corresponding expense.
-
Network Incentives: 13,043 LPT / $30,000. Principal for the Orchestrator Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participating orchestrators according to the published incentive rules.
-
Workload Facilitator Incentives: 4,348 LPT / $10,000. Principal for the Workload Facilitator Hackathon Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participants who meet the published hackathon criteria.
-
Consumer Hackathon: 4,348 LPT / $10,000. Principal for the Consumer Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to consumers who meet the published incentive terms.
Total: 43,478 LPT / $100,000.
The grant will be managed on Arbitrum through a proposal-facing multisig, incorporating comprehensive receipt spend tracking and structured spending categories.
Multisig Composition
-
Orchestrator Tiebreaker: One signer - Pon.
-
Embody Team: Two signers.
-
Foundation: Two signers, including Rick, the Foundation’s head engineer.
Treasury actions will proceed through a 3/5 signature scheme path. If funds need to be returned, the remaining balance can be converted to LPT and sent back to the Livepeer treasury through the governance process described in the separate wallet governance packet.
7. Addressing Past Feedback
We want to thank the Livepeer stakeholders who gave feedback on earlier versions of this pre-proposal. That feedback improved the proposal materially by surfacing three important issues: the security boundary needed to be clearer, the scope was too abstract, and the budget needed to match the size of the work more credibly.
This revision responds directly to those points. It narrows the first workload claim, explicitly defines the system as an open-source tool rather than a decentralized protocol, makes the public consumer path and governance shape more legible, and ties the four-month ask to reviewable milestone outputs. During the core engineering period, the team will remain responsive to ongoing feedback and incorporate useful improvements.
8. FAQ
1. Who is WEAVE for? WEAVE is designed for both the creation of entirely new workloads and the implementation of changes to existing ones.
2. How much automation exists in WEAVE? A WEAVE user can select their preferred level of automation. They can choose to manually review each stage, leave the review to the agent for auto-authorization, or take a highly hands-on approach in the creation process. The lifecycle agents are capable of automating the entire workload lifecycle, including scanning for novel opportunities.
3. How will WEAVE workloads be deployed to orchestrators? The Embody team will maintain a registry where the lifecycle agents of every WEAVE user can post their workloads. Livepeer orchestrators can then browse this registry and select to deploy these workloads through a single command.
4.How are you sure that workloads will be secure? The security evaluation process naturally sits outside the domain of individual WEAVE users. All workloads will be automatically inspected by centralized lifecycle agents operated by the Embody team. Furthermore, every workload will require a manual review before it is approved for deployment to the registry.
5. Will WEAVE use existing Livepeer components for the workload lifecycle and orchestrator payments? Yes. WEAVE will use Bring Your Own Compute (BYOC) for workload deployment, alongside Livepeer gateways and the clearinghouse for workload delivery and payments. The custom Embody parts that previously fulfilled these functions will be replaced with their mapped Livepeer-specific components.
6. What happens if you aren’t finished in the provided timeframe? All provided funds managed by the multisig will be converted to LPT and sent back to the treasury.
9. References & Technical Appendix
This appendix serves as the deeper review bundle behind the shorter forum post. The post stays high-level; the linked docs carry the architecture, roadmap, budget, and governance detail.
Repositories
-
embody-skill: https://github.com/its-DeFine/embody-skill
-
livepeer-ops: https://github.com/its-DeFine/livepeer-ops
-
Unreal_Vtuber: https://github.com/its-DeFine/Unreal_Vtuber
Packet Docs
note: packet docs are being actively updated for the new version
", replyCount: 21, views: 423, likeCount: 39, datePosted: "Feb 17, 2026", lastActivity: "Apr 1, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Embody Team: Updates", href: "https://forum.livepeer.org/t/3215", author: "By DeFine (@DeFine)", content: "Embody Team: Retrospective
Date: February 9, 2026
This document provides a retrospective of the Embody team’s (DeFine + Dane) workstream, covering the Agent SPE Phase 2 period and post-separation efforts through February 9, 2026. Our focus is on the open-source deliverables and technical contributions made to the Livepeer ecosystem. This retrospective is scoped to the Embody-managed workstream and does not cover the full scope of the Agent SPE Phase 2 grant.
Executive Summary: What We Shipped
•Open-Source VTuber Stack: Shipped and maintained Unreal_Vtuber, a Pixel Streaming stack enabling Livepeer orchestrators to run embodied MetaHuman avatars. Tagged open-source releases from v1.0.0 (December 18, 2025) through v1.3.5 (January 28, 2026).
•Dynamic Customization: Delivered extensive avatar and environment customization, including a character customizer, morph targets, hair, clothing, and camera controls, as documented in the weekly work logs.
•Incentives Pipeline: Delivered and maintained an orchestrator incentives program, funded from Embody-managed inference credits. This work was outside the strict Phase 2 scope.
•Multi-Platform Broadcast Pipeline: Built a broadcast-capable pipeline (WebRTC source with an optional RTMP output for platforms like Twitch and YouTube). Automation of this pipeline is in active development.
•Continued Work Post-Separation: Despite a reduced budget following the separation from Agent SPE, the Embody team continued execution and completed the majority of technical and non-technical deliverables.
Timeline Highlights
•April 14, 2025: Phase 2 begins.
•August 20, 2025: Separation settlement and allocations are publicly posted.
•December 18, 2025: First tagged Unreal_Vtuber open-source release (v1.0.0).
•January 28, 2026: Unreal_Vtuber v1.3.5 is tagged.
•February 7, 2026: On-chain reconciliation packet is produced.
Promised Deliverables vs. Current Status
This section is structured by the Phase 2 proposal’s “Months 1–6” deliverables, with Embody’s current status and evidence pointers. Items Embody did not manage (funds and execution) are explicitly marked as Defer to Agent SPE.
| Deliverable | Status (Embody) | Evidence |
|---|---|---|
| Technical Excellence | Delivered a full embodied-avatar pipeline and operational Pixel Streaming stack. The “sub-100ms” latency target from the proposal is a goal; this document does not include an independent benchmark. | Unreal_Vtuber OSS stack |
| Livepeer Integration | Delivered. Orchestrators can run embodied avatars via the open-source stack, and Phase 2 weekly logs show Livepeer inference integrations and related pipeline work. | Unreal_Vtuber OSS stack, Livepeer-Autogen-Integration, plugin-livepeer-inference, NeuroSync-Core, eliza-livepeer-integration |
| Streamlined Onboarding | Delivered simplified operator onboarding for the OSS stack. The “<5 minutes” figure is a proposal target, not a universally measured setup time. | Unreal_Vtuber OSS stack |
| Comprehensive Analytics | Partially delivered. OSS/runtime telemetry exists, and production-validation analytics were set up via PostHog (not a treasury deliverable). | PostHog work is documented in internal repository files. |
| Dynamic Customization | Delivered. Dane’s Phase 2 work (Animator Handbook) documents extensive customization work. | Animator Handbook |
| Multi-Platform Deployment | Delivered a broadcast-capable pipeline (Pixel Streaming → RTMP) and ongoing operator automation for autonomous streaming. A fully autonomous, interactive VTuber is live and continuously improving, with memory and background tool-use capabilities. Note: the autonomous agent is continuously improving, and its current state represents the baseline of its capabilities. | Livi Embody — Autonomous VTuber (Twitch) |
| Protocol Partnerships | ElizaOS integration plans were paused/deprioritized; the primary execution path pivoted to Embody-managed direct integrations. | eliza-livepeer-integration |
| Startup Integration Program | Defer to Agent SPE. Embody did not manage these funds post-separation. | Separation Post |
| Usage Incentives | Defer to Agent SPE for the original proposal line item. Separately, Embody did operate and maintain an orchestrator incentives program funded from the inference credits allocated to Embody. Note: Livepeer stakeholders requiring the full unredacted financial/accounting pack may contact the Embody team. | Public Financial Audit Pack |
| Use Case Demonstrations | Delivered multiple demonstrations and continues to iterate on use cases, including a live autonomous interactive VTuber stream. | Livi Embody — Autonomous VTuber (Twitch), Livepeer Fireside Appearance, Unreal Vtuber Demo |
| Financial Sovereignty Infrastructure | In progress. Will be released this week with the public release of the OpenClaw agent repository. | Release pending. |
| Diversified Revenue Frameworks | Embody has begun operating in the agent-to-agent economy(see embody.zone). A further community update on this deliverable will follow within the week. | embody.zone |
Sources Used
", replyCount: 1, views: 129, likeCount: 4, datePosted: "Feb 10, 2026", lastActivity: "Mar 25, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Pre-proposal: Livepeer FrameWorks SPE Pilot phase", href: "https://forum.livepeer.org/t/2773", author: "By Marco van Dijk (@stronk)", content: "Livepeer FrameWorks SPE: Pilot phase
Author(s): The MistServer Team
Contact: developers@mistserver.org
Abstract
The FrameWorks SPE proposes to strengthen the Livepeer protocol by bridging the gap between transcoding infrastructure and real-world media applications.
This includes:
- Providing dedicated engineering resources to ensure stability, feature enhancements, automated testing and a clear & complete documentation.
- Providing onboarding and infrastructure support for teams building on Livepeer.
- Operating an independent, Livepeer-powered E2E media pipeline that validates new transcoding features in real-world deployments.
By focusing on low operating costs, easy integration and strategic partnerships, FrameWorks aims to provide a viable, scalable alternative to traditional full-service video providers.
This first phase serves as a pilot to build trust and credibility within the Livepeer ecosystem while keeping the initial funding request modest.
Mission
The media industry is highly complex. Building reliable, scalable streaming applications requires complex deployments and industry expertise.
Livepeer Inc has laid a robust foundation for decentralized video infrastructure. However, there remains a gap between what the network offers versus what video applications need.
This proposal builds on their achievements by addressing key areas where we can contribute with our expertise.
The MistServer team proposes a Special Purpose Entity to take ownership of maintaining and enhancing the transcoding pipeline, ensuring that node operators have the support, documentation, and features they need.
FrameWorks will also bridge the DevOps gap by offering an E2E media pipeline that businesses can directly integrate or self-host, rather than relying on Livepeer Studio for infrastructure, support or custom features.
Instead of replicating Studios’ high-complexity, full-service model, FrameWorks aims to build a scalable, low-overhead alternative aimed at easy integration with external business logic.
Result: A more stable, performant, and accessible transcoding pipeline for node operators and Livepeer-powered media applications.
Terminology
Some of these terms are not present in this pre-proposal, but can be helpful when browsing through the feature board.
- E2E media pipeline: Provides the core infrastructure for a full media pipeline. Including but not limited to: ingesting, processing, storing, and delivering video.
- Transcoding: The process of decoding a video stream, transforming it (resolution, bitrate, etc.), and encoding it for delivery or storage.
- Segmented Workflow: A process of breaking video streams into discrete segments for transcoding. A full segment is required before it can be transcoded by the network.
- Streaming Workflow: A continuous processing method where the video stream is sent in small chunks and immediately transcoded.
- Intel QSV: Intel’s “Quick Sync Video” hardware for video encoding/decoding, allowing efficient transcoding on Intel CPUs and GPUs.
- AV1: A royalty-free, high-efficiency video coding format which is gaining in popularity.
- Latency: In the context of Livepeer we consider the delay between the stream ingest at a Gateway node and receiving the transcoded frames back.
- Netint: Specialized hardware device for video transcoding.
- LPMS: Livepeer Media Server, the core transcoding library used within the Livepeer stack.
- FTE: Full Time Equivalent, indicates the amount of hours dedicated to a project. 1 FTE equals one fulltime employee, but could also be two people each contributing 0.5 FTEs worth of effort.
Structure
The MistServer Team leads the SPE, with Marco (stronk-tech.eth) acting as the primary decision-maker and point of contact.
The SPE is open to expand the core SPE team with additional applications from outside the MistServer team.
Structure
- Lead: Marco, long-time Orchestrator and MistServer maintainer.
- Core Team: MistServer maintainers with expertise in transcoding and live streaming.
- Open-Source Contributors: Developers in the Livepeer community who take on bounties.
- Advisors:
- Rick (
transcode.eth): AI SPE Lead. - Brad (
ad-astra-video.eth): AI SPE Engineer, also familiar with the transcoding codebase. - Josh: Livepeer Inc engineer with extensive experience with relevant code repositories (
LPMSandgo-livepeer). - Rich: Livepeer Ecosystem Growth Team
- Rick (
Responsibilities
- Core Team: Scoping out tasks, assigning bounties, conducting code reviews, and core development of the transcoding pipeline.
- DDVTech: The business entity of the MistServer team, responsible for hiring, team coordination, and administrative processes.
- Advisors: Provide strategic & operational guidance and brainstorming about potential solutions.
About the MistServer Team
The MistServer team is composed of experts in live streaming and media server technology. Our journey began in 2009 when we set out to build a better media server following the failure of a media-related project due to unreliable software. Since then, MistServer has become our core business, and we’ve dedicated our professional lives to advancing live streaming technology.
We bring over half a century of combined hands-on experience in live streaming and media server development, including experience managing streaming infrastructure (like Picarto).
This hands-on expertise positions us uniquely to lead the FrameWorks SPE and contribute meaningfully to the ecosystem.
Scope
The core responsibilities of this SPE include:
- Making the Livepeer transcoding pipeline more robust and competitive.
Adding codecs, adding device support, reducing latency and enhancing transcoding jobs with more parameters.
- Supporting node operators.
Identifying & addressing common pain points, like replacing the static session limit with smarter GPU load balancing and improving Gateway Documentation.
- Ongoing core maintenance
This is a task which also sees ownership from existing core contributors. The Transcoding SPE intends to jump in (wherever required) to assist with tasks like keeping the build pipelines up-to-date, rebasing the LPMS FFMPEG patches and fixing bugs or crashes.
- Research & integrations
The media industry landscape changes over time (slowly evolving). WebRTC and SRT are now common methods to transport media, but are unsupported by Gateway nodes.
These kind of features could also be supported by siderunning applications, like how WebRTC has limited support through go-livepeer’s MediaMTX integration.
This topic covers exploring enhancements to the Gateway with additional protocols or improving integrations with external applications.
- Expanding testing & QA practices
Implementing automated testing to ensure network stability and prevent regressions.
This includes writing feature-specific tests for each change we make, while also expanding coverage with additional regression or benchmark tests.
- Bridging the DevOps gap for media applications
Providing support to entities looking to build on the network as well as setting up an E2E media pipeline, making it easier for applications to integrate Livepeer-powered streaming without reliance on Livepeer Studio.
Any development work will of course be published open-source and under the Unlicense.
Phase 1: Pilot
Goals
- Gather pain points from Gateway and Orchestrator operators.
- Prioritize roadmap items to address critical gaps in the transcoding pipeline.
- Set up a transcoding bounty program.
- Scope out the E2E media pipeline.
- Cross off the first few items from the roadmap.
Timeline
March 2025:
- Set up operations and governance structure.
- Identify and re-prioritize key tasks for this quarter.
- Launch a bounty board for community contributions.
- Initial discussions on FrameWorks infrastructure.
April – July 2025:
- Engineering work on Q2 key tasks, explained in the roadmap below.
- Next phase planning: Identifying FTE needs and define the FrameWorks infrastructure roadmap.
Roadmap
We have published a feature board where anyone can request items, vote on priorities, and comment on issues.
The roadmap will be prioritized based on continuous conversations with node operators, as well as the needs of inbound opportunities for our E2E media pipeline.
Initial Q2 goals are:
- Improve documentation for Gateway operators.
- Pull Netint integration over the finish line.
- Pull AV1 codec support over the finish line.
- Add Intel QSV support.
- Smarter session limits & load balancing for transcoders.
This roadmap indicates our short-term goals. Not all of these features might see completion in Q2.
Future Phases
If the pilot phase succeeds future requests may include:
- Expanding the core SPE team to increase engineering capacity.
- Addressing long-term goals and more complex tasks, including transitioning to a streaming workflow or expanding the Transcoding job type with more parameters (for example: allowing non-realtime, high quality transcodes for VoD processing).
- Further development & deployment of the FrameWorks E2E media pipeline.
Budget Breakdown
Funding Period: March – June 2025
Total Ask: 15,000 LPT
Breakdown:
| Item | Amount | Explanation |
|---|---|---|
| March: SPE Kickoff & onboarding | Free | Structuring the SPE, setting up communication channels, onboarding contributors, gathering feedback from Gateway & Orchestrator operators, initial design work on the E2E media pipeline. |
| April – June: Core Development | 12000 LPT | Managing bounties, active community participation, feature development, testing, and infrastructure work. |
| Community Incentives | 3000 LPT | Open-source contributor incentives to drive external contributions. |
Rate Justification
For 4,000 LPT per month, the MistServer team operates the SPE while providing 1 FTE of dedicated engineering work. At $5 per LPT, this equates to $20,000 a month (~$115/hr), which is a reduced bulk rate for long-term commitments. This ensures that developers assigned to the SPE remain fully committed, without being pulled into other commercial projects.
If future proposals require additional engineers, we can use the DDVTech entity to hire freelancers or full-timers. This approach allows us to:
- Offer security & guarantees to SPE hires through an established legal entity, of course with access to our office and team’s expertise for onboarding.
- Provide additional engineering capacity at a lower cost, ensuring efficient use of treasury funds.
We are open to adjusting the LPT request or FTE commitment based on community feedback, but believe the amounts are fair given the technical expertise required and in comparison with common rates in the media industry.
Success Metrics:
Defining success metrics for a broad core-development SPE like this is difficult. We encourage feedback on what we can do to measure impact and ensure accountability.
-
Core Contributions:
- Completed bounties.
- PRs submitted and merged into the Livepeer codebase.
- Increase in test coverage.
-
Feedback & Adoption:
- Positive feedback from Gateway & Orchestrator operators.
- Growth in the number of Gateway operators on the network, onboarded through the FrameWorks SPE.
- Transcoded minutes on the E2E media pipeline.
Transparency and Accountability
Engagement with protocol participants is an important part of this SPE. We will work closely with Gateway & Orchestrator operators to collect issues or requests to put on the feature board. We gather community input through multiple channels:
- Discord threads & forum discussions.
- a Canny task board to track development progress, request items or discuss tasks.
- Titan’s weekly water cooler sessions.
Leftover LPT will roll over into future proposals or return to the treasury if the SPE disbands for any reason.
Reporting:
- Quarterly progress reports will include:
- Amount of LPT spent, staked, or held.
- Progress on any of the success metrics.
", replyCount: 18, views: 842, likeCount: 52, datePosted: "Feb 22, 2025", lastActivity: "Mar 17, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Ecosystem Roadmap Update", href: "https://forum.livepeer.org/t/3234", author: "By b3nnn (@b3nnn)", content: "
Activating the Livepeer Ecosystem Roadmap — What’s Changing and How to Get Involved
The Ecosystem roadmap at roadmap.livepeer.org has never fully satisfied us. It’s basically been a display board rather than a genuine two-way system between the Contributors, Foundation and the broader community.
We’re now fixing that. I’ll explain what’s changing and what we need from everyone in the ecosystem.
What the Roadmap Is For
The roadmap exists to make ecosystem direction visible, coherent, and participatory.
It is not a promise or a project plan. It is a shared and evolving view of where the network is headed. This includes projects being worked on, who is driving them, and where there are opportunities to pick things up or get involved.
Every item on the roadmap defines a problem, a desired outcome, and who owns it. Items previously came from only two sources:
-
Advisory Board Recommendations — captured from the project with domain experts last year
-
Foundation Priorities — strategic improvements identified and funded by the Foundation
And, excitedly we now introduce a third way for things to enter the roadmap:
- Community Suggestions — ideas submitted and validated through our community process
In this way, the Roadmap becomes further signalling for the things people want to see come to the network, and a way for everyone to put forward impactful projects and provide upvotes are genuine input signals — not performative ones — towards what gets prioritised.
Why a Community Intake Process Matters
Until now, there has been no clear path for a community member to propose something and see it taken seriously without testing it with a formal forum post or completing an SPE proposal. A lot of great suggestions and discussions were had in Discord or raised on Watercooler’s, but with no structured process, no feedback loop, and no progress, many were lost.
That’s a problem for two reasons. First, the ecosystem has real expertise distributed across contributors, orchestrators, builders, and delegators. Some of the best ideas about what Livepeer needs to build next will come from people outside Inc and the Foundation. Second, without a visible process, community participation in the roadmap is essentially performative and people have no reason to engage if engagement doesn’t lead anywhere.
A real intake process changes that. It creates accountability on both sides: the community commits to submitting well-formed proposals and raising the standard of what we want to see from suggestions, and the Foundation commits to reviewing them, providing a space and rituals for them to see further discussion, and publishing those discussions and any decisions to help advance items in ways that make sense.
The New Community Suggestions Process
Anyone in the Livepeer ecosystem can now propose a roadmap item at any time. Here’s how it works:
Step 1 — Submit a proposal
Go to roadmap.livepeer.org and click “Suggest an Item” (in future you will be able to simply type /featurebase directly in Discord). A good proposal answers three things: What is the problem? Why does it matter for the ecosystem? What does success look like?
I’ve included two project “proposals” that were recommended as part of the discussions on the emissions system which can act as helpful examples and jumpstart the monthly call:
Step 2 — Community upvoting (ongoing)
All proposals are publicly visible in the roadmap with the tag “Propose Ecosystem Project”. Upvote and comment on proposals you care about at any time. Momentum is tracked — strong community support between monthly cycles can fast-track a proposal into the next review.
Step 3 — Foundation weekly review
We will aim to review the proposal queue every week and provide some feedback about how to prepare for the monthly Discord call. The aim here is to get things well prepared and to knock out early things that are maybe not going to reach a bar that we all feel is needed for high quality suggestions.
Step 4 — Monthly Discord call
Once a month proposals are presented on a community Discord call (if not the Watercooler, another forum). We’ll make a quick intro for each including upvotes and comments, the Proposer can give a short discussion, and then community asks questions and discusses live. After the call, the Foundation will publish key information and based on sentiment aim to reach a decision that can be shared: Promoted to Roadmap, Held for Next Cycle, or Declined with a public explanation.
Proposals that are promoted join the roadmap with status Under Review and from there move forward to planning - most likely as an RFP, a SPE Proposal, or some other mechanism that makes sense (more on this to come).
How to Use the Roadmap
The roadmap will work best when the community is actively engaged. We’ll start to talk about it more effectively on the Watercooler. But here’s what we need from you:
Upvote items you care about. This does two things: it signals priorities to the item owners, and it subscribes you to all future updates on that item. When an item’s status changes, you’ll be notified automatically. Your upvote has a visible consequence.
Comment on items. Share context, ask questions, flag concerns, or offer to contribute. Comments are read by item owners and the Foundation. Good comments surface edge cases and use cases that owners may not have considered. Good feedback here can shut things down before wasting everyones time, but also can give the right spark for a simple idea to be a gamechanger!
Follow the changelog at roadmap.livepeer.org/changelog. Every major milestone on a roadmap item generates a changelog entry. This is the progress reporting mechanism for the ecosystem — if you want to know what’s actually shipping, the changelog is where to look.
Propose new items if you think something important is missing. The bar for submitting is low — a clear problem statement, the reason is matters, and what the future looks like if that proposed item becomes a success. The intake process can take it from there. Items might make it to the roadmap, or be bundled or merged with others “under” an SPE.
For teams shipping roadmap items: update your item’s status when it changes (this auto-notifies everyone who upvoted), and post a changelog entry at each major milestone. The changelog is your public progress report — it replaces ad hoc updates scattered across Discord and forum threads.
A Note on What This Is Not
This is not a governance mechanism. In time this can become a good funnel for the onchain treasury but for now we want this to become a way to surface useful recommendations and priorities and created a clearer, more participatory and better recorded feedback loop. The proposed items and upvotes are strong input signals — not binding votes. This is intentional: it keeps the roadmap strategically coherent while ensuring community voice is genuinely considered and visibly acted upon.
If a proposal is declined, people will know why. Transparency is a key part of this commitment. And people can always still take things to a vote onchain.. this just raises the bar for proposing something if it’s already been tested with the community in this way
Get Started
The roadmap is already live at roadmap.livepeer.org. The suggestions board is open now.
If you’ve had something in mind that Livepeer shoud be building or capitalising on, now is a great time to share it. We will run the first Monthly call at the end of Mark. And if you have questions or feedback just drop them in here.
", replyCount: 0, views: 67, likeCount: 3, datePosted: "Mar 9, 2026", lastActivity: "Mar 9, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "Telegram Bot: Transcoder-Watcher", href: "https://forum.livepeer.org/t/609", author: "By vires-in-numeris (@vires-in-numeris)", content: "Over the past few days, I’ve been further developing the Transcoder Watcher Bot running in my 0x525 Transcoder Telegram Channel. It was my goal to create a tool that everyone can use to get notified about transcoder events and here it is:
The Telegram Transcoder-Watcher Bot!
You can find the bot here: https://t.me/TranscoderWatcher_bot
What does it do?
By writing “/start”, the bot will give you an introduction and informs about the available commands:
- subscribe
- remove
- subscriptions
- history
details here: Telegram Bot: Transcoder-Watcher
If you subscribe to a transcoder (or multiple, there is no limit), you will get notified about the following events:
- reward calls
- missing reward calls
- reward cut changes
- transcoder becomes inactive
Whenever possible, I include the transaction link so you can be sure that no incorrect information is sent. However, please note that the bot is still in the testing phase and of course it’s always possible that the script crashes and the bot stops working.
How does it look like?
Here are some screenshots for the various events.
- Reward Calls:
- Missing Reward Calls:
- Reward Cut changes:
- Transcoder becomes inactive:
If you discover any error or have feature requests, you can reply here or send me a message on discord!
", replyCount: 16, views: 5777, likeCount: 16, datePosted: "Mar 21, 2019", lastActivity: "Mar 8, 2026", categoryId: 7, categoryName: "Transcoders", categoryColor: "#25AAE2" }, { title: "AI capability discovery", href: "https://forum.livepeer.org/t/3233", author: "By chrishobcroft (@chrishobcroft)", content: "Can someone help me learn how to reliably query which AI capabilities and models the network offers?
I’m running a gateway on localhost with 0.065 deposit and 0.03 reserve. I’m managing to get some text-to-image jobs through, which is a great start.
Ideally it would be great to be able to query:
- all available job types,
- which models are available,
- what the O’s pricing is.
It seems like an obvious thing from my limited perspective, that an O will advertise its services to a G.
Any clues?
", replyCount: 0, views: 35, likeCount: 2, datePosted: "Mar 7, 2026", lastActivity: "Mar 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "Transcoder Campaign: lpt-gzp-node.eth", href: "https://forum.livepeer.org/t/2931", author: "By lpt-gzp-node.eth (@tryingout)", content: "Hi everyone! I’m running a Livepeer transcoder based in Slovenia since 2022, focused on reliability, sustainability, and geographical diversity in the network. I truly believe Livepeer has huge room to grow, and I’m in it for the long run.
Hardware setup:
- 2× NVIDIA GTX 1070 GPUs for rock-solid transcoding
- 1× NVIDIA RTX 3090 dedicated to the AI network
- Solar-powered when available
Current fee structure:
- Reward cut: 8%
- Fee cut: 49%
Cuts may lower as more LPT is staked — early delegators are rewarded!
If you’re looking to support a trustworthy, green, and diverse node, consider staking with me:
Delegate here
Got questions or just want to connect? Join me on Discord: @gasper5466
", replyCount: 12, views: 482, likeCount: 6, datePosted: "May 30, 2025", lastActivity: "Mar 4, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "Continuing discussions on Inflation", href: "https://forum.livepeer.org/t/3139", author: "By b3nnn (@b3nnn)", content: "Hey everyone, I wanted to use this post to reinvigorate the inflation discussion led by @dob in this thread earlier this year.
As a member of the Foundation, and as chair of the Capital Markets Advisory board, I think it’s important to keep us moving forward on this as it part of broader perceptions of the Livepeer project, is part of the broader industry focus on ‘fundamentals’, and is a key component of how capital is allocated within our ecosystem.
From previous discussions (and some new ones), it seems there is broad consensus on the need for small and incremental action. I see my role as helping give a little nudge so we take that small but important first step.
The previous draft from Dob got us to the starting line of what a proposal could look like. My personal tldr of the thread was that:
-
There was general alignment that we should start taking some action
-
There’s alignment on using existing parameters, which avoids risks or delays from new protocol or smart contract work
-
But.. the sticking point was whether to do that using
targetBondingRateorinflationChange, or both, and how to do it in a principled, risk aware way rather than using something that might feel a bit arbitrary
Reinforcing all of this, during the Livepeer summit Doug and Arunas /@Jonas_Pixelfield completed a hackathon project that both modeled parameter changes and surveyed a sizeable set of Orchestrators and Delegators on their perceptions. A short summary is that:
-
Simple modeling shows small parameter changes lead to effects over a fairly long time horizon (in the range of 12+ months to reach something that might be considered major change). This gives ample time to start, observe, and learn and adapt as necessary as we go
-
The survey and interviews further reinforced the consensus from Orchestrators and Delegators that they see the need for action, but sometimes struggle to find confidence with any given approach
With all this in mind, I want to share what we plan to do to help the community move forward:
-
Firstly, we want to keep discussing the Inflation topic with Orchestrators and Delegators. Two ways to do this include:
-
Completing a short survey to expand on your thoughts about the topic
-
Book a meeting where we can discuss or asnwer any questions in real time
-
-
Secondly, we intend to try to quantify the risks involved with some additional modeling. I’ve asked Andrew from Shtuka Research (who is a member of the Capital Markets Advisory board) to take the lead on this. Andrew is a mathematician with a long career in academic and applied research, who will help quantify the risks of different change scenarios. He’ll also be helping us build out a framework for continual risk monitoring and adjustment in the future, so that we can all have confidence to move forward to voting on any proposed changes.
Hopefully you agree that these goals are a relatively simple way to make that last important push and build on the broad consensus reached so far. This is not a one-and-done topic so we will share a bit more about what the path ahead could look like as we get more information.
I’m going to sign off here so that Andrew can share a bit more about the survey and modeling, and I’d encourage anyone who wants to chat on this topic to reach out to me direct via DM on Discord or by using my calendar link share above.
", replyCount: 20, views: 1045, likeCount: 50, datePosted: "Nov 5, 2025", lastActivity: "Mar 2, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }]; export const ScrollBox = ({children, maxHeight = 300, showHint = true, ariaLabel = "Scrollable content", style = {}, className = "", ...rest}) => { const contentRef = useRef(null); const [isOverflowing, setIsOverflowing] = useState(false); useEffect(() => { const checkOverflow = () => { if (contentRef.current) { const maxHeightPx = typeof maxHeight === "number" ? maxHeight : parseInt(maxHeight, 10) || 300; setIsOverflowing(contentRef.current.scrollHeight > maxHeightPx); } }; checkOverflow(); window.addEventListener("resize", checkOverflow); return () => window.removeEventListener("resize", checkOverflow); }, [maxHeight, children]); return} {label}
No videos at this time.
No announcements at this time.
No blog posts at this time.
No blog posts at this time.
Last Updated {socialFeedsLastUpdated}