", replyCount: 1, views: 114, likeCount: 4, datePosted: "Feb 10, 2026", lastActivity: "Mar 25, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Transcoder Campaign: NYC Philanthropy", href: "https://forum.livepeer.org/t/2229", author: "By NYCphilanthropy (@NYCphilanthropy)", content: "

Hi all, NYC Philanthropy here.
NYC Philanthropy Node on Livepeer Explorer

Our current LPT Reward/ETH Fee Cuts are: 50%/50%

This node has pledged at least 30% of this node’s Total ETH Fee earnings to be directed towards philanthropic efforts. Please keep updated on the donations at nycphilanthropy.com

", replyCount: 1, views: 308, likeCount: 2, datePosted: "Jan 12, 2024", lastActivity: "Feb 6, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { 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

", replyCount: 0, views: 37, likeCount: 2, datePosted: "Apr 7, 2026", lastActivity: "Apr 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { 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: 53, 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: 27, likeCount: 2, datePosted: "Mar 7, 2026", lastActivity: "Mar 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "AI SPE Phase 4 Retrospective", href: "https://forum.livepeer.org/t/3208", author: "By _ptr (@_ptr)", content: "

A retrospective on the last six months of work by the AI SPE per our Phase 4 Livepeer Treasury Proposal

Note: The AI SPE is now restructured under the name MuxionLabs.

Introduction

Phase 4 built on the Phase 3 real-time foundations by hardening Bring-Your-Own-Container (BYOC) workflows, expanding ComfyStream’s capabilities (including text/data-channel outputs and multimodal support), and shipping applied-research additions to the ComfyUI Stream Pack. The focus was to move from “prototype” to “repeatable experimentation” while unblocking a path to broader orchestrator and demand onboarding.

Significant progress was made toward productionizing the BYOC pipeline. BYOC streaming has been merged into go-livepeer with substantially reduced coupling to the existing ai-runner path and improved test coverage. Earlier work that did not made it into the main branch still served a valuable purpose by validating the core architecture and enabled testing sustained streaming workloads on the network.

During this process, earlier assumptions about directly embedding BYOC streaming into existing go-livepeer execution paths proved limiting. Addressing this required a deeper refactor than initially planned, resulting in a temporary revert and subsequent redesign. The outcome was a fully decoupled BYOC execution path and the emergence of PyTrickle as a standalone integration layer, enabling containerized Python workloads to participate in Livepeer streaming with minimal friction.

This tradeoff delayed some downstream milestones but materially strengthened the long-term viability of BYOC as a generalized, permissionless onboarding mechanism.

By the end of the phase, we materially stabilized the BYOC path in go-livepeer and made it a clearer, repeatable route for teams to bring new job types onto the network - this has unlocked the ability to onboard multiple demand sources without bespoke core integrations.

On the demand side, the Embody SPE has been pushing production workloads to the Livepeer Network via our BYOC solution for the past six months, recently transitioning to a custom implementation. The Streamplace integration is now complete and expected to go live in production shortly. In parallel, we’ve published multiple example applications at

showcasing fully end-to-end pipelines on Livepeer.

The AI SPE is in the process of rebranding as MuxionLabs.org, but this retrospective will refer to the original name as when we delivered the Phase 4 proposal.

Commitments Delivered

These Deliverables reflect the most meaningful progress made in Phase 4:

Stabilized BYOC batch processing

BYOC matured through hands-on iteration with the Embody SPE, BYOC batch-style request bugs were fixed and the batch path is now largely stable. This enables repeatable batch BYOC jobs on the open network.

BYOC streaming in production

BYOC streaming was implemented early in Phase 4 and successfully demonstrated sustained operation on the open network, running continuously for multiple hours. While the initial implementation was temporarily reverted to allow for additional review and test hardening, this work validated the core streaming architecture and clarified the remaining integration requirements with the core network stack.

Following this, we expanded test coverage, improved stability, fully decoupled the BYOC path into a standalone module, and landed the updated implementation in the main branch of go-livepeer. Ahead of the official merge, the Embody SPE has been actively leveraging this work via beta Docker images built from our go-livepeer fork.

ComfyStream Optimization and Expansion : text output + multimodal + BYOC

ComfyStream gained text output support for nodes such as audio transcription that produce data as opposed to images/video. Additional enhancements like dynamic warmup and automatic modality detection reduced operational friction and increased the range of workflows a single worker can serve.

We enabled ComfyStream to run on the Livepeer BYOC stack. Now ComfyStream can serve not only as a fast prototyping tool for new real-time video AI pipelines by developing workflows in ComfyUI, but also a robust solution for hosting multiple models and disparate workflow/pipelines on one orchestrator in a single container. Quickly warming up a new pipeline and models on demand - even mid stream - is a built in feature.

Stream Pack improvements and Real-Time Video Custom Nodes

4 sets of Custom Nodes were added to the ComfyUI Stream Pack.

StreamDiffusion + SDXL + TensorRT + Loras + Controlnets + IP-Adapters
- Ported from Livepeer INCs Daydream StreamDiffusion pipeline
StreamDiffusionV2
- Ported from Livepeer INCs Daydream StableDiffusion 2 pipeline
- Supports V2V & I2I
SuperResolution
- Real-time video upscaling
AudioTranscription + SRT
- Synchronizes captions into video output
- Alternately can output transcribed text only via dedicated data output custom node

The phase also produced four real-time ComfyStream pipeline/workflows accompanying these node sets, to enable creative generative real-time streaming video, audio transcription to a data channel (Whisper with text output), and transcription with SRT subtitles embedded in the output video segments.

In addition, we have implemented a simple, config based method to allow for developing and deploying workflows using custom nodes which have different underlying python package requirements. ComfyStream docker/dev containers can now be built with a user specified subset of supported Custom Nodes from the ComfyUI Stream Pack.

Delivered Beyond What Was Committed

Though these items were not explicitly specified in the scope of Phase 4, we determined that these strategically important force multipliers expand on the work that we have done on BYOC and ComfyStream in the spirit of our mission to make it easy to build on the Livepeer network.

Alternative worker integration path via PyTrickle

The AI SPE developed the PyTrickle BYOC package, which allows Python applications to operate as Livepeer AI workers outside the ai-runner integration path (livepeer/pytrickle). PyTrickle provides a modular BYOC serving model, enabling Python codebases to participate in the Livepeer network by importing a single package. Pytrickle docs can be found at https://muxionlabs.github.io/pytrickle/

We’ve also integrated PyTrickle into ComfyStream, demonstrating how an existing application can quickly adopt the BYOC stack while delivering a flexible, production-grade backend AI worker.

Developer Tooling for BYOC Streaming Experimentation

To lower the barrier for builders and orchestrators to develop and test real-time BYOC streaming pipelines, the AI SPE shipped example-apps.muxionlabs.org. This site showcases several ready-to-fork, BYOC-compatible open-source applications that demonstrate end-to-end streaming workflows on the Livepeer network. The underlying implementations live in the BYOC Example Apps GitHub repository, which also includes a lightweight web UI for testing PyTrickle- and BYOC-based pipelines.

In parallel, we published a TypeScript SDK for BYOC streaming (@muxionlabs/byoc-sdk) to simplify client-side integration. The SDK enables front-end applications to stream directly from the browser to a Livepeer Gateway without requiring a custom backend. It provides WebRTC streaming, data-channel support, device management, React hooks, and connection utilities such as retries, monitoring, and statistics.

Together, these tools reduce integration overhead and make it significantly easier to move from experimentation to deployable prototypes. They are already being used in practice by the Cloud SPE for validation and by orchestrators for debugging and pipeline testing.

ComfyUI Daydream API node

Recognizing an opportunity to translate emerging ecosystem demand into scalable, extensible infrastructure, the AI SPE developed the ComfyUI-RTC custom node set that enables real-time webRTC streaming workflows directly within ComfyUI, allowing users to connect live frame streams to external APIs and backend pipelines.

While Daydream served as an initial design partner, the node was intentionally built as a brand-agnostic integration layer that can support any compatible real-time generative or streaming backend.

The node includes a local RTC server that streams video frames to external services and supports bidirectional workflows, including extracting the latest frame from an active stream for downstream processing within ComfyUI. This architecture enables flexible composition of real-time pipelines without requiring a local GPU, across platforms.

By partnering with Livepeer Inc. and validating the integration through Daydream, this work identified a clear demand vector for real-time streaming within the ComfyUI ecosystem. At the same time, the generalized design positions the node as a reusable foundation for future integrations, enabling additional demand spikes and third-party adoption across the ComfyUI community.

Milestones (Retrospective Status)

Phase 4 was primarily focused on two objectives outlined in the proposal:

(1) maturing BYOC from an early prototype into a production-ready, permissionless pipeline, and

(2) expanding ComfyStream and the ComfyUI Stream Pack to broaden real-time AI demand on the Livepeer network.

While not all milestones were delivered exactly as originally scoped, the phase produced meaningful architectural progress, validated key assumptions, and resulted in durable infrastructure now landing in core Livepeer components.

Demand Partner Onboarding and Validation

The Agent SPE and Embody SPE served as primary early design partners throughout Phase 4. Extensive collaboration with these teams drove critical improvements to the BYOC stack, particularly around stability, execution semantics, and streaming behavior.

While the proposal targeted onboarding three additional demand partners, progress here was more incremental than planned. Work was initiated with Streamplace, including an MVP transcription pipeline and coordination with the repository owner; however, full onboarding was gated on additional go-livepeer changes currently under review. This experience reinforced the need to harden the core BYOC path before scaling partner onboarding.

Technical RFC and Public Roadmap

While BYOC RFC content was discussed publicly through watercoolers and ongoing conversations, a formal published RFC was not released during this phase. The PyTrickle library emerged as a foundational component of the BYOC stack, serving as the integration layer between Python-based, containerized applications and the Livepeer real-time streaming stack.

A comprehensive Technical RFC was completed in the form of the BYOC PyTrickle Engineering Spec for Custom Containers, defining the end-to-end architecture and serving as the canonical reference for BYOC development.

Similarly, while a public BYOC roadmap was discussed informally with stakeholders and partners, it was not released as a formal, published roadmap. This remains an actionable follow-up now unblocked by the stabilized architecture.

Orchestrator Onboarding

End-to-end validation of a fully production-ready BYOC pipeline on public orchestrators remains partially outstanding. While over a dozen orchestrators have been BYOC-backed workloads through collaboration with the Embody SPE and exercised via beta Docker images, broader onboarding was constrained by the earlier need to redesign BYOC’s integration with go-livepeer.

With the decoupled BYOC path now landed in the main branch the remaining work is primarily operational: merging final changes, deploying to orchestrators, and completing end-to-end validation on the public network.

ComfyStream and Stream Pack Expansion

Progress against ComfyStream and Stream Pack related milestones was strong and largely aligned with the objectives outlined in the Phase 4 proposal, particularly around expanding the diversity of real-time models, pipelines, and data-driven workflows available on the network.

Foundational real-time video models.

Three new real-time foundational video model nodes were delivered via the ComfyUI Stream Pack, meeting the proposal target:

StreamDiffusion
StreamDiffusion V2
Super Resolution

These nodes enable the community to build more diverse and higher-quality real-time creative workflows on Livepeer, and serve as reusable building blocks for both research-driven experimentation and partner-facing pipelines.

ComfyStream-enabled pipelines.

Five new ComfyStream-enabled pipelines were delivered, satisfying the milestone for demonstrating compelling, end-to-end workflows:

StreamDiffusion
StreamDiffusion V2
Real-time audio transcription
- Transcript output via data-channel
- Embedded Video Subtitles (SRT)
Video understanding via Gemma (BYOC container pipeline)
Generative video via a BYOC container pipeline

These pipelines demonstrate a range of capabilities spanning generative video, video intelligence, and hybrid video-plus-data workloads, and are intended to be reused by the ComfyStream creator community, internal research efforts, and external demand partners.

Data-channel–enabled models.

One data-channel–enabled model (real-time audio transcription) was delivered during the phase. While the proposal targeted three such models, early implementation work revealed that embedding data-channel support directly into the existing go-livepeer live-video-to-video path was overly restrictive. This led to a shift toward implementing data-channel support through the PyTrickle and BYOC architecture, resulting in a more flexible and extensible foundation for future data-channel–driven models.

Deferred Scope for Future Phases

Two items were intentionally deferred to future phases: publishing the BYOC Technical RFC and public roadmap, and scaling orchestrator and demand partner onboarding. Both were delayed to prioritize stabilizing and decoupling the BYOC streaming path in go-livepeer, ensuring the architecture is robust, reviewable, and suitable for long-term upstream support. With this foundation now in place, these efforts are unblocked and can proceed with greater clarity and confidence in subsequent phases.

Network Impact

Phase 4 strengthened Livepeer’s position as a viable platform for custom real-time AI workloads by materially reducing the engineering friction required for demand partners to bring their solutions on-network. By stabilizing the BYOC execution path and validating streaming use cases, we moved the ecosystem from bespoke core integrations toward a repeatable, modular onboarding flow.

This progress enables real world demand today:

The Embody SPE is actively running BYOC jobs, demonstrating that third-party workloads can be deployed and exercised on the network using the stabilized BYOC path and beta tooling.
The Streamplace transcription integration is in active staging and expected to go live soon, illustrating how external builders can extend Livepeer with new use cases without custom internal forks.
Multiple general reference pipelines (e.g.: generative video, video understanding, real-time transcription) published in the livepeer-app-pipelines repository provide concrete, runnable examples that other teams can fork and adapt without deep network expertise.

These outcomes matter because they convert architectural advancement into deployable demand use cases via scripts that builders and orchestrators can plug into and expand. While broader production hardening (orchestration stability, observability/metrics, SLA tooling) remains in flight, the engineering foundation now supports meaningful, concrete demand activity and makes future partner onboarding significantly easier.

Phase 4 didn’t just ship features, it unlocked the next wave of demand experimentation on Livepeer. Future phases will now focus on scaling that demand into reliable, open, fee-generating activity across more orchestrators and use cases.

Key Learnings

Shipping BYOC streaming required architectural maturity beyond ai-runner’s current state

Although BYOC streaming was technically viable early in the phase, attempting to integrate it too tightly into existing go-livepeer execution paths revealed shortcomings in testability, reviewability, and long-term maintainability. Decoupling the BYOC path and strengthening test coverage ultimately proved necessary to make the work acceptable for upstream inclusion and future iteration. This reinforced that production readiness on Livepeer depends as much on integration quality and operational clarity as on raw functionality.
Data-channel support meaningfully expanded the set of viable demand use cases

Adding first-class support for text and structured data alongside video unlocked concrete new workflows, most notably real-time transcription. These capabilities are already being exercised through ComfyStream pipelines and early partner integrations, and they broaden Livepeer’s applicability beyond purely generative video into video intelligence, analysis, and agent-driven use cases. This validated data channels as a key lever for diversifying network demand.
Hands-on usage by partners and operators surfaced the need for better developer tooling

Feedback from the Agent SPE, Cloud SPE, and orchestrators testing BYOC streaming highlighted that even well-designed APIs are insufficient without ergonomic tooling for debugging, iteration, and client-side integration. This directly motivated the creation of example BYOC applications and the TypeScript streaming SDK, which are now actively used for testing and validation. Reducing this friction is critical to moving from isolated prototypes to repeatable ecosystem experimentation.

Conclusion & What’s Next

Although several milestones were delivered later or differently than originally scoped, Phase 4 achieved its core objective: transforming BYOC from a promising prototype into a robust, extensible foundation for permissionless AI workload onboarding on Livepeer. The architectural decisions made during this phase — particularly around decoupling, modularization, and reuse — directly support the long-term strategy outlined in the proposal, even where short-term delivery targets shifted.

Using our newly shipped SDKs, new streaming BYOC streaming path through go-livepeer, and our proven pipelines, we have unlocked the ability to support the team’s goal of growing demand by making deployment easier, more reliable, and performant. Builders can now develop a deployable application on the Livepeer network either by using ComfyStream as a flexible real-time streaming backend, or by utilizing PyTrickle in their own container and the go-livepeer endpoints exposed by BYOC.

", replyCount: 0, views: 91, likeCount: 3, datePosted: "Jan 27, 2026", lastActivity: "Jan 27, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "Retroactive Report: Livepeer Open Source Sponsorship Initiative", href: "https://forum.livepeer.org/t/3207", author: "By Jason (@jjassonn69)", content: "

Overview

On March 14, 2025, a total of 5,000 LPT was transferred from the Livepeer Treasury to multisig safe wallet for the purpose of funding open-source software (OSS) sponsorships critical to the Livepeer ecosystem. At the time of transfer, this allocation was valued at approximately $26,128 USD, while its valuation at current prices is approximately $15,850 USD.

Rather than liquidating the full amount immediately, LPT was sold incrementally each month to match sponsorship requirements and administrative expenses. This approach minimized market impact and aligned cash flow with operational needs, though some value was lost due to price volatility and swap slippage when converting LPT to USDC.

After nine months of execution, the effective deployed budget total approximately $19,115 USD, resulting in an average realised value of $3.82 per LPT.

Administrative and Management Costs

Operational overhead was kept minimal and transparent. Over the nine-month period:

Breakdown:
- Accountant services: 2 hours @ $50/hour = $100 per month
- Project management: 5 hours @ $30/hour = $150 per month
Monthly total: $250
Total management time: 63 hours
Total administrative cost (9 months): $2,250 USD

Sponsorship Budget Allocation

Monthly sponsorship disbursements were structured as follows:

OSS Sponsorships: $1,875/month (approx.)
Administrative Fees: $250/month

This resulted in consistent support across the sponsorship period while maintaining sustainability amid LPT price fluctuations.

Project Scope Adjustments

Due to the reduction in LPT price during the execution period, the original project list proposed required adjustment. The following projects were excluded to remain within budget constraints:

Pydantic
Python-Multipart & Uvicorn
StreamV2V & StreamDiffusion
(These projects were privately sponsored by INC and therefore removed to avoid duplication.)

Final Sponsored Projects

Despite the reduced scope, the initiative successfully supported several high-impact open-source projects used directly or indirectly within the Livepeer stack:

oapi-codegen
imageio
OpenCV
ComfyUI-Depth-Anything-TensorRT
kin-openapi
FFmpeg
HiddenSwitch (ComfyUI fork)

Payment Infrastructure & Transparency

Most sponsorships were executed through GitHub Sponsors, enabling streamlined and transparent recurring payments. However, some projects—specifically FFmpeg and ComfyUI-TensorRT—required alternative payment methods such as PayPal or BuyMeACoffee, which were manually processed each month.

All payment receipts have been archived publicly for transparency and auditing purposes:

Receipts Repository:
https://github.com/oss-funding/.github/tree/main/payment-receipts

Additionally, monthly transaction summary has been documented to ensure full accountability.

Monthly Summery:

accounting/record-keeping.mdx

main

## OSS Funding Wallet Transactions This document tracks all outgoing transactions from the OSS funding wallet to ensure transparency and accountability. Each transaction entry includes the transaction hash and the amount sent. ### Transaction Records Below is a detailed list of transactions, ordered by date with the most recent first. #### Transaction Entry Format Each transaction follows this structure: - **Date**: The date when the transaction was made. - **Recipient**: The entity or address receiving the funds. - **Amount**: The amount transferred from the wallet. - **Transaction Hash**: Unique identifier for the transaction on the blockchain. - **Purpose**: Brief description of the transaction's purpose. #### Transactions List Current Balance Amount : 0 LPT

This file has been truncated. show original

Community Impact and Ecosystem Engagement

Beyond financial contributions, this initiative strengthened Livepeer’s relationship with upstream open-source maintainers:

The HiddenSwitch (ComfyUI) maintainer joined a Livepeer Watercooler call to discuss the impact of OSS funding and has since actively collaborated with the AI SPE team (Muxion Lab). He now helps synchronize updates from the main ComfyUI repository into the maintained HiddenSwitch fork for Comfystream.
The maintainer of oapi-codegen has agreed to participate in an upcoming Watercooler call to share insights from maintaining a widely used open-source project. Livepeer is now proudly displayed as a sponsor within the project’s repository, increasing ecosystem visibility.

Conclusion and Reflection

Although it was not possible to sponsor every open-source dependency within the Livepeer stack due to budget limitations, this initiative represents a critical first step toward building a sustainable OSS contribution model funded directly by the Livepeer Treasury.

As the project lead for this initiative, it has been both an honor and a privilege to manage Livepeer’s first treasury-funded open-source contribution program. This experiment demonstrates the tangible impact that decentralized networks can have on the broader software ecosystem and sets a strong precedent for future community-driven funding initiatives.

We hope this effort encourages further participation, transparency, and long-term investment in the open-source foundations that power Livepeer and the wider AI infrastructure landscape.

", replyCount: 0, views: 115, likeCount: 4, datePosted: "Jan 26, 2026", lastActivity: "Jan 26, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }]; export const forumByViews = [{ title: "Telegram Bot: Transcoder-Watcher", href: "https://forum.livepeer.org/t/609", author: "By vires-in-numeris (@vires-in-numeris)", content: "

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

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: 5769, likeCount: 16, datePosted: "Mar 21, 2019", lastActivity: "Mar 8, 2026", categoryId: 7, categoryName: "Transcoders", categoryColor: "#25AAE2" }, { 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.

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 targetBondingRate or inflationChange , or both, and how to do it in a principled, risk aware way rather than using something that might feel a bit arbitrary

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.

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).

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.

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 @rickstaa on 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.

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.

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

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 (LPMS and go-livepeer).
- Rich: Livepeer Ecosystem Growth Team

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

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

- Research & integrations

- Expanding testing & QA practices

- Bridging the DevOps gap for media applications

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

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

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.

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

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: 811, 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.

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

Deliverables

(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.

(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.

(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.

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 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.

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.

", replyCount: 11, views: 665, likeCount: 38, datePosted: "Dec 11, 2025", lastActivity: "Mar 28, 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: "

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: 468, likeCount: 6, datePosted: "May 30, 2025", lastActivity: "Mar 4, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "Transformation SPE Release Notes & Closing Retro", href: "https://forum.livepeer.org/t/3142", author: "By Mehrdad (@Mehrdad)", content: "

", replyCount: 5, views: 400, likeCount: 16, datePosted: "Nov 11, 2025", lastActivity: "Feb 28, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "Pre-Proposal: Supporting AI Artists: Livepeer’s Real-Time Video AI Showcase", href: "https://forum.livepeer.org/t/2682", author: "By rafkats (@rafkats)", content: "

Hi everyone!

We look forward to seeing hearing from the community and making sure the program feeds into the larger Livepeer vision!

Context

SPE Title: Supporting AI Artists: Livepeer’s Real-Time Video AI Showcase

Abstract

Mission

As Livepeer positions itself at the forefront of real-time AI video pipelines, this program offers a crucial step in showcasing practical applications of its technology. The mission is to:

Showcase how real-time AI video can enhance creative industries through artist-driven projects.
Foster a community of creators exploring innovative uses for Livepeer’s technology.
Deliver measurable engagement, adoption, and visibility for Livepeer’s platform.

This program aligns with the broader goals of Livepeer by using tangible use cases to inspire adoption and innovation, reinforcing Livepeer’s role as a leader in decentralized video infrastructure.

Rationale

By supporting creators and showcasing their work, the initiative will:

● Highlight Livepeer’s unique strengths in AI-powered media transformations.

● Build a community of developers and creators who actively use the network.

● Inspire broader adoption of Livepeer’s infrastructure through high-profile activations and digital showcases.

Key Terms

● AI-Powered Creativity: Leveraging Livepeer’s tools to apply real-time video transformations and data integration in creative projects.

● Creative Activations: Livepeer tentpole event at EthDenver blending technology, art, and culture to engage audiences.

SPE Governance Structure

● Core Team: Refraction will lead project execution, including artist curation, event production, and technical integration.

● Community Involvement: Broaden the grant committee to include voices from the Livepeer community to foster transparency and collaboration.

● Public Accountability: Publish detailed reports on funding allocations, project outcomes, and key insights to ensure alignment with Livepeer’s open ethos.

Milestones and Timeline

Key Milestones:

December 2024: SPE approval, outreach to artists, and initial ETHDenver planning.
January 2025: Launch full program; initiate artist workshops and project development.
February 2025: Execute ETHDenver activation, showcasing Livepeer-powered projects.
March 2025: Publish post-event report, distribute retroactive grants, and expand digital distribution efforts.

Timeline:

December 2024: Approval of SPE, outreach, and initial Denver production holds.
January 2025: Program launch, artist onboarding, and preparatory workshops.
February 2025: Event execution and project showcases.
March 2025: Post-event reporting and distribution.

Manpower, Tools, and Partnerships

Manpower: Event producers, technologists, marketing specialists, and curators.
Tools: Livepeer’s video streaming and real-time AI tools (e.g., Titles.xyz, Regenerate); communication platforms (Discord, Telegram, Towns).
Partnerships: Collaboration with Refraction, local artists, and ecosystem projects (eg,. UFO Club, The Lot Radio).

Budget Breakdown

Total Request: 4,000 LPT tokens.

Funding Grants for Artists (35%): 1,400 LPT.

○ Grants for 50–100 artists leveraging Livepeer tools for real-time AI-powered creations.

Event Costs (30%): 1,200 LPT.

○ Covers ETHDenver production, equipment rentals, and event logistics.

Team Costs (35%): 1400 LPT.

○ Support for ecosystem growth via curation, artist workshops, and technical implementation. Includes marketing costs - promotional content, digital distribution efforts, and post-event reporting.

Timeline for Fund Use

● December 2024: 50% of the total tokens allocated to cover pre-event planning, initial production costs, and marketing.

● January–February 2025: 40% of the total tokens used for event execution, including grants distribution, equipment rental, and staffing.

● March 2025: 10% of the total tokens reserved for post-event reporting and retroactive funding to highlight standout creator projects.

Expected Outcomes

KPIs:

Number of artists funded: At least 50 creators actively using Livepeer tools.
Number of AI-powered artworks created: Significant contributions by supported artists.
Network engagement: Increase in fees generated by artists and orchestrators.
Adoption metrics: Growth in creators integrating Livepeer’s infrastructure.

Reporting:

Publish a detailed post-event report in March 2025, including:

○ Artist feedback and outputs.

○ Engagement statistics and lessons learned.

○ Media coverage and adoption metrics.

Community Engagement: Solicit public feedback to improve future activations.

The Opportunity

Team

Additional Team Members
Our broader team includes individuals with significant experience in creative industries:

Contributors to Boiler Room, known for its cutting-edge cultural programming.
Collaborators with visionary creators like Virgil Abloh, demonstrating the ability to bridge high-profile art, culture, and technology.

This team’s combined expertise uniquely positions us to execute this initiative, attract top-tier talent, and ensure Livepeer’s tools reach creators and communities both inside and outside Web3.

", replyCount: 3, views: 396, likeCount: 11, datePosted: "Dec 12, 2024", lastActivity: "Feb 3, 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

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.

Despite this advantage, creating workloads within the Livepeer ecosystem remains exceedingly difficult due to the following barriers:

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

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.

Orchestrator Release Lifecycle agents package workloads, document release requirements, and move them through a clear operator onboarding and rollout path.

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.md and begins distribution outreach.

For orchestrators, this creates a faster path to new fee-generating workloads and lowers integration friction.

Economic Incentives

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.

5. What We Are Delivering (4-Month Scope)

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.md and 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.

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.

7. Addressing Past Feedback

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.

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: 385, likeCount: 39, datePosted: "Feb 17, 2026", lastActivity: "Apr 1, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Transcoder Campaign: NYC Philanthropy", href: "https://forum.livepeer.org/t/2229", author: "By NYCphilanthropy (@NYCphilanthropy)", content: "

Hi all, NYC Philanthropy here.
NYC Philanthropy Node on Livepeer Explorer

Our current LPT Reward/ETH Fee Cuts are: 50%/50%

This node has pledged at least 30% of this node’s Total ETH Fee earnings to be directed towards philanthropic efforts. Please keep updated on the donations at nycphilanthropy.com

", replyCount: 1, views: 308, likeCount: 2, datePosted: "Jan 12, 2024", lastActivity: "Feb 6, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "Metrics and SLA Foundations for NaaP", href: "https://forum.livepeer.org/t/3189", author: "By speedybird (@speedybird)", content: "

Cloud SPE Pre-Proposal: Network-as-a-Product (NaaP) MVP – SLA Metrics, Analytics, and Public Infrastructure

Abstract

Rationale

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.

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

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.

", replyCount: 12, views: 284, likeCount: 40, 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: "

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

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

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

", replyCount: 5, views: 281, likeCount: 11, datePosted: "Dec 11, 2025", lastActivity: "Mar 5, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "Pre-proposal: Put the brakes on LPT emissions", href: "https://forum.livepeer.org/t/3211", author: "By Andrew Macpherson (@awma)", content: "

It’s time to bring the discussion down to earth with a concrete proposal. Please read it here: [PROPOSAL]

For additional context, consult @dob’s discussion thread on LIP-100 from last March.

I will maintain an FAQ section in this post as discussion evolves.

FAQ

How will this affect Orchestrators and Delegators?

The upper tail of possible yield outcomes for H1 2026 comes down, reducing uncertainty. Yearly trailing yield remains above 60% with high confidence. See the relevant section of the proposal.

If we vote to pass this proposal, what happens after that? What do we do past the end of the forecast period?

Why do we want to do this?

How did you use the responses to the November survey?

How are emissions are on track to be higher than last year if participation is already over 50%?

What are the current parameters set to again? How much of a change is this?

The current value of targetBondingRate is equivalent to 50%. Our proposal is to reduce it by four percentage points. This is a much smaller reduction than has been considered in earlier models.

The outcome of these changes is so small, why are we bothering? Shouldn’t we be trying to drastically reduce emissions?

The current system is working as intended.

Not a question, but a sentiment we’ve seen enough times to warrant a response.

We asked the community what they think about the 50% target, and almost no one considered it a red line: anything over 40% bonding rate is perfectly fine. So if the price adjustment mechanism’s job is to keep the bonding rate over (or at) some threshold, there is no reason to insist that threshold be 50%.
We studied the performance of the adjustment mechanism from a theoretical and empirical perspective, and found little evidence to support the claim that very high emissions are necessary or sufficient for high participation. If they aren’t, it’s really unclear how they can be worth the risk of externalities, which have been discussed at length elsewhere.

Will this make the token price go up?

We should implement an emissions cap.

Shouldn’t we wait until fees are enough to sustain Os before cutting emissions?

Why should I, a staker, vote to prioritise non-stakers?

Acknowledgements

", replyCount: 3, views: 234, likeCount: 6, datePosted: "Jan 30, 2026", lastActivity: "Feb 26, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "LiveInfra SPE - Q1 2026 Operations", href: "https://forum.livepeer.org/t/3210", author: "By Joey (@ftkstaking)", content: "

Proposer: FTK Staking
Contact: admin@liveinfraspe.com
ENS: liveinfra.eth
Discord: @ftkuhnsman

Abstract

Mission

The LiveInfra SPE is dedicated to empowering the Livepeer community by providing free, reliable blockchain infrastructure services.

Problem and Importance

Rationale

Current Operations

Q1 2026 Operations Plan

Milestones and Timeline

January–March 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 (Q2 2026) to secure continued funding.

Budget Breakdown

Quarterly Recurring Costs - $16,500
- $9,000 USD - Infrastructure: Quarterly costs for high-quality cloud resources.
- $7,500 USD - Maintenance & Support: Quarterly node upkeep, software upgrades, database pruning, and user support.

Total Request USD: $16,500
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

", replyCount: 2, views: 129, likeCount: 5, datePosted: "Jan 27, 2026", lastActivity: "Feb 3, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Retroactive Report: Livepeer Open Source Sponsorship Initiative", href: "https://forum.livepeer.org/t/3207", author: "By Jason (@jjassonn69)", content: "

Overview

After nine months of execution, the effective deployed budget total approximately $19,115 USD, resulting in an average realised value of $3.82 per LPT.

Administrative and Management Costs

Operational overhead was kept minimal and transparent. Over the nine-month period:

Breakdown:
- Accountant services: 2 hours @ $50/hour = $100 per month
- Project management: 5 hours @ $30/hour = $150 per month
Monthly total: $250
Total management time: 63 hours
Total administrative cost (9 months): $2,250 USD

Sponsorship Budget Allocation

Monthly sponsorship disbursements were structured as follows:

OSS Sponsorships: $1,875/month (approx.)
Administrative Fees: $250/month

This resulted in consistent support across the sponsorship period while maintaining sustainability amid LPT price fluctuations.

Project Scope Adjustments

Due to the reduction in LPT price during the execution period, the original project list proposed required adjustment. The following projects were excluded to remain within budget constraints:

Pydantic
Python-Multipart & Uvicorn
StreamV2V & StreamDiffusion
(These projects were privately sponsored by INC and therefore removed to avoid duplication.)

Final Sponsored Projects

Despite the reduced scope, the initiative successfully supported several high-impact open-source projects used directly or indirectly within the Livepeer stack:

oapi-codegen
imageio
OpenCV
ComfyUI-Depth-Anything-TensorRT
kin-openapi
FFmpeg
HiddenSwitch (ComfyUI fork)

Payment Infrastructure & Transparency

All payment receipts have been archived publicly for transparency and auditing purposes:

Receipts Repository:
https://github.com/oss-funding/.github/tree/main/payment-receipts

Additionally, monthly transaction summary has been documented to ensure full accountability.

Monthly Summery:

accounting/record-keeping.mdx

main

## OSS Funding Wallet Transactions This document tracks all outgoing transactions from the OSS funding wallet to ensure transparency and accountability. Each transaction entry includes the transaction hash and the amount sent. ### Transaction Records Below is a detailed list of transactions, ordered by date with the most recent first. #### Transaction Entry Format Each transaction follows this structure: - **Date**: The date when the transaction was made. - **Recipient**: The entity or address receiving the funds. - **Amount**: The amount transferred from the wallet. - **Transaction Hash**: Unique identifier for the transaction on the blockchain. - **Purpose**: Brief description of the transaction's purpose. #### Transactions List Current Balance Amount : 0 LPT

This file has been truncated. show original

Community Impact and Ecosystem Engagement

Beyond financial contributions, this initiative strengthened Livepeer’s relationship with upstream open-source maintainers:

The HiddenSwitch (ComfyUI) maintainer joined a Livepeer Watercooler call to discuss the impact of OSS funding and has since actively collaborated with the AI SPE team (Muxion Lab). He now helps synchronize updates from the main ComfyUI repository into the maintained HiddenSwitch fork for Comfystream.
The maintainer of oapi-codegen has agreed to participate in an upcoming Watercooler call to share insights from maintaining a widely used open-source project. Livepeer is now proudly displayed as a sponsor within the project’s repository, increasing ecosystem visibility.

Conclusion and Reflection

We hope this effort encourages further participation, transparency, and long-term investment in the open-source foundations that power Livepeer and the wider AI infrastructure landscape.

", replyCount: 0, views: 115, likeCount: 4, datePosted: "Jan 26, 2026", lastActivity: "Jan 26, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "Embody Team: Updates", href: "https://forum.livepeer.org/t/3215", author: "By DeFine (@DeFine)", content: "

Embody Team: Retrospective

Date: February 9, 2026

Executive Summary: What We Shipped

•Incentives Pipeline: Delivered and maintained an orchestrator incentives program, funded from Embody-managed inference credits. This work was outside the strict Phase 2 scope.

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

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: 114, likeCount: 4, datePosted: "Feb 10, 2026", lastActivity: "Mar 25, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "AI SPE Phase 4 Retrospective", href: "https://forum.livepeer.org/t/3208", author: "By _ptr (@_ptr)", content: "

A retrospective on the last six months of work by the AI SPE per our Phase 4 Livepeer Treasury Proposal

Note: The AI SPE is now restructured under the name MuxionLabs.

Introduction

This tradeoff delayed some downstream milestones but materially strengthened the long-term viability of BYOC as a generalized, permissionless onboarding mechanism.

showcasing fully end-to-end pipelines on Livepeer.

The AI SPE is in the process of rebranding as MuxionLabs.org, but this retrospective will refer to the original name as when we delivered the Phase 4 proposal.

Commitments Delivered

These Deliverables reflect the most meaningful progress made in Phase 4:

Stabilized BYOC batch processing

BYOC streaming in production

ComfyStream Optimization and Expansion : text output + multimodal + BYOC

Stream Pack improvements and Real-Time Video Custom Nodes

4 sets of Custom Nodes were added to the ComfyUI Stream Pack.

StreamDiffusion + SDXL + TensorRT + Loras + Controlnets + IP-Adapters
- Ported from Livepeer INCs Daydream StreamDiffusion pipeline
StreamDiffusionV2
- Ported from Livepeer INCs Daydream StableDiffusion 2 pipeline
- Supports V2V & I2I
SuperResolution
- Real-time video upscaling
AudioTranscription + SRT
- Synchronizes captions into video output
- Alternately can output transcribed text only via dedicated data output custom node

Delivered Beyond What Was Committed

Alternative worker integration path via PyTrickle

We’ve also integrated PyTrickle into ComfyStream, demonstrating how an existing application can quickly adopt the BYOC stack while delivering a flexible, production-grade backend AI worker.

Developer Tooling for BYOC Streaming Experimentation

ComfyUI Daydream API node

While Daydream served as an initial design partner, the node was intentionally built as a brand-agnostic integration layer that can support any compatible real-time generative or streaming backend.

Milestones (Retrospective Status)

Phase 4 was primarily focused on two objectives outlined in the proposal:

(1) maturing BYOC from an early prototype into a production-ready, permissionless pipeline, and

(2) expanding ComfyStream and the ComfyUI Stream Pack to broaden real-time AI demand on the Livepeer network.

Demand Partner Onboarding and Validation

Technical RFC and Public Roadmap

Orchestrator Onboarding

ComfyStream and Stream Pack Expansion

Foundational real-time video models.

Three new real-time foundational video model nodes were delivered via the ComfyUI Stream Pack, meeting the proposal target:

StreamDiffusion
StreamDiffusion V2
Super Resolution

ComfyStream-enabled pipelines.

Five new ComfyStream-enabled pipelines were delivered, satisfying the milestone for demonstrating compelling, end-to-end workflows:

StreamDiffusion
StreamDiffusion V2
Real-time audio transcription
- Transcript output via data-channel
- Embedded Video Subtitles (SRT)
Video understanding via Gemma (BYOC container pipeline)
Generative video via a BYOC container pipeline

Data-channel–enabled models.

Deferred Scope for Future Phases

Network Impact

This progress enables real world demand today:

The Embody SPE is actively running BYOC jobs, demonstrating that third-party workloads can be deployed and exercised on the network using the stabilized BYOC path and beta tooling.
The Streamplace transcription integration is in active staging and expected to go live soon, illustrating how external builders can extend Livepeer with new use cases without custom internal forks.
Multiple general reference pipelines (e.g.: generative video, video understanding, real-time transcription) published in the livepeer-app-pipelines repository provide concrete, runnable examples that other teams can fork and adapt without deep network expertise.

Key Learnings

Shipping BYOC streaming required architectural maturity beyond ai-runner’s current state

Although BYOC streaming was technically viable early in the phase, attempting to integrate it too tightly into existing go-livepeer execution paths revealed shortcomings in testability, reviewability, and long-term maintainability. Decoupling the BYOC path and strengthening test coverage ultimately proved necessary to make the work acceptable for upstream inclusion and future iteration. This reinforced that production readiness on Livepeer depends as much on integration quality and operational clarity as on raw functionality.
Data-channel support meaningfully expanded the set of viable demand use cases

Adding first-class support for text and structured data alongside video unlocked concrete new workflows, most notably real-time transcription. These capabilities are already being exercised through ComfyStream pipelines and early partner integrations, and they broaden Livepeer’s applicability beyond purely generative video into video intelligence, analysis, and agent-driven use cases. This validated data channels as a key lever for diversifying network demand.
Hands-on usage by partners and operators surfaced the need for better developer tooling

Feedback from the Agent SPE, Cloud SPE, and orchestrators testing BYOC streaming highlighted that even well-designed APIs are insufficient without ergonomic tooling for debugging, iteration, and client-side integration. This directly motivated the creation of example BYOC applications and the TypeScript streaming SDK, which are now actively used for testing and validation. Reducing this friction is critical to moving from isolated prototypes to repeatable ecosystem experimentation.

Conclusion & What’s Next

", replyCount: 0, views: 91, likeCount: 3, datePosted: "Jan 27, 2026", lastActivity: "Jan 27, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { 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

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.

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

Why a Community Intake Process Matters

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

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)

Step 3 — Foundation weekly review

Step 4 — Monthly Discord call

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:

A Note on What This Is Not

Get Started

The roadmap is already live at roadmap.livepeer.org. The suggestions board is open now.

", replyCount: 0, views: 53, likeCount: 3, datePosted: "Mar 9, 2026", lastActivity: "Mar 9, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { 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

Team Structure Updates

Dane decided to move on from WEAVE for personal reasons, and we parted on good terms.

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’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

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

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

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

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

", replyCount: 0, views: 37, likeCount: 2, datePosted: "Apr 7, 2026", lastActivity: "Apr 7, 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: 27, likeCount: 2, datePosted: "Mar 7, 2026", lastActivity: "Mar 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }]; export const forumByNewest = [{ 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

Team Structure Updates

Dane decided to move on from WEAVE for personal reasons, and we parted on good terms.

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’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

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

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

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

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

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.

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

Why a Community Intake Process Matters

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

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)

Step 3 — Foundation weekly review

Step 4 — Monthly Discord call

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:

A Note on What This Is Not

Get Started

The roadmap is already live at roadmap.livepeer.org. The suggestions board is open now.

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: 27, 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

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.

Despite this advantage, creating workloads within the Livepeer ecosystem remains exceedingly difficult due to the following barriers:

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

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.

Orchestrator Release Lifecycle agents package workloads, document release requirements, and move them through a clear operator onboarding and rollout path.

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.md and begins distribution outreach.

For orchestrators, this creates a faster path to new fee-generating workloads and lowers integration friction.

Economic Incentives

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.

5. What We Are Delivering (4-Month Scope)

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.md and 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.

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.

7. Addressing Past Feedback

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.

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: 385, 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

Executive Summary: What We Shipped

•Incentives Pipeline: Delivered and maintained an orchestrator incentives program, funded from Embody-managed inference credits. This work was outside the strict Phase 2 scope.

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

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: 114, likeCount: 4, datePosted: "Feb 10, 2026", lastActivity: "Mar 25, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Pre-proposal: Put the brakes on LPT emissions", href: "https://forum.livepeer.org/t/3211", author: "By Andrew Macpherson (@awma)", content: "

It’s time to bring the discussion down to earth with a concrete proposal. Please read it here: [PROPOSAL]

For additional context, consult @dob’s discussion thread on LIP-100 from last March.

I will maintain an FAQ section in this post as discussion evolves.

FAQ

How will this affect Orchestrators and Delegators?

The upper tail of possible yield outcomes for H1 2026 comes down, reducing uncertainty. Yearly trailing yield remains above 60% with high confidence. See the relevant section of the proposal.

If we vote to pass this proposal, what happens after that? What do we do past the end of the forecast period?

Why do we want to do this?

How did you use the responses to the November survey?

How are emissions are on track to be higher than last year if participation is already over 50%?

What are the current parameters set to again? How much of a change is this?

The current value of targetBondingRate is equivalent to 50%. Our proposal is to reduce it by four percentage points. This is a much smaller reduction than has been considered in earlier models.

The outcome of these changes is so small, why are we bothering? Shouldn’t we be trying to drastically reduce emissions?

The current system is working as intended.

Not a question, but a sentiment we’ve seen enough times to warrant a response.

We asked the community what they think about the 50% target, and almost no one considered it a red line: anything over 40% bonding rate is perfectly fine. So if the price adjustment mechanism’s job is to keep the bonding rate over (or at) some threshold, there is no reason to insist that threshold be 50%.
We studied the performance of the adjustment mechanism from a theoretical and empirical perspective, and found little evidence to support the claim that very high emissions are necessary or sufficient for high participation. If they aren’t, it’s really unclear how they can be worth the risk of externalities, which have been discussed at length elsewhere.

Will this make the token price go up?

We should implement an emissions cap.

Shouldn’t we wait until fees are enough to sustain Os before cutting emissions?

Why should I, a staker, vote to prioritise non-stakers?

Acknowledgements

", replyCount: 3, views: 234, likeCount: 6, datePosted: "Jan 30, 2026", lastActivity: "Feb 26, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "LiveInfra SPE - Q1 2026 Operations", href: "https://forum.livepeer.org/t/3210", author: "By Joey (@ftkstaking)", content: "

Proposer: FTK Staking
Contact: admin@liveinfraspe.com
ENS: liveinfra.eth
Discord: @ftkuhnsman

Abstract

Mission

The LiveInfra SPE is dedicated to empowering the Livepeer community by providing free, reliable blockchain infrastructure services.

Problem and Importance

Rationale

Current Operations

Q1 2026 Operations Plan

Milestones and Timeline

January–March 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 (Q2 2026) to secure continued funding.

Budget Breakdown

Quarterly Recurring Costs - $16,500
- $9,000 USD - Infrastructure: Quarterly costs for high-quality cloud resources.
- $7,500 USD - Maintenance & Support: Quarterly node upkeep, software upgrades, database pruning, and user support.

Total Request USD: $16,500
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

", replyCount: 2, views: 129, likeCount: 5, datePosted: "Jan 27, 2026", lastActivity: "Feb 3, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "AI SPE Phase 4 Retrospective", href: "https://forum.livepeer.org/t/3208", author: "By _ptr (@_ptr)", content: "

A retrospective on the last six months of work by the AI SPE per our Phase 4 Livepeer Treasury Proposal

Note: The AI SPE is now restructured under the name MuxionLabs.

Introduction

This tradeoff delayed some downstream milestones but materially strengthened the long-term viability of BYOC as a generalized, permissionless onboarding mechanism.

showcasing fully end-to-end pipelines on Livepeer.

The AI SPE is in the process of rebranding as MuxionLabs.org, but this retrospective will refer to the original name as when we delivered the Phase 4 proposal.

Commitments Delivered

These Deliverables reflect the most meaningful progress made in Phase 4:

Stabilized BYOC batch processing

BYOC streaming in production

ComfyStream Optimization and Expansion : text output + multimodal + BYOC

Stream Pack improvements and Real-Time Video Custom Nodes

4 sets of Custom Nodes were added to the ComfyUI Stream Pack.

StreamDiffusion + SDXL + TensorRT + Loras + Controlnets + IP-Adapters
- Ported from Livepeer INCs Daydream StreamDiffusion pipeline
StreamDiffusionV2
- Ported from Livepeer INCs Daydream StableDiffusion 2 pipeline
- Supports V2V & I2I
SuperResolution
- Real-time video upscaling
AudioTranscription + SRT
- Synchronizes captions into video output
- Alternately can output transcribed text only via dedicated data output custom node

Delivered Beyond What Was Committed

Alternative worker integration path via PyTrickle

We’ve also integrated PyTrickle into ComfyStream, demonstrating how an existing application can quickly adopt the BYOC stack while delivering a flexible, production-grade backend AI worker.

Developer Tooling for BYOC Streaming Experimentation

ComfyUI Daydream API node

While Daydream served as an initial design partner, the node was intentionally built as a brand-agnostic integration layer that can support any compatible real-time generative or streaming backend.

Milestones (Retrospective Status)

Phase 4 was primarily focused on two objectives outlined in the proposal:

(1) maturing BYOC from an early prototype into a production-ready, permissionless pipeline, and

(2) expanding ComfyStream and the ComfyUI Stream Pack to broaden real-time AI demand on the Livepeer network.

Demand Partner Onboarding and Validation

Technical RFC and Public Roadmap

Orchestrator Onboarding

ComfyStream and Stream Pack Expansion

Foundational real-time video models.

Three new real-time foundational video model nodes were delivered via the ComfyUI Stream Pack, meeting the proposal target:

StreamDiffusion
StreamDiffusion V2
Super Resolution

ComfyStream-enabled pipelines.

Five new ComfyStream-enabled pipelines were delivered, satisfying the milestone for demonstrating compelling, end-to-end workflows:

StreamDiffusion
StreamDiffusion V2
Real-time audio transcription
- Transcript output via data-channel
- Embedded Video Subtitles (SRT)
Video understanding via Gemma (BYOC container pipeline)
Generative video via a BYOC container pipeline

Data-channel–enabled models.

Deferred Scope for Future Phases

Network Impact

This progress enables real world demand today:

The Embody SPE is actively running BYOC jobs, demonstrating that third-party workloads can be deployed and exercised on the network using the stabilized BYOC path and beta tooling.
The Streamplace transcription integration is in active staging and expected to go live soon, illustrating how external builders can extend Livepeer with new use cases without custom internal forks.
Multiple general reference pipelines (e.g.: generative video, video understanding, real-time transcription) published in the livepeer-app-pipelines repository provide concrete, runnable examples that other teams can fork and adapt without deep network expertise.

Key Learnings

Shipping BYOC streaming required architectural maturity beyond ai-runner’s current state

Although BYOC streaming was technically viable early in the phase, attempting to integrate it too tightly into existing go-livepeer execution paths revealed shortcomings in testability, reviewability, and long-term maintainability. Decoupling the BYOC path and strengthening test coverage ultimately proved necessary to make the work acceptable for upstream inclusion and future iteration. This reinforced that production readiness on Livepeer depends as much on integration quality and operational clarity as on raw functionality.
Data-channel support meaningfully expanded the set of viable demand use cases

Adding first-class support for text and structured data alongside video unlocked concrete new workflows, most notably real-time transcription. These capabilities are already being exercised through ComfyStream pipelines and early partner integrations, and they broaden Livepeer’s applicability beyond purely generative video into video intelligence, analysis, and agent-driven use cases. This validated data channels as a key lever for diversifying network demand.
Hands-on usage by partners and operators surfaced the need for better developer tooling

Feedback from the Agent SPE, Cloud SPE, and orchestrators testing BYOC streaming highlighted that even well-designed APIs are insufficient without ergonomic tooling for debugging, iteration, and client-side integration. This directly motivated the creation of example BYOC applications and the TypeScript streaming SDK, which are now actively used for testing and validation. Reducing this friction is critical to moving from isolated prototypes to repeatable ecosystem experimentation.

Conclusion & What’s Next

Overview

After nine months of execution, the effective deployed budget total approximately $19,115 USD, resulting in an average realised value of $3.82 per LPT.

Administrative and Management Costs

Operational overhead was kept minimal and transparent. Over the nine-month period:

Breakdown:
- Accountant services: 2 hours @ $50/hour = $100 per month
- Project management: 5 hours @ $30/hour = $150 per month
Monthly total: $250
Total management time: 63 hours
Total administrative cost (9 months): $2,250 USD

Sponsorship Budget Allocation

Monthly sponsorship disbursements were structured as follows:

OSS Sponsorships: $1,875/month (approx.)
Administrative Fees: $250/month

This resulted in consistent support across the sponsorship period while maintaining sustainability amid LPT price fluctuations.

Project Scope Adjustments

Due to the reduction in LPT price during the execution period, the original project list proposed required adjustment. The following projects were excluded to remain within budget constraints:

Pydantic
Python-Multipart & Uvicorn
StreamV2V & StreamDiffusion
(These projects were privately sponsored by INC and therefore removed to avoid duplication.)

Final Sponsored Projects

Despite the reduced scope, the initiative successfully supported several high-impact open-source projects used directly or indirectly within the Livepeer stack:

oapi-codegen
imageio
OpenCV
ComfyUI-Depth-Anything-TensorRT
kin-openapi
FFmpeg
HiddenSwitch (ComfyUI fork)

Payment Infrastructure & Transparency

All payment receipts have been archived publicly for transparency and auditing purposes:

Receipts Repository:
https://github.com/oss-funding/.github/tree/main/payment-receipts

Additionally, monthly transaction summary has been documented to ensure full accountability.

Monthly Summery:

accounting/record-keeping.mdx

main

## OSS Funding Wallet Transactions This document tracks all outgoing transactions from the OSS funding wallet to ensure transparency and accountability. Each transaction entry includes the transaction hash and the amount sent. ### Transaction Records Below is a detailed list of transactions, ordered by date with the most recent first. #### Transaction Entry Format Each transaction follows this structure: - **Date**: The date when the transaction was made. - **Recipient**: The entity or address receiving the funds. - **Amount**: The amount transferred from the wallet. - **Transaction Hash**: Unique identifier for the transaction on the blockchain. - **Purpose**: Brief description of the transaction's purpose. #### Transactions List Current Balance Amount : 0 LPT

This file has been truncated. show original

Community Impact and Ecosystem Engagement

Beyond financial contributions, this initiative strengthened Livepeer’s relationship with upstream open-source maintainers:

The HiddenSwitch (ComfyUI) maintainer joined a Livepeer Watercooler call to discuss the impact of OSS funding and has since actively collaborated with the AI SPE team (Muxion Lab). He now helps synchronize updates from the main ComfyUI repository into the maintained HiddenSwitch fork for Comfystream.
The maintainer of oapi-codegen has agreed to participate in an upcoming Watercooler call to share insights from maintaining a widely used open-source project. Livepeer is now proudly displayed as a sponsor within the project’s repository, increasing ecosystem visibility.

Conclusion and Reflection

We hope this effort encourages further participation, transparency, and long-term investment in the open-source foundations that power Livepeer and the wider AI infrastructure landscape.

", replyCount: 0, views: 115, likeCount: 4, datePosted: "Jan 26, 2026", lastActivity: "Jan 26, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "Metrics and SLA Foundations for NaaP", href: "https://forum.livepeer.org/t/3189", author: "By speedybird (@speedybird)", content: "

Cloud SPE Pre-Proposal: Network-as-a-Product (NaaP) MVP – SLA Metrics, Analytics, and Public Infrastructure

Abstract

Rationale

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.

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

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.

", replyCount: 12, views: 284, likeCount: 40, 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.

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

Deliverables

(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.

(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.

(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.

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 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.

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.

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

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

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

", replyCount: 5, views: 400, likeCount: 16, datePosted: "Nov 11, 2025", lastActivity: "Feb 28, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { 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.

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 targetBondingRate or inflationChange , or both, and how to do it in a principled, risk aware way rather than using something that might feel a bit arbitrary

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.

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).

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.

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 @rickstaa on 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.

", replyCount: 19, views: 893, likeCount: 43, datePosted: "Sep 18, 2025", lastActivity: "Mar 31, 2026", categoryId: 21, categoryName: "RFP Applications", categoryColor: "#8C6238" }, { title: "Transcoder Campaign: lpt-gzp-node.eth", href: "https://forum.livepeer.org/t/2931", author: "By lpt-gzp-node.eth (@tryingout)", content: "

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: 468, likeCount: 6, datePosted: "May 30, 2025", lastActivity: "Mar 4, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { 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.

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

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 (LPMS and go-livepeer).
- Rich: Livepeer Ecosystem Growth Team

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

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

- Research & integrations

- Expanding testing & QA practices

- Bridging the DevOps gap for media applications

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

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

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.

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

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: 811, likeCount: 52, datePosted: "Feb 22, 2025", lastActivity: "Mar 17, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Pre-Proposal: Supporting AI Artists: Livepeer’s Real-Time Video AI Showcase", href: "https://forum.livepeer.org/t/2682", author: "By rafkats (@rafkats)", content: "

Hi everyone!

We look forward to seeing hearing from the community and making sure the program feeds into the larger Livepeer vision!

Context

SPE Title: Supporting AI Artists: Livepeer’s Real-Time Video AI Showcase

Abstract

Mission

As Livepeer positions itself at the forefront of real-time AI video pipelines, this program offers a crucial step in showcasing practical applications of its technology. The mission is to:

Showcase how real-time AI video can enhance creative industries through artist-driven projects.
Foster a community of creators exploring innovative uses for Livepeer’s technology.
Deliver measurable engagement, adoption, and visibility for Livepeer’s platform.

This program aligns with the broader goals of Livepeer by using tangible use cases to inspire adoption and innovation, reinforcing Livepeer’s role as a leader in decentralized video infrastructure.

Rationale

By supporting creators and showcasing their work, the initiative will:

● Highlight Livepeer’s unique strengths in AI-powered media transformations.

● Build a community of developers and creators who actively use the network.

● Inspire broader adoption of Livepeer’s infrastructure through high-profile activations and digital showcases.

Key Terms

● AI-Powered Creativity: Leveraging Livepeer’s tools to apply real-time video transformations and data integration in creative projects.

● Creative Activations: Livepeer tentpole event at EthDenver blending technology, art, and culture to engage audiences.

SPE Governance Structure

● Core Team: Refraction will lead project execution, including artist curation, event production, and technical integration.

● Community Involvement: Broaden the grant committee to include voices from the Livepeer community to foster transparency and collaboration.

● Public Accountability: Publish detailed reports on funding allocations, project outcomes, and key insights to ensure alignment with Livepeer’s open ethos.

Milestones and Timeline

Key Milestones:

December 2024: SPE approval, outreach to artists, and initial ETHDenver planning.
January 2025: Launch full program; initiate artist workshops and project development.
February 2025: Execute ETHDenver activation, showcasing Livepeer-powered projects.
March 2025: Publish post-event report, distribute retroactive grants, and expand digital distribution efforts.

Timeline:

December 2024: Approval of SPE, outreach, and initial Denver production holds.
January 2025: Program launch, artist onboarding, and preparatory workshops.
February 2025: Event execution and project showcases.
March 2025: Post-event reporting and distribution.

Manpower, Tools, and Partnerships

Manpower: Event producers, technologists, marketing specialists, and curators.
Tools: Livepeer’s video streaming and real-time AI tools (e.g., Titles.xyz, Regenerate); communication platforms (Discord, Telegram, Towns).
Partnerships: Collaboration with Refraction, local artists, and ecosystem projects (eg,. UFO Club, The Lot Radio).

Budget Breakdown

Total Request: 4,000 LPT tokens.

Funding Grants for Artists (35%): 1,400 LPT.

○ Grants for 50–100 artists leveraging Livepeer tools for real-time AI-powered creations.

Event Costs (30%): 1,200 LPT.

○ Covers ETHDenver production, equipment rentals, and event logistics.

Team Costs (35%): 1400 LPT.

○ Support for ecosystem growth via curation, artist workshops, and technical implementation. Includes marketing costs - promotional content, digital distribution efforts, and post-event reporting.

Timeline for Fund Use

● December 2024: 50% of the total tokens allocated to cover pre-event planning, initial production costs, and marketing.

● January–February 2025: 40% of the total tokens used for event execution, including grants distribution, equipment rental, and staffing.

● March 2025: 10% of the total tokens reserved for post-event reporting and retroactive funding to highlight standout creator projects.

Expected Outcomes

KPIs:

Number of artists funded: At least 50 creators actively using Livepeer tools.
Number of AI-powered artworks created: Significant contributions by supported artists.
Network engagement: Increase in fees generated by artists and orchestrators.
Adoption metrics: Growth in creators integrating Livepeer’s infrastructure.

Reporting:

Publish a detailed post-event report in March 2025, including:

○ Artist feedback and outputs.

○ Engagement statistics and lessons learned.

○ Media coverage and adoption metrics.

Community Engagement: Solicit public feedback to improve future activations.

The Opportunity

Team

Additional Team Members
Our broader team includes individuals with significant experience in creative industries:

Contributors to Boiler Room, known for its cutting-edge cultural programming.
Collaborators with visionary creators like Virgil Abloh, demonstrating the ability to bridge high-profile art, culture, and technology.

This team’s combined expertise uniquely positions us to execute this initiative, attract top-tier talent, and ensure Livepeer’s tools reach creators and communities both inside and outside Web3.

", replyCount: 3, views: 396, likeCount: 11, datePosted: "Dec 12, 2024", lastActivity: "Feb 3, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Transcoder Campaign: NYC Philanthropy", href: "https://forum.livepeer.org/t/2229", author: "By NYCphilanthropy (@NYCphilanthropy)", content: "

Hi all, NYC Philanthropy here.
NYC Philanthropy Node on Livepeer Explorer

Our current LPT Reward/ETH Fee Cuts are: 50%/50%

This node has pledged at least 30% of this node’s Total ETH Fee earnings to be directed towards philanthropic efforts. Please keep updated on the donations at nycphilanthropy.com

", replyCount: 1, views: 308, likeCount: 2, datePosted: "Jan 12, 2024", lastActivity: "Feb 6, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "Telegram Bot: Transcoder-Watcher", href: "https://forum.livepeer.org/t/609", author: "By vires-in-numeris (@vires-in-numeris)", content: "

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

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: 5769, likeCount: 16, datePosted: "Mar 21, 2019", lastActivity: "Mar 8, 2026", categoryId: 7, categoryName: "Transcoders", categoryColor: "#25AAE2" }]; export const forumData = [{ title: "Metrics and SLA Foundations for NaaP", href: "https://forum.livepeer.org/t/3189", author: "By speedybird (@speedybird)", content: "

Cloud SPE Pre-Proposal: Network-as-a-Product (NaaP) MVP – SLA Metrics, Analytics, and Public Infrastructure

Abstract

Rationale

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.

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

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.

", replyCount: 12, views: 284, likeCount: 40, datePosted: "Jan 10, 2026", lastActivity: "Apr 14, 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

Team Structure Updates

Dane decided to move on from WEAVE for personal reasons, and we parted on good terms.

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’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

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

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

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

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

", replyCount: 0, views: 37, likeCount: 2, datePosted: "Apr 7, 2026", lastActivity: "Apr 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

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.

Despite this advantage, creating workloads within the Livepeer ecosystem remains exceedingly difficult due to the following barriers:

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

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.

Orchestrator Release Lifecycle agents package workloads, document release requirements, and move them through a clear operator onboarding and rollout path.

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.md and begins distribution outreach.

For orchestrators, this creates a faster path to new fee-generating workloads and lowers integration friction.

Economic Incentives

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.

5. What We Are Delivering (4-Month Scope)

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.md and 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.

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.

7. Addressing Past Feedback

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.

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: 385, likeCount: 39, datePosted: "Feb 17, 2026", lastActivity: "Apr 1, 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).

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.

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 @rickstaa on 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.

", replyCount: 19, views: 893, likeCount: 43, datePosted: "Sep 18, 2025", lastActivity: "Mar 31, 2026", categoryId: 21, categoryName: "RFP Applications", categoryColor: "#8C6238" }, { 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.

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

Deliverables

(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.

(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.

(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.

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 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.

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.

", replyCount: 11, views: 665, likeCount: 38, datePosted: "Dec 11, 2025", lastActivity: "Mar 28, 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

Executive Summary: What We Shipped

•Incentives Pipeline: Delivered and maintained an orchestrator incentives program, funded from Embody-managed inference credits. This work was outside the strict Phase 2 scope.

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

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: 114, 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.

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

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 (LPMS and go-livepeer).
- Rich: Livepeer Ecosystem Growth Team

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

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

- Research & integrations

- Expanding testing & QA practices

- Bridging the DevOps gap for media applications

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

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

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.

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

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: 811, 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

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.

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

Why a Community Intake Process Matters

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

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)

Step 3 — Foundation weekly review

Step 4 — Monthly Discord call

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:

A Note on What This Is Not

Get Started

The roadmap is already live at roadmap.livepeer.org. The suggestions board is open now.

", replyCount: 0, views: 53, 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: "

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

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: 5769, 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: 27, likeCount: 2, datePosted: "Mar 7, 2026", lastActivity: "Mar 7, 2026", categoryId: 1, categoryName: "Uncategorized", categoryColor: "#AB9364" }, { title: "Lisar SPE Release Notes", href: "https://forum.livepeer.org/t/3159", author: "By serial_winner (@serial_winner)", content: "

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

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

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

", replyCount: 5, views: 281, likeCount: 11, datePosted: "Dec 11, 2025", lastActivity: "Mar 5, 2026", categoryId: 8, categoryName: "Updates", categoryColor: "#9EB83B" }, { title: "Transcoder Campaign: lpt-gzp-node.eth", href: "https://forum.livepeer.org/t/2931", author: "By lpt-gzp-node.eth (@tryingout)", content: "

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: 468, 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.

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 targetBondingRate or inflationChange , or both, and how to do it in a principled, risk aware way rather than using something that might feel a bit arbitrary

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.

", replyCount: 20, views: 1006, likeCount: 50, datePosted: "Nov 5, 2025", lastActivity: "Mar 2, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Transformation SPE Release Notes & Closing Retro", href: "https://forum.livepeer.org/t/3142", author: "By Mehrdad (@Mehrdad)", content: "

It’s time to bring the discussion down to earth with a concrete proposal. Please read it here: [PROPOSAL]

For additional context, consult @dob’s discussion thread on LIP-100 from last March.

I will maintain an FAQ section in this post as discussion evolves.

FAQ

How will this affect Orchestrators and Delegators?

The upper tail of possible yield outcomes for H1 2026 comes down, reducing uncertainty. Yearly trailing yield remains above 60% with high confidence. See the relevant section of the proposal.

If we vote to pass this proposal, what happens after that? What do we do past the end of the forecast period?

Why do we want to do this?

How did you use the responses to the November survey?

How are emissions are on track to be higher than last year if participation is already over 50%?

What are the current parameters set to again? How much of a change is this?

The current value of targetBondingRate is equivalent to 50%. Our proposal is to reduce it by four percentage points. This is a much smaller reduction than has been considered in earlier models.

The outcome of these changes is so small, why are we bothering? Shouldn’t we be trying to drastically reduce emissions?

The current system is working as intended.

Not a question, but a sentiment we’ve seen enough times to warrant a response.

We asked the community what they think about the 50% target, and almost no one considered it a red line: anything over 40% bonding rate is perfectly fine. So if the price adjustment mechanism’s job is to keep the bonding rate over (or at) some threshold, there is no reason to insist that threshold be 50%.
We studied the performance of the adjustment mechanism from a theoretical and empirical perspective, and found little evidence to support the claim that very high emissions are necessary or sufficient for high participation. If they aren’t, it’s really unclear how they can be worth the risk of externalities, which have been discussed at length elsewhere.

Will this make the token price go up?

We should implement an emissions cap.

Shouldn’t we wait until fees are enough to sustain Os before cutting emissions?

Why should I, a staker, vote to prioritise non-stakers?

Acknowledgements

", replyCount: 3, views: 234, likeCount: 6, datePosted: "Jan 30, 2026", lastActivity: "Feb 26, 2026", categoryId: 17, categoryName: "Governance", categoryColor: "#0088CC" }, { title: "Transcoder Campaign: NYC Philanthropy", href: "https://forum.livepeer.org/t/2229", author: "By NYCphilanthropy (@NYCphilanthropy)", content: "

Hi all, NYC Philanthropy here.
NYC Philanthropy Node on Livepeer Explorer

Our current LPT Reward/ETH Fee Cuts are: 50%/50%

This node has pledged at least 30% of this node’s Total ETH Fee earnings to be directed towards philanthropic efforts. Please keep updated on the donations at nycphilanthropy.com

", replyCount: 1, views: 308, likeCount: 2, datePosted: "Jan 12, 2024", lastActivity: "Feb 6, 2026", categoryId: 14, categoryName: "Uncategorized", categoryColor: "#808281" }, { title: "LiveInfra SPE - Q1 2026 Operations", href: "https://forum.livepeer.org/t/3210", author: "By Joey (@ftkstaking)", content: "

Proposer: FTK Staking
Contact: admin@liveinfraspe.com
ENS: liveinfra.eth
Discord: @ftkuhnsman

Abstract

Mission

The LiveInfra SPE is dedicated to empowering the Livepeer community by providing free, reliable blockchain infrastructure services.

Problem and Importance

Rationale

Current Operations

Q1 2026 Operations Plan

Milestones and Timeline

January–March 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 (Q2 2026) to secure continued funding.

Budget Breakdown

Quarterly Recurring Costs - $16,500
- $9,000 USD - Infrastructure: Quarterly costs for high-quality cloud resources.
- $7,500 USD - Maintenance & Support: Quarterly node upkeep, software upgrades, database pruning, and user support.

Total Request USD: $16,500
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

", replyCount: 2, views: 129, likeCount: 5, datePosted: "Jan 27, 2026", lastActivity: "Feb 3, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "Pre-Proposal: Supporting AI Artists: Livepeer’s Real-Time Video AI Showcase", href: "https://forum.livepeer.org/t/2682", author: "By rafkats (@rafkats)", content: "

Hi everyone!

We look forward to seeing hearing from the community and making sure the program feeds into the larger Livepeer vision!

Context

SPE Title: Supporting AI Artists: Livepeer’s Real-Time Video AI Showcase

Abstract

Mission

As Livepeer positions itself at the forefront of real-time AI video pipelines, this program offers a crucial step in showcasing practical applications of its technology. The mission is to:

Showcase how real-time AI video can enhance creative industries through artist-driven projects.
Foster a community of creators exploring innovative uses for Livepeer’s technology.
Deliver measurable engagement, adoption, and visibility for Livepeer’s platform.

This program aligns with the broader goals of Livepeer by using tangible use cases to inspire adoption and innovation, reinforcing Livepeer’s role as a leader in decentralized video infrastructure.

Rationale

By supporting creators and showcasing their work, the initiative will:

● Highlight Livepeer’s unique strengths in AI-powered media transformations.

● Build a community of developers and creators who actively use the network.

● Inspire broader adoption of Livepeer’s infrastructure through high-profile activations and digital showcases.

Key Terms

● AI-Powered Creativity: Leveraging Livepeer’s tools to apply real-time video transformations and data integration in creative projects.

● Creative Activations: Livepeer tentpole event at EthDenver blending technology, art, and culture to engage audiences.

SPE Governance Structure

● Core Team: Refraction will lead project execution, including artist curation, event production, and technical integration.

● Community Involvement: Broaden the grant committee to include voices from the Livepeer community to foster transparency and collaboration.

● Public Accountability: Publish detailed reports on funding allocations, project outcomes, and key insights to ensure alignment with Livepeer’s open ethos.

Milestones and Timeline

Key Milestones:

December 2024: SPE approval, outreach to artists, and initial ETHDenver planning.
January 2025: Launch full program; initiate artist workshops and project development.
February 2025: Execute ETHDenver activation, showcasing Livepeer-powered projects.
March 2025: Publish post-event report, distribute retroactive grants, and expand digital distribution efforts.

Timeline:

December 2024: Approval of SPE, outreach, and initial Denver production holds.
January 2025: Program launch, artist onboarding, and preparatory workshops.
February 2025: Event execution and project showcases.
March 2025: Post-event reporting and distribution.

Manpower, Tools, and Partnerships

Manpower: Event producers, technologists, marketing specialists, and curators.
Tools: Livepeer’s video streaming and real-time AI tools (e.g., Titles.xyz, Regenerate); communication platforms (Discord, Telegram, Towns).
Partnerships: Collaboration with Refraction, local artists, and ecosystem projects (eg,. UFO Club, The Lot Radio).

Budget Breakdown

Total Request: 4,000 LPT tokens.

Funding Grants for Artists (35%): 1,400 LPT.

○ Grants for 50–100 artists leveraging Livepeer tools for real-time AI-powered creations.

Event Costs (30%): 1,200 LPT.

○ Covers ETHDenver production, equipment rentals, and event logistics.

Team Costs (35%): 1400 LPT.

○ Support for ecosystem growth via curation, artist workshops, and technical implementation. Includes marketing costs - promotional content, digital distribution efforts, and post-event reporting.

Timeline for Fund Use

● December 2024: 50% of the total tokens allocated to cover pre-event planning, initial production costs, and marketing.

● January–February 2025: 40% of the total tokens used for event execution, including grants distribution, equipment rental, and staffing.

● March 2025: 10% of the total tokens reserved for post-event reporting and retroactive funding to highlight standout creator projects.

Expected Outcomes

KPIs:

Number of artists funded: At least 50 creators actively using Livepeer tools.
Number of AI-powered artworks created: Significant contributions by supported artists.
Network engagement: Increase in fees generated by artists and orchestrators.
Adoption metrics: Growth in creators integrating Livepeer’s infrastructure.

Reporting:

Publish a detailed post-event report in March 2025, including:

○ Artist feedback and outputs.

○ Engagement statistics and lessons learned.

○ Media coverage and adoption metrics.

Community Engagement: Solicit public feedback to improve future activations.

The Opportunity

Team

Additional Team Members
Our broader team includes individuals with significant experience in creative industries:

Contributors to Boiler Room, known for its cutting-edge cultural programming.
Collaborators with visionary creators like Virgil Abloh, demonstrating the ability to bridge high-profile art, culture, and technology.

This team’s combined expertise uniquely positions us to execute this initiative, attract top-tier talent, and ensure Livepeer’s tools reach creators and communities both inside and outside Web3.

", replyCount: 3, views: 396, likeCount: 11, datePosted: "Dec 12, 2024", lastActivity: "Feb 3, 2026", categoryId: 18, categoryName: "Treasury", categoryColor: "#ebef0b" }, { title: "AI SPE Phase 4 Retrospective", href: "https://forum.livepeer.org/t/3208", author: "By _ptr (@_ptr)", content: "

A retrospective on the last six months of work by the AI SPE per our Phase 4 Livepeer Treasury Proposal

Note: The AI SPE is now restructured under the name MuxionLabs.

Introduction

This tradeoff delayed some downstream milestones but materially strengthened the long-term viability of BYOC as a generalized, permissionless onboarding mechanism.

showcasing fully end-to-end pipelines on Livepeer.

The AI SPE is in the process of rebranding as MuxionLabs.org, but this retrospective will refer to the original name as when we delivered the Phase 4 proposal.

Commitments Delivered

These Deliverables reflect the most meaningful progress made in Phase 4:

Stabilized BYOC batch processing

BYOC streaming in production

ComfyStream Optimization and Expansion : text output + multimodal + BYOC

Stream Pack improvements and Real-Time Video Custom Nodes

4 sets of Custom Nodes were added to the ComfyUI Stream Pack.

StreamDiffusion + SDXL + TensorRT + Loras + Controlnets + IP-Adapters
- Ported from Livepeer INCs Daydream StreamDiffusion pipeline
StreamDiffusionV2
- Ported from Livepeer INCs Daydream StableDiffusion 2 pipeline
- Supports V2V & I2I
SuperResolution
- Real-time video upscaling
AudioTranscription + SRT
- Synchronizes captions into video output
- Alternately can output transcribed text only via dedicated data output custom node

Delivered Beyond What Was Committed

Alternative worker integration path via PyTrickle

We’ve also integrated PyTrickle into ComfyStream, demonstrating how an existing application can quickly adopt the BYOC stack while delivering a flexible, production-grade backend AI worker.

Developer Tooling for BYOC Streaming Experimentation

ComfyUI Daydream API node

While Daydream served as an initial design partner, the node was intentionally built as a brand-agnostic integration layer that can support any compatible real-time generative or streaming backend.

Milestones (Retrospective Status)

Phase 4 was primarily focused on two objectives outlined in the proposal:

(1) maturing BYOC from an early prototype into a production-ready, permissionless pipeline, and

(2) expanding ComfyStream and the ComfyUI Stream Pack to broaden real-time AI demand on the Livepeer network.

Demand Partner Onboarding and Validation

Technical RFC and Public Roadmap

Orchestrator Onboarding

ComfyStream and Stream Pack Expansion

Foundational real-time video models.

Three new real-time foundational video model nodes were delivered via the ComfyUI Stream Pack, meeting the proposal target:

StreamDiffusion
StreamDiffusion V2
Super Resolution

ComfyStream-enabled pipelines.

Five new ComfyStream-enabled pipelines were delivered, satisfying the milestone for demonstrating compelling, end-to-end workflows:

StreamDiffusion
StreamDiffusion V2
Real-time audio transcription
- Transcript output via data-channel
- Embedded Video Subtitles (SRT)
Video understanding via Gemma (BYOC container pipeline)
Generative video via a BYOC container pipeline

Data-channel–enabled models.

Deferred Scope for Future Phases

Network Impact

This progress enables real world demand today:

The Embody SPE is actively running BYOC jobs, demonstrating that third-party workloads can be deployed and exercised on the network using the stabilized BYOC path and beta tooling.
The Streamplace transcription integration is in active staging and expected to go live soon, illustrating how external builders can extend Livepeer with new use cases without custom internal forks.
Multiple general reference pipelines (e.g.: generative video, video understanding, real-time transcription) published in the livepeer-app-pipelines repository provide concrete, runnable examples that other teams can fork and adapt without deep network expertise.

Key Learnings

Shipping BYOC streaming required architectural maturity beyond ai-runner’s current state

Although BYOC streaming was technically viable early in the phase, attempting to integrate it too tightly into existing go-livepeer execution paths revealed shortcomings in testability, reviewability, and long-term maintainability. Decoupling the BYOC path and strengthening test coverage ultimately proved necessary to make the work acceptable for upstream inclusion and future iteration. This reinforced that production readiness on Livepeer depends as much on integration quality and operational clarity as on raw functionality.
Data-channel support meaningfully expanded the set of viable demand use cases

Adding first-class support for text and structured data alongside video unlocked concrete new workflows, most notably real-time transcription. These capabilities are already being exercised through ComfyStream pipelines and early partner integrations, and they broaden Livepeer’s applicability beyond purely generative video into video intelligence, analysis, and agent-driven use cases. This validated data channels as a key lever for diversifying network demand.
Hands-on usage by partners and operators surfaced the need for better developer tooling

Feedback from the Agent SPE, Cloud SPE, and orchestrators testing BYOC streaming highlighted that even well-designed APIs are insufficient without ergonomic tooling for debugging, iteration, and client-side integration. This directly motivated the creation of example BYOC applications and the TypeScript streaming SDK, which are now actively used for testing and validation. Reducing this friction is critical to moving from isolated prototypes to repeatable ecosystem experimentation.

Conclusion & What’s Next

Overview

After nine months of execution, the effective deployed budget total approximately $19,115 USD, resulting in an average realised value of $3.82 per LPT.

Administrative and Management Costs

Operational overhead was kept minimal and transparent. Over the nine-month period:

Breakdown:
- Accountant services: 2 hours @ $50/hour = $100 per month
- Project management: 5 hours @ $30/hour = $150 per month
Monthly total: $250
Total management time: 63 hours
Total administrative cost (9 months): $2,250 USD

Sponsorship Budget Allocation

Monthly sponsorship disbursements were structured as follows:

OSS Sponsorships: $1,875/month (approx.)
Administrative Fees: $250/month

This resulted in consistent support across the sponsorship period while maintaining sustainability amid LPT price fluctuations.

Project Scope Adjustments

Due to the reduction in LPT price during the execution period, the original project list proposed required adjustment. The following projects were excluded to remain within budget constraints:

Pydantic
Python-Multipart & Uvicorn
StreamV2V & StreamDiffusion
(These projects were privately sponsored by INC and therefore removed to avoid duplication.)

Final Sponsored Projects

Despite the reduced scope, the initiative successfully supported several high-impact open-source projects used directly or indirectly within the Livepeer stack:

oapi-codegen
imageio
OpenCV
ComfyUI-Depth-Anything-TensorRT
kin-openapi
FFmpeg
HiddenSwitch (ComfyUI fork)

Payment Infrastructure & Transparency

All payment receipts have been archived publicly for transparency and auditing purposes:

Receipts Repository:
https://github.com/oss-funding/.github/tree/main/payment-receipts

Additionally, monthly transaction summary has been documented to ensure full accountability.

Monthly Summery: