"use strict"; const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0]; const {useMDXComponents: _provideComponents} = arguments[0]; const discordAnnouncementsData = [{ id: "1486303511787602010", content: "📣 Monthly Updates & Retros Are Due! 📣

Please post your February monthly update or retrospective as a reply under your original proposal.
For guidance, refer to the Monthly Update Guide and Retro Guide.

The following teams have already shared theirs:

", author: "_alisonwonderland", timestamp: "2026-03-25T09:59:31.394Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1486303511787602010" }, { id: "1486303464345702520", content: "📣 The CloudSPE proposal is live. 🗳️ 📣

The proposal funds Cloud SPE to build a focused MVP for standardized, publicly observable network performance, reliability, and demand metrics, making the network measurable and comparable while laying the groundwork for future SLA-aware routing and scaling.

Vote Yes ✅ or No ❌ here", author: "_alisonwonderland", timestamp: "2026-03-25T09:59:20.083Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1486303464345702520" }, { id: "1486303431873527941", content: "📣 Vote now on the Protocol R&D SPE 🗳️ 📣

All network value depends on protocol security. The proposal argues for a dedicated, continuously staffed function for protocol security, upgrades, and core improvements, replacing the current ad hoc model with a single accountable structure.

Vote Yes ✅ or No ❌ here", author: "_alisonwonderland", timestamp: "2026-03-25T09:59:12.341Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1486303431873527941" }, { id: "1486303296984453240", content: "🦃🦃🦃 November #2 Community Update 🦃🦃🦃

Big Moments

📈 Network fees last week were \$15,826 with a stable fee baseline in November. Participation rate is
51.7% - a three year high; the inflation rate is decreasing, currently at 0.06835%.

<:daydream:1435328189311488060> Daydream Scope, created by <@380038770520489986>, added LoRA Support in Scope v0.1.0a7. Read more here.

🔐 The new bot measures has again curbed spam in the server. Beware of a new tactic - Bots are adding links into their bio. We are exploring measures to remove these bots. Never click links in the bio of unverified sources.

Upcoming Events

Livepeer Fireside -
Watercooler Chat -

Other Updates

🟣 Muxion Labs

<@&1303105760661606450>'s <@488172209823678474> created a new Daydream Comfy Custom Node with an updated interface. If you want to see it in action - watch this week's Watercooler Chat here! The link goes directly to the demo timestamp.

🏛️ Livepeer Foundation

Livepeer Foundation has been making progress towards the Transformation SPE goals:

<@781667568942841866> posted progress on updating our documentation here
<@537817645140017153> digested the feedback from the Inflation Survey here
Guild has made improvements to the Explorer

<@&1433161182143053864> members & <@423592125406380042> were in Argentina for DevConnect - See <@543292258980593664> review of the conference https://discord.com/channels/423160867534929930/426106677650128898/1441545466323144734

Livepeer Fireside

Watch the most recent Fireside here.

Last Fireside's agenda:

<@515896144560128000> from Embody Network updating on progress
<@389895972102209551> from Embody Network presenting Embody AI creator

❌ Missed an event?

If you miss any events, check out our Youtube here.

Asking again: What do we want for Livepeer in 2026? Please drop your opinions in <#426106677650128898> 🦃🪞

Watercooler Chat | November 24 2025

Tune into our weekly Watercooler Chat to discuss pressing topics from community members.
- - -
Connect with Livepeer on Socials:
Twitter: https://twitter.com/Livepeer
Discord: https://discord.gg/uaPhtyrWsF
Telegram: https://t.me/livepeerorg
Reddit: https://www.reddit.com/r/livepeer/
Blog: https://medium.com/livepeer-blog
Forum: https://forum...

$\"Watercooler$

RFP - Documentation Restructure

Hello all! Thank you for welcoming me at today's Watercooler Chat [Slides here] where I provided a few key Documentation updates, which I'm also sharing below. Sharing the latest structured update on the Livepeer Documentation Restructure, aligned with the RFP goals outlined here: RFP - Documentation Restructure - #10 by honestly_rich...

$\"RFP$

Continuing discussions on Inflation

Quick update on the survey: We have a good number (25) of results now, so I'll be closing the survey at midnight UTC on Thursday. That means that the last day to fill out the form is Wednesday (in the morning if you're in Argentina). I'll then synthesise the answers and share a summary here this Friday. Edit: The survey is now closed. ...

Livepeer Fireside | November 12 2025

Join our weekly Fireside where we discuss the most important happenings within our ecosystem. The heavy hitters of the community present their updates. Tap in!
- - -
Connect with Livepeer on Socials:
Twitter: https://twitter.com/Livepeer
Discord: https://discord.gg/uaPhtyrWsF
Telegram: https://t.me/livepeerorg
Reddit: https://www.reddit.com/...

$\"Livepeer$

", author: "_alisonwonderland", timestamp: "2026-03-25T09:58:40.181Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1486303296984453240" }, { id: "1483220726331740373", content: "Livepeer #🎙│announcements", author: "_alisonwonderland", timestamp: "2026-03-16T21:49:38.066Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1483220726331740373" }, { id: "1473413137410560030", content: "Livepeer #🎙│announcements", author: "_alisonwonderland", timestamp: "2026-02-17T20:17:46.651Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1473413137410560030" }, { id: "1463397885272920138", content: "📣 The CloudSPE proposal is live. 🗳️ 📣

The proposal funds Cloud SPE to build a focused MVP for standardized, publicly observable network performance, reliability, and demand metrics, making the network measurable and comparable while laying the groundwork for future SLA-aware routing and scaling.

Vote Yes ✅ or No ❌ here", author: "_alisonwonderland", timestamp: "2026-01-21T05:00:44.467Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1463397885272920138" }, { id: "1463397844890288351", content: "📣 Vote now on the Protocol R&D SPE 🗳️ 📣

All network value depends on protocol security. The proposal argues for a dedicated, continuously staffed function for protocol security, upgrades, and core improvements, replacing the current ad hoc model with a single accountable structure.

Vote Yes ✅ or No ❌ here", author: "_alisonwonderland", timestamp: "2026-01-21T05:00:34.839Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1463397844890288351" }, { id: "1463392024576266301", content: "Livepeer #🎙│announcements", author: "_alisonwonderland", timestamp: "2026-01-21T04:37:27.168Z", url: "https://discord.com/channels/1066890817425387581/1463391944746078319/1463392024576266301" }]; const youtubeData = [{ title: 'Livepeer Fireside (11)', href: 'https://www.youtube.com/watch?v=Kf2V6d90oqk', author: 'By Livepeer', content: '——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Dec 18, 2025', duration: 'PT51M23S', thumbnailUrl: 'https://i.ytimg.com/vi/Kf2V6d90oqk/hqdefault.jpg' }, { title: 'Livepeer Fireside', href: 'https://www.youtube.com/watch?v=NYczXgZ_oLg', author: 'By Livepeer', content: '——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Dec 3, 2025', duration: 'PT15M55S', thumbnailUrl: 'https://i.ytimg.com/vi/NYczXgZ_oLg/hqdefault.jpg' }, { title: 'Livepeer Fireside 📱', href: 'https://www.youtube.com/watch?v=CnuyKyms6qg', author: 'By Livepeer', content: '——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Dec 3, 2025', duration: 'PT15M53S', thumbnailUrl: 'https://i.ytimg.com/vi/CnuyKyms6qg/hqdefault.jpg' }, { title: 'Watercooler Chat | December 1 2025', href: 'https://www.youtube.com/watch?v=LmZNEaOOb9I', author: 'By Livepeer', content: 'Tune into our weekly Watercooler Chat to discuss pressing topics from community members. ——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Dec 1, 2025', duration: 'PT40M4S', thumbnailUrl: 'https://i.ytimg.com/vi/LmZNEaOOb9I/hqdefault.jpg' }, { title: 'Livepeer Fireside 📱', href: 'https://www.youtube.com/watch?v=hz9oorf8g-A', author: 'By Livepeer', content: '——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 27, 2025', duration: 'PT58M29S', thumbnailUrl: 'https://i.ytimg.com/vi/hz9oorf8g-A/hqdefault.jpg' }, { title: 'Livepeer Fireside', href: 'https://www.youtube.com/watch?v=qiy1GFAgs2E', author: 'By Livepeer', content: '——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 27, 2025', duration: 'PT58M31S', thumbnailUrl: 'https://i.ytimg.com/vi/qiy1GFAgs2E/hqdefault.jpg' }, { title: 'Livepeer Fireside | November 26 2025', href: 'https://www.youtube.com/watch?v=GNC__DEpxOY', author: 'By Livepeer', content: 'Join our weekly Fireside where we discuss the most important happenings within our ecosystem. The heavy hitters of the community present their updates. Tap in! ——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 26, 2025', duration: 'PT53M21S', thumbnailUrl: 'https://i.ytimg.com/vi/GNC__DEpxOY/hqdefault.jpg' }, { title: 'Watercooler Chat | November 24 2025', href: 'https://www.youtube.com/watch?v=9rZh5d_wRlI', author: 'By Livepeer', content: 'Tune into our weekly Watercooler Chat to discuss pressing topics from community members. ——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 24, 2025', duration: 'PT1H5M38S', thumbnailUrl: 'https://i.ytimg.com/vi/9rZh5d_wRlI/hqdefault.jpg' }, { title: 'Watercooler Chat | November 17 2025', href: 'https://www.youtube.com/watch?v=X0z2o3b5LEo', author: 'By Livepeer', content: 'Tune into our weekly Watercooler Chat to discuss pressing topics from community members. ——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 18, 2025', duration: 'PT1H36M3S', thumbnailUrl: 'https://i.ytimg.com/vi/X0z2o3b5LEo/hqdefault.jpg' }, { title: 'Livepeer Fireside | November 12 2025', href: 'https://www.youtube.com/watch?v=Uw7cdZLx7kA', author: 'By Livepeer', content: 'Join our weekly Fireside where we discuss the most important happenings within our ecosystem. The heavy hitters of the community present their updates. Tap in! ——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 12, 2025', duration: 'PT42M2S', thumbnailUrl: 'https://i.ytimg.com/vi/Uw7cdZLx7kA/hqdefault.jpg' }, { title: 'Eric Tang | Live in Lisbon Summit 2025 by Livepeer', href: 'https://www.youtube.com/watch?v=-iO7HsR3KE4', author: 'By Livepeer', content: 'A deep dive into Daydream, the real-time video Ai gateway for the Livepeer network. ——— Connect with Livepeer on Socials: Website: https://www.livepeer.org/ Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 11, 2025', duration: 'PT22M10S', thumbnailUrl: 'https://i.ytimg.com/vi/-iO7HsR3KE4/hqdefault.jpg' }, { title: 'Watercooler Chat | November 10 2025', href: 'https://www.youtube.com/watch?v=WIhKrNWr8ZM', author: 'By Livepeer', content: 'Tune into our weekly Watercooler chat to discuss pressing topics from community members. ——— Connect with Livepeer on Socials: Twitter: https://twitter.com/Livepeer Discord: https://discord.gg/uaPhtyrWsF Telegram: https://t.me/livepeerorg Reddit: https://www.reddit.com/r/livepeer/ Blog: https://medium.com/livepeer-blog Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 10, 2025', duration: 'PT30M41S', thumbnailUrl: 'https://i.ytimg.com/vi/WIhKrNWr8ZM/hqdefault.jpg' }, { title: 'Define & Dane | Live in Lisbon Summit 2025', href: 'https://www.youtube.com/watch?v=s1dhZTofuCM', author: 'By Livepeer', content: 'The embody network ——— Connect with Livepeer on Socials: Website: https://www.livepeer.org/ Twitter: / livepeer Discord: / discord Telegram: https://t.me/livepeerorg Blog: / livepeer Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 10, 2025', duration: 'PT15M54S', thumbnailUrl: 'https://i.ytimg.com/vi/s1dhZTofuCM/hqdefault.jpg' }, { title: 'Peter Schroedl | Live in Lisbon Summit 2025', href: 'https://www.youtube.com/watch?v=q6MP7OgfBzg', author: 'By Livepeer', content: '(BYOC) Bring your own container, and the shift to real-time AI container. ——— Connect with Livepeer on Socials: Website: https://www.livepeer.org/ Twitter: / livepeer Discord: / discord Telegram: https://t.me/livepeerorg Blog: / livepeer Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 10, 2025', duration: 'PT14M48S', thumbnailUrl: 'https://i.ytimg.com/vi/q6MP7OgfBzg/hqdefault.jpg' }, { title: 'Rich O\'grady | Live in Lisbon Summit 2025', href: 'https://www.youtube.com/watch?v=BXMArwnp-No', author: 'By Livepeer', content: 'Introducing the hackathon tracks. ——— Connect with Livepeer on Socials: Website: https://www.livepeer.org/ Twitter: / livepeer Discord: / discord Telegram: https://t.me/livepeerorg Blog: / livepeer Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 9, 2025', duration: 'PT16M18S', thumbnailUrl: 'https://i.ytimg.com/vi/BXMArwnp-No/hqdefault.jpg' }, { title: 'Shannon wells | Live in Lisbon Summit 2025', href: 'https://www.youtube.com/watch?v=_PnB7Kc9zx4', author: 'By Livepeer', content: 'Back to the future of open source. ——— Connect with Livepeer on Socials: Website: https://www.livepeer.org/ Twitter: / livepeer Discord: / discord Telegram: https://t.me/livepeerorg Blog: / livepeer Forum: https://forum.livepeer.org/...', publishedDate: 'Nov 9, 2025', duration: 'PT21M42S', thumbnailUrl: 'https://i.ytimg.com/vi/_PnB7Kc9zx4/hqdefault.jpg' }]; const ghostData = [{ title: "AI X Open Media Forum: Building New Wave Creativity", href: "https://blog.livepeer.org/ai-x-open-media-forum-building-new-wave-creativity/", author: "By Livepeer", datePosted: "Dec 30, 2025", img: "https://blog.livepeer.org/content/images/2025/12/Header.png", excerpt: "The AI x Open Media Forum, hosted by the Livepeer Foundation and Refraction during Devconnect Buenos Aires, brought together artists, technologists, curators, protocol designers, founders and researchers at a moment when media is being reshaped at its foundations. Real-time AI has moved from experimental edges into active use, influencing how" }, { title: "A Real-time Update to the Livepeer Network Vision", href: "https://blog.livepeer.org/a-real-time-update-to-the-livepeer-network-vision/", author: "By Livepeer", datePosted: "Nov 14, 2025", img: "https://blog.livepeer.org/content/images/2025/11/LP_Blog-Header_Nov25_01_moshed-1.png", excerpt: "For the past year, the Livepeer Ecosystem has been guided by the Cascade vision: a path to transition from a pure streaming and transcoding infrastructure, to an infrastructure that could succeed at providing compute for the future of real-time AI video. The latest Livepeer quarterly report from Messari highlights" }, { title: "Livepeer Onchain Builders - Streamplace: Building the Video Backbone of Decentralized Social", href: "https://blog.livepeer.org/livepeer-onchain-builders-streamplace-building-the-video-backbone-of-decentralized-social/", author: "By Livepeer", datePosted: "Aug 15, 2025", img: "https://blog.livepeer.org/content/images/2025/08/Onchain-Builders-Streamplace.jpg", excerpt: "Welcome to Livepeer Onchain Builders, a new content series spotlighting the Special Purpose Entities (SPEs) funded by the Livepeer onchain treasury. SPEs are working groups funded by the community treasury to work on specific tasks and are accountable to the community for their delivery. These deep dives will explore how" }, { title: "Builder Story: dotsimulate x Daydream", href: "https://blog.livepeer.org/builder-story-dotsimulate-x-daydream/", author: "By Livepeer", datePosted: "Aug 6, 2025", img: "https://blog.livepeer.org/content/images/2025/08/DD_Builder-Story_dotsimulate_01.png", excerpt: "Building StreamDiffusionTD Operator - a Real-Time Generative Video Operator for TouchDesigner, Powered by the Daydream APICreator: Lyell Hintz (@dotsimulate)Operator: StreamDiffusionTDBackends Supported: Local + Daydream (Livepeer) 0:00 /0:34 1 OverviewStreamDiffusionTD is a TouchDesigner operator that connects real-time inputs like audio, sensors, and camera feeds to" }]; const forumData = [{ 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

All the funding that was earmarked for Dane’s compensation is being converted into a four-month growth role. Demand generation, workload onboarding, marketing. We’ll hire for it openly and update you with all developments regarding the matter.

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, datePosted: "Apr 7, 2026" }, { title: "Embody SPE: Pre-proposal Intelligent Public Pipelines", href: "https://forum.livepeer.org/t/3220", author: "By DeFine (@DeFine)", content: "

Pre-proposal v5: WEAVE

Authors: DeFine (Strategy & Engineering), Dane (Virtual Worlds & Avatars)Date: March 15, 2026

1. Abstract

The Embody SPE is an entity dedicated to bringing embodied avatar workloads into the Livepeer ecosystem. Since our inception, we have continuously evolved our technology to meet the needs of the network. Our core drive is to deliver sustained fee growth for Livepeer orchestrators.

Along our journey, we have developed solutions and frameworks that address Livepeer’s core bottleneck: the workload lifecycle. Embody seeks funding to develop and prove these solutions, and to expand them into an open-source public-good toolset fit for every existing and upcoming workload deployed on Livepeer.

2. The Problem

To understand the problem, one must recognize three fundamental actors within the Livepeer ecosystem:

Orchestrators, who provide compute for workloads.
Workload Facilitators, who engineer and maintain the workloads that orchestrators run.
Consumers, who utilize these workloads and generate demand.

The Livepeer network provides adequate tokenomic incentives for orchestrators. However, workload facilitator and consumer incentives are currently funded in a non-standardized way by the Livepeer treasury, with limited success so far. In supply and demand terms, compute suppliers vastly outnumber both demand seekers and demand creators.

Workload facilitators generally fall into two subcategories: startups seeking capital to pay for compute and build a consumer base, and established organizations that already possess compute capital and consumers. Livepeer is attractive to both because orchestrators are incentivized through token inflation to offer compute below standard market costs. Theoretically, workload facilitators should be able to offer better prices to their consumers by selecting Livepeer orchestrators.

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

The Technical and Conceptual Barrier Workload facilitators must deeply understand the Livepeer ecosystem technically and conceptually. Furthermore, manually executing every step of a workload’s lifecycle and managing the handoff to the next stage requires an immense amount of time and effort. This creates an exceptionally high barrier to entry, practically excluding non-technical participants from the creation process.

The Economic and Incentive Barrier Economic incentives for workload creation are virtually non-existent by default. Startups rely on the treasury to incentivize their work. Even if a team possesses the technical capability to deliver workloads, they must invest significant time navigating the community and preparing proposals, hoping for treasury approval. For established organizations, there is no incentive to risk service downtime and consumer dissatisfaction by migrating from centralized providers to Livepeer. To date, there are zero documented successful cases of such organizations making the swap.

The Distribution and Interface Barrier Once a workload is live, startups without established consumer bases face the monumental task of building consumer interfaces and executing outreach. Such organizations typically have low headcounts. The added overhead of maintaining Livepeer-specific infrastructure, building interfaces, and distributing workloads is enough to make Livepeer unattractive, especially given the generous inference subsidies offered by centralized providers.

This culmination of friction leads to a critical question: How can we radically reduce the time it takes to convert intent into workload creation and distribution?

3. The Solution

To resolve this bottleneck, we propose WEAVE; an open-source, semi-autonomous agentic orchestration tool with a human-in-the-loop design. WEAVE is designed to turn stakeholder intent into researched, engineered, tested, maintained, and distributed workloads, compressing the lifecycle from months to mere hours.

WEAVE will be accessible to everyone, resolving lifecycle bottlenecks from initial research to consumer distribution. It allows workload facilitators to create new GPU-powered workloads and rapidly deploy them to orchestrators and consumers.

The human operator’s role is simplified: they prompt the initial intent, review the output at the end of each lifecycle stage, and authorize the agent to proceed to the next step. Embody will develop and provide the first WEAVE workloads, managing consumer and orchestrator incentives to power our own and future WEAVE users.

How WEAVE Solves Each Stage

WEAVE directly addresses each stage of the workload lifecycle:

Research Lifecycle agents help identify promising workloads, synthesize demand, evaluate tooling and feasibility signals, and prepare proposals for Livepeer stakeholder review.

Engineering and Maintenance Lifecycle agents turn approved intent into implemented workloads, updates, fixes, and ongoing maintenance work inside bounded environments.

QA Lifecycle agents validate workloads, catch regressions, and prepare them for release through a repeatable testing path.

Consumer Interface The public entry point is a published SKILL.md—a markdown contract that instructs consumers on how to start, control, and end the workload through a mediated public control surface.

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

Consumer Distribution Lifecycle agents support the distribution work needed to reach consumers, drive adoption, and keep the workload legible as a public interface rather than an obscure private implementation.

From Intent to Live Workload

WEAVE provides a clear path from initial intent to live network execution:

Intent Submission: A user submits a workload intent. This can propose a new workload, request an improvement, or point the pipeline toward a concrete opportunity (e.g., real-time camera tracking).
Lifecycle Execution: Agents pick up the intent and move it through research, engineering, QA, release preparation, and distribution.
Stage Review and Authorization: At the end of each stage, agents publish artifacts and request human review. Agents carry the workflow forward, but human authorization is strictly required to complete a stage.
Runtime Release and Distribution: When release-ready, WEAVE distributes the workload to the orchestrator registry. Operators can adopt it through a bounded action. The system simultaneously publishes the consumer-facing SKILL.md and begins distribution outreach.

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

Economic Incentives

WEAVE resolves the time constraints and technical barriers, but this only solves part of the problem. The other half is the absence of economic incentives for workload facilitators and consumers. Similarly, orchestrators typically do not run workloads for free out of goodwill; there must be clear incentives for them to support WEAVE workloads. To address this, we propose three perpetual financial packets:

1. Workload Facilitator Hackathon Packet A perpetual hackathon powered by an LPT economic packet, where a portion of the accrued inflation value is used to incentivize the weekly creation of new workloads. The remaining value is fed back into the principal, allowing it to compound continuously so that token rewards grow over time. The shape of the hackathon and its economic parameters will be subject to ongoing refinement by the multisig participants. Participants will engage through a SKILL.md contract, and funding will be distributed retroactively upon the completion of intended targets. This creates an asymmetric upside: participants are incentivized with an initial allocation, and upon delivering a high-demand workload, they receive retroactive funding along with the ability to deploy applications on top of the workload.

2. Consumer Incentive PacketThis perpetual financial packet operates similarly to the facilitator packet, utilizing weekly accrued inflation to incentivize consumers of WEAVE workloads to take specific actions. For example, SKILL.md consumer agents holding a blockchain wallet could be eligible for rewards if they deliver a working open-source companion application that reaches five concurrent daily users. Like the facilitator packet, this is designed with an asymmetric risk/reward model: the consumer uses the workload without charge and receives a small initial incentive (subject to terms), while the upside includes retroactive rewards and the ability to profit from an application built on WEAVE’s incentive layer.

3. Orchestrator Incentive PacketAn economic packet dedicated to providing weekly rewards for orchestrators who run WEAVE workloads on their hardware systems, ensuring consistent compute availability and sustained network participation.

4. Where We Are Today

WEAVE is being proposed on top of assets the Embody team already operates: a mature Embody workload, an orchestrator rollout lane, and a working consumer entry point.

embody-skill: The published skill-contract path for the workload interface, providing a working consumer-distribution surface.
livepeer-ops: The control-plane layer for sessions, policy, and orchestrator allocation.
Unreal_Vtuber: The runtime environment for the embodied avatar workload.
Registered Orchestrators: 13+ orchestrators have registered to the pipeline and received workloads; seven are currently active, and prior participants can reenter.
Rollout Capability: The active lane can already receive auto-updates through the Unreal_Vtuber path.

Together, these assets provide the execution base for the proposal: a mature workload, an existing operator lane, and functioning distribution tooling on which WEAVE can be built, tested, and released.

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

The roadmap advances in three stages: first, deploy Embody as the inaugural workload on WEAVE; second, extend WEAVE to host daydream/scope; third, generalize WEAVE beyond both to support any realtime application, establishing it as a true open-source public good for the Livepeer ecosystem.

The perpetual financial packets are foundational to this progression. All three launch alongside the Embody workload in Month 1, ensuring that workload facilitator and consumer incentives are active from the start and that orchestrator expenses are covered from day one.

Month 1 — Embody Workload, Lifecycle Automation & Incentives Launch

DeFine

Deliverables

Establish the first bounded lifecycle-agent runtime.
Automate research, engineering, maintenance, and QA flows on the Embody (non game-dependent) proving lane.
Release Embody as the first working WEAVE workload, accessible via SKILL.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.

Each monthly tranche is released independently via 3/5 multisig upon confirmation of that month’s criteria — DeFine: $4,000 per month, Dane: $6,000 per month. Month 4 payments for both tracks are advanced upon Month 3 confirmation, with final deliverables confirming grant completion. A delay or gap in one track does not block the other.

6. Budget & Financial Governance

The total amount requested from the on-chain treasury is $100,000 USD, equal to 43,478 LPT at an LPT reference price of $2.30 on March 15, 2026.

Budget Breakdown

Team Compensation: 17,391 LPT / $40,000 total.
- DeFine: $16,000 total ($4,000/month). Strategy, control plane, WEAVE engineering, and governance/runtime delivery.
- Dane: $24,000 total ($6,000/month). Embodied avatar workload engineering across Unreal Engine and non-Unreal runtime paths.
- Release mechanism: Each monthly tranche is held in the multisig and released only after the month’s work is complete and its success criteria have been met. Release requires 3/5 multisig confirmation. Each track is independently verified and independently released — a delay in one does not block the other.
Operational Costs: 4,348 LPT / $10,000. Infrastructure, runtime, measurement, and support costs for the proving workload during the grant window.
- Release mechanism: Funds are released against submitted receipts as expenses are incurred. No advance disbursement; each release requires documentation of the corresponding expense.
Network Incentives: 13,043 LPT / $30,000. Principal for the Orchestrator Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participating orchestrators according to the published incentive rules.
Workload Facilitator Incentives: 4,348 LPT / $10,000. Principal for the Workload Facilitator Hackathon Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to participants who meet the published hackathon criteria.
Consumer Hackathon: 4,348 LPT / $10,000. Principal for the Consumer Incentive Packet.
- Release mechanism: Once the program launches in Month 1, the multisig releases weekly or bi-weekly distributions to consumers who meet the published incentive terms.

Total: 43,478 LPT / $100,000.

The grant will be managed on Arbitrum through a proposal-facing multisig, incorporating comprehensive receipt spend tracking and structured spending categories.

Multisig Composition

Orchestrator Tiebreaker: One signer - Pon.
Embody Team: Two signers.
Foundation: Two signers, including Rick, the Foundation’s head engineer.

Treasury actions will proceed through a 3/5 signature scheme path. If funds need to be returned, the remaining balance can be converted to LPT and sent back to the Livepeer treasury through the governance process described in the separate wallet governance packet.

7. Addressing Past Feedback

We want to thank the Livepeer stakeholders who gave feedback on earlier versions of this pre-proposal. That feedback improved the proposal materially by surfacing three important issues: the security boundary needed to be clearer, the scope was too abstract, and the budget needed to match the size of the work more credibly.

This revision responds directly to those points. It narrows the first workload claim, explicitly defines the system as an open-source tool rather than a decentralized protocol, makes the public consumer path and governance shape more legible, and ties the four-month ask to reviewable milestone outputs. During the core engineering period, the team will remain responsive to ongoing feedback and incorporate useful improvements.

8. FAQ

1. Who is WEAVE for? WEAVE is designed for both the creation of entirely new workloads and the implementation of changes to existing ones.

2. How much automation exists in WEAVE? A WEAVE user can select their preferred level of automation. They can choose to manually review each stage, leave the review to the agent for auto-authorization, or take a highly hands-on approach in the creation process. The lifecycle agents are capable of automating the entire workload lifecycle, including scanning for novel opportunities.

3. How will WEAVE workloads be deployed to orchestrators? The Embody team will maintain a registry where the lifecycle agents of every WEAVE user can post their workloads. Livepeer orchestrators can then browse this registry and select to deploy these workloads through a single command.

4.How are you sure that workloads will be secure? The security evaluation process naturally sits outside the domain of individual WEAVE users. All workloads will be automatically inspected by centralized lifecycle agents operated by the Embody team. Furthermore, every workload will require a manual review before it is approved for deployment to the registry.

5. Will WEAVE use existing Livepeer components for the workload lifecycle and orchestrator payments? Yes. WEAVE will use Bring Your Own Compute (BYOC) for workload deployment, alongside Livepeer gateways and the clearinghouse for workload delivery and payments. The custom Embody parts that previously fulfilled these functions will be replaced with their mapped Livepeer-specific components.

6. What happens if you aren’t finished in the provided timeframe? All provided funds managed by the multisig will be converted to LPT and sent back to the treasury.

9. References & Technical Appendix

This appendix serves as the deeper review bundle behind the shorter forum post. The post stays high-level; the linked docs carry the architecture, roadmap, budget, and governance detail.

Repositories

embody-skill: https://github.com/its-DeFine/embody-skill
livepeer-ops: https://github.com/its-DeFine/livepeer-ops
Unreal_Vtuber: https://github.com/its-DeFine/Unreal_Vtuber

Packet Docs

note: packet docs are being actively updated for the new version

", replyCount: 21, datePosted: "Feb 17, 2026" }, { title: "Metrics and SLA Foundations for NaaP", href: "https://forum.livepeer.org/t/3189", author: "By speedybird (@speedybird)", content: "

Thank you to everyone who reviewed the earlier pre-proposal and shared detailed feedback in the forum and during the Watercooler. The concerns raised around scope, cost, architectural risk, and MVP clarity were well-founded and directly informed this revision.

This updated pre-proposal reflects a deliberate reset toward a smaller, clearer Network-as-a-Product MVP. The scope has been significantly narrowed, the budget reduced, and the architecture simplified to prioritize time-to-value, reuse of existing Livepeer infrastructure, and immediate usefulness to gateways, orchestrators, and ecosystem teams.

Below is the revised pre-proposal. We welcome the community’s review and feedback on the updated scope, design, and framing. We will be present on this coming Monday’s Water Cooler for discussion.

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

Abstract

This pre-proposal seeks treasury funding for the Livepeer Cloud Special Purpose Entity (SPE) to design, build, and operate a focused Network-as-a-Product (NaaP) MVP for SLA metrics, analytics, and public visibility.

The objective of this work is to make the Livepeer network measurable, comparable, and trustworthy at a network level by delivering a small but complete set of standardized performance, reliability, and demand metrics. These metrics will be publicly observable and designed to support gateway providers, orchestrators, and ecosystem builders evaluating Livepeer as production infrastructure.

This MVP intentionally prioritizes time-to-value, architectural simplicity, and reuse of existing Livepeer infrastructure, while establishing a durable foundation for future SLA-aware routing, scaling, and productization efforts led by Livepeer Inc, the Livepeer Foundation, and the community.

Rationale

As Livepeer advances toward the Network-as-a-Product vision, predictable service characteristics and transparent performance signals become essential. While the network supports real workloads today, participants lack a shared, network-wide view of performance, reliability, and demand that can be used to assess suitability for production use.

Community discussions around earlier drafts of this initiative strongly aligned on the problem, while raising important concerns around scope, cost, architectural risk, and MVP clarity. This pre-proposal reflects that feedback by narrowing focus to a practical MVP that:

Demonstrates clear value with minimal complexity
Leverages existing data sources and pipelines wherever possible
Avoids protocol changes, enforcement mechanisms, or premature decentralization
Produces immediately usable outputs for real network participants

Key challenges addressed by this proposal include:

Fragmented metrics: Existing performance and reliability data is dispersed across systems and difficult for non-core teams to consume.
Limited network-level visibility: Gateway providers and orchestrators cannot easily compare performance across regions, workloads, or peers.
Adoption friction: Without transparent, shared metrics, external developers and partners struggle to evaluate Livepeer for serious workloads.
Missing foundation for NaaP evolution: Future SLA-aware routing, scaling, and automation require a trusted measurement layer first.

The Cloud SPE is well positioned to deliver this work as neutral, public infrastructure, building on its prior experience operating gateways, test tooling, dashboards, and analytics for the Livepeer network.

Importantly, this proposal does not attempt to enforce SLAs, modify protocol incentives, or introduce new routing logic. Its purpose is to establish shared measurement and learning infrastructure as a prerequisite for those future decisions.

Deliverables

The NaaP MVP will deliver a constrained, end-to-end metrics system focused on observability and learning inspired by the NaaP product MVP and Foundation roadmap.

1. Core SLA Metrics (MVP Scope)

A standardized set of network, performance, and reliability metrics sufficient to evaluate orchestrator and GPU behavior across workflows.
Metrics sourced primarily from job tester gateway and orchestrator-emitted telemetry, with targeted additions only when other Gateways opt-in.

2. Network Test & Verification Signals

Operation of one or more reference load-test gateways to generate consistent, reproducible performance signals for live AI video pipelines.
Public test scenarios (aka test datasets) designed to reflect real workloads while remaining transparent and community-verifiable. These will be captured in Github.
Test results contributed into the same analytics layer as organic network traffic to enable comparison (when other Gateways participate).

3. Analytics & Aggregation Layer

Lightweight ETL and aggregation pipelines to transform raw metrics into network-level views.
Computation of a small number of derived indicators as outlined in the Metrics Catalog
Data structured for efficient querying without requiring dashboards to load raw job data.

4. Public Dashboard & APIs

A standalone public dashboard presenting live and historical metrics.
Public, read-only APIs for aggregate SLA scores and hardware.
Clear paths for gateways and ecosystem teams to consume the data directly or mirror it into their own analytics systems.

5. Operations & Stewardship

Ongoing operation of testing, analytics, and dashboard infrastructure.
Maintenance, monitoring, and community support for the MVP for 1 year.

Any scope not outlined here is not part of the Deliverables and out of the scope of this proposal.

Key Milestones

Milestone 1 – Metrics Collection & Aggregation

Define and implement the minimal metrics set
Aggregate existing telemetry into a unified analytics layer
A basic dashboard showing sample data flowing end to end

Milestone 2 – Test Signals & Derived Analytics

Deploy reference load-test gateways
Launch a public dashboard with core views
APIs for ecosystem consumption

Milestone 3 – Stabilization & Review

Harden infrastructure for reliability and cost efficiency
Document metrics, assumptions, and known gaps
Review outcomes with the community to determine next steps

Timeline

Delivery is anticipated to take approximately six months (and already underway as of November 2025). This is dependent on the team’s development velocity and subject to change. Preliminary design and validation work has begun to reduce delivery risk.

November 2025 - Works began on original proposal and discovery process
February 2026 – Milestone 1: Metrics Collection & Aggregation
March 2026 – Milestone 2 – Test Signals & Derived Analytics
April 2026 – Milestone 3 – Stabilization & Review

Budget

Total Requested Budget: $90,000

This budget supports:

Engineering work to aggregate, validate, and expose SLA-relevant metrics
Development of Load Testing Gateway (AI Job Tester + Gateway enhancements) and Network Data Scraper
Development of minimal analytics and public-facing dashboards
Development of DevOps infrastructure and automation
Operation of testing, analytics, and storage infrastructure for approximately one year
Ongoing maintenance, documentation, and community support

The budget is intentionally sized for a thin but complete MVP, designed to validate assumptions, inform future investment, and avoid long-term commitments before value is demonstrated.

Closing Note

This pre-proposal reflects extensive community and Livepeer Inc feedback and represents a deliberate step toward a simpler, clearer, and more actionable NaaP MVP.

By focusing on shared measurement rather than enforcement or protocol change, this work aims to give the Livepeer ecosystem a common understanding of network behavior today — and a solid foundation for deciding what to build next.

", replyCount: 11, datePosted: "Jan 10, 2026" }, { title: "RFP — Explorer Maintenance", href: "https://forum.livepeer.org/t/3072", author: "By Rick (@rickstaa)", content: "

Date Issued: 2025-09-17
Issued By: Livepeer Foundation
Contact: Rick Staa

1. Objective

Restore the Livepeer Explorer to a secure, maintainable, and high-performance state while laying the groundwork for new network-wide data and governance dashboards.

2. Problem Statement

The Explorer is the primary entry point for orchestrators, delegators, developers, and gateways. However, since December 2023 lack of ownership has accumulated significant technical debt:

Outdated dependencies in the Explorer and design system, fragile under Node 20, break on updates and could lead to security risks, undermining long-term maintainability.
Duplicated/obsolete code and missing contribution infrastructure (guidelines, CI/tests, stubs), making contributions slow and error-prone.
Inefficient data fetching (e.g. Infura/Graph duplication), creating performance issues.
A backlog of unmerged PRs and unresolved bugs (e.g., broken migration widget, UI inconsistencies, incorrectly displayed data).

A future roadmap for expanded network data and richer Explorer stakeholder experiences depends on first restoring a stable, secure, and maintainable Explorer. This RFP focuses on that critical first step.

3. Desired Outcome

Success means that within four months the Explorer is:

Clean, well tested, with automated tests and continuous integration pipelines, providing a healthy, maintainable codebase.
Free of critical bugs and stale pull requests, with a clearly organized issue backlog.
Running on up-to-date, secure dependencies (Explorer and design system) fully compatible with the current Node.js LTS.
Improved in performance, with faster page loads and a simplified, well-documented data layer for developers
Equipped with a new voting-transparency feature integrated with the voting-tally subgraph.
Backed by a clear 6-month roadmap and a dedicated maintainer team providing ongoing maintenance and timely support.

In short, the Explorer will be trusted infrastructure and ready to power further iteration of capabilities.

4. Deliverables

Within four months (target completion by February 1, 2026), the selected team will deliver the following milestone-based outcomes.

Each deliverable must be demonstrated in a Livepeer community call, and the team must provide public progress updates at least every two weeks (e.g., forum posts) throughout the project.

Payments are released only after each demo is accepted by the RFP owner.

(i) Establish Healthy Explorer Codebase

Goal: Deliver a clean, maintainable, and well-tested Explorer foundation to enable ongoing community contributions.

Requirements:

Remove unused and duplicate code.
Reorganize folder and module structure, where needed, to improve navigation and long-term maintainability.
Add comprehensive unit and integration tests covering all critical user flows (e.g., staking, delegating, governance), with measurable coverage targets proposed by the vendor.
Implement CI pipelines for reliable builds and automated checks.
Ensure all components are fully typed (TypeScript) and all ESLint/TypeScript errors resolved.
Provide clear contributor documentation and review workflow, with local-development stubs/mocks so the codebase can run without production environment variables.

Outcome: A clean, healthy, well-tested codebase with CI pipelines and local stubs that contributors can run with minimal setup, forming a solid foundation for future improvements.

Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the cleaned codebase, CI, tests, and contributor docs.

(II) Improve Data-Fetching Efficiency

Goal: Enhance the Explorer’s data layer to reduce latency, eliminate redundant calls, and ensure responsive, reliable performance for end users and contributors.

Requirements:

Optimize subgraph and RPC data fetching to reduce latency, avoid duplication, and improve responsiveness.

Outcome: A faster, more efficient Explorer with reduced redundant calls and a simplified, well-documented data layer for easier future contributions.

Demo Day: To be proposed by the team and agreed with the RFP owner, showcasing faster data fetching and improved data-layer developer documentation.

(III) Resolve Critical UI Issues & Backlog

Goal: Eliminate high-impact bugs and stale pull requests to ensure a stable, accurate, user-friendly Explorer.

Requirements:

Resolve all current critical UI bugs (GitHub bug list), including the delegator migration widget, data inaccuracies, and major UX defects, and triage/fix any new critical issues during the engagement.
Review and merge, close, or supersede all open pull requests (GitHub pull requests) other than the voting-transparency feature (covered in Deliverable 5).
Work with the Foundation and Advisory Boards to prioritize any other high-impact feature requests from the backlog that fit within the agreed budget and timeline.

Outcome: A more stable, accurate, and user-friendly Explorer with all critical issues resolved and a significantly reduced bug backlog, ready for ongoing community contributions.

Demo Day: To be proposed by the team and agreed with the RFP owner, presenting a detailed report of resolved bugs and key fixes, along with the cleaned and updated issue board.

(IV) Deliver Voting-Transparency Feature & Subgraph Integration

Goal: Provide clear, real-time visibility into on-chain governance participation.

Requirements:

Finalize and deploy the voting-transparency feature, incorporating requested UI refinements and migrating data fetching to the voting-tally subgraph for improved performance, using feedback from the Foundation and Advisory Boards.

Outcome: A fully deployed voting-transparency feature integrated with the voting-tally subgraph and refined UI, offering accurate, real-time governance data.

Demo Day: To be proposed by the team and agreed with the RFP owner, demonstrating the live voting-transparency feature.

(V) Establish Maintainability & Roadmap

Goal: Ensure the Explorer remains easy to maintain with a clear 6-month plan.

Requirements:

Publish a 6-month feature/bug roadmap aligned with the Foundation’s Data Gap Analysis and community feedback.
Provide contributor docs, maintenance practices, and an issue-tracking process (including a clean, well-labeled issue board).

Outcome: A documented maintenance framework and forward roadmap enabling smooth ongoing development and community contributions.

Demo Day: To be proposed by the team and agreed with the RFP owner, presenting the final roadmap and contributor maintenance guide.

(VI) Provide Ongoing Support & Post-Delivery Responsibility

Goal: Ensure professional post-launch support and continuity of maintenance, whether the same team continues or future maintainers take over.

Requirements:

During the project, acknowledge critical bugs within 24–48 hours and resolve or mitigate them within a few business days (or faster per the proposer’s SLA).
After delivery, provide at least a 60-day support window for critical fixes, security incidents, and knowledge transfer, meeting the proposer’s SLA.

Outcome: Stable post-launch operations with timely critical-issue resolution and clear processes for continued maintenance, regardless of who maintains the Explorer.

Payment: The team must present a support-readiness plan with defined SLA commitments, to be agreed with the RFP owner. Ninety percent of each milestone payment is released after acceptance of that milestone’s demo. The remaining ten percent of the total contract is held until the 60-day support period concludes and SLA commitments and resolution targets are met.

Out of Scope

To avoid confusion, the following items are not part of this RFP:

A full UI/UX redesign or new visual styling of the Explorer.
Major new product features beyond the initial voting-transparency integration.
Broader data-gap mapping (handled by separate workstreams).
Protocol/client changes or on-chain improvements to surface new data (managed through separate RFPs within the same workstream).

5 Capabilities required

Skills

Strong front-end engineering in modern JavaScript/TypeScript (React/Next.js), including implementing and refining accessible UI components within an existing component library or design system.
Proven experience with codebase modernization and maintainability—refactoring, setting up CI/CD pipelines, adding automated unit and integration tests, and enforcing TypeScript and ESLint standards.
Ability to update and manage complex dependency stacks, including Node.js and modern package managers, while resolving breaking changes and configuring automated update tooling (e.g., Dependabot or Renovate).
Proficiency in performance optimization and efficient data-fetching techniques, particularly with GraphQL/subgraph and RPC endpoints.
Experience reviewing, triaging, and merging open-source pull requests and managing a clean, well-labeled issue backlog.
Familiarity with monitoring and incident-response tools (e.g., Sentry, Bugsnag) to ensure production reliability.

Knowledge

Understanding of the Ethereum/Web3 stack, including wallet flows, transactions, RPC providers, and common front-end pitfalls.
Awareness of accessibility (a11y) best practices and secure front-end patterns such as dependency risk management and safe secret handling.
Experience with open-source project governance, including contributor guidelines, code review workflows, semantic versioning, and changelogs.
Familiarity with The Graph/subgraph architecture and GraphQL schemas (nice to have).
Familiarity with the Livepeer protocol and current Explorer repository (nice to have).

Attitude

Community-oriented and collaborative, engaging proactively with contributors, Advisory Boards, and Foundation stakeholders.
Accountable and responsive, acknowledging critical bugs within 24–48 hours and working toward mitigation or resolution within a few business days.
Documentation-first mindset, maintaining clear READMEs, runbooks, and migration notes to enable future contributors.
Quality-driven and pragmatic, balancing rigorous testing, CI, and security with on-time delivery.
Long-term stewardship, treating the Explorer as trusted infrastructure and designing for multi-year maintainability.
Supportive and open, encouraging new contributors and fostering an inclusive contributor community.
Mission-aligned, motivated to strengthen the Explorer as a cornerstone of the Livepeer ecosystem.

6. Proposal Requirements

Please include in your proposal:

Executive Summary - give an overview of the proposal and why you are suited.
Company / Contributor Overview & Capabilities - breakdown of each contributor with bio and relevant case studies.
Past Work & Experience – examples of large front-end refactors, dependency upgrades, CI/CD setup, performance optimization, or open-source project maintenance.
Milestone Breakdown – a plan aligned with Section 2 deliverables, with proposer-set milestone dates and demo day schedules, each including clear outputs and payment tied to demo acceptance.
Support & Maintenance Plan – proposed SLA commitments (e.g., response and resolution times), 60-day post-delivery support approach, and handover/knowledge-transfer strategy.
Pricing Breakdown - breakdown of payment by milestone with an optional ongoing support.

Though we recommend you use your own creativity in the proposal, an example template is here: Livepeer RFP — Proposal Template.

7. RFP Timeline

Proposal Deadline: Wednesday 24th September 2025
Decision Announced: Friday 26th September 2025
Project Start: Wednesday 1 October 2025
Project Completion: Sunday 1 Feb 2026

8. Proposal Submission Instructions

Format: PDF or Notion page (share with view access).
Proposal Deadline: 11:59pm GMT-7, Wednesday 24th September 2025.
Questions: reach out to @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, datePosted: "Sep 18, 2025" }]; const ScrollBox = ({children, maxHeight = 300, showHint = true, ariaLabel = "Scrollable content", style = {}, className = "", ...rest}) => { const _components = { div: "div", ..._provideComponents() }; const contentRef = useRef(null); const [isOverflowing, setIsOverflowing] = useState(false); useEffect(() => { const checkOverflow = () => { if (contentRef.current) { const maxHeightPx = typeof maxHeight === "number" ? maxHeight : parseInt(maxHeight, 10) || 300; setIsOverflowing(contentRef.current.scrollHeight > maxHeightPx); } }; checkOverflow(); window.addEventListener("resize", checkOverflow); return () => window.removeEventListener("resize", checkOverflow); }, [maxHeight, children]); return _jsxs(_components.div, { className: className, style: { position: "relative", ...style }, ...rest, children: [_jsx(_components.div, { ref: contentRef, role: "region", tabIndex: 0, "aria-label": ariaLabel, style: { maxHeight: typeof maxHeight === "number" ? `${maxHeight}px` : maxHeight, overflowY: "auto", paddingRight: 4 }, onScroll: e => { const el = e.target; const atBottom = el.scrollHeight - el.scrollTop <= el.clientHeight + 10; const hint = el.parentNode.querySelector("[data-scroll-hint]"); if (hint) hint.style.opacity = atBottom ? "0" : "1"; }, children: children }), showHint && isOverflowing && _jsx(_components.div, { "data-scroll-hint": true, style: { fontSize: 11, color: "var(--lp-color-text-muted)", textAlign: "center", marginTop: 8, transition: "opacity 0.2s" }, children: "Scroll for more ↓" })] }); }; const LinkArrow = ({href, label, description, newline = true, borderColor, className = '', style = {}, ...rest}) => { const _components = { a: "a", br: "br", div: "div", span: "span", ..._provideComponents() }, {Icon} = _components; if (!Icon) _missingMdxReference("Icon", true); const linkArrowStyle = { display: 'inline-flex', alignItems: 'center', justifyContent: 'center', gap: "var(--lp-spacing-1)", width: 'fit-content', ...borderColor && ({ borderColor }) }; return _jsxs(_components.span, { className: className, style: style, ...rest, children: [newline && _jsx(_components.br, {}), _jsxs(_components.span, { style: linkArrowStyle, children: [_jsx(_components.a, { href: href, target: "_blank", rel: "noopener noreferrer", children: label }), _jsx(Icon, { icon: "arrow-up-right", size: 14, color: "var(--lp-color-accent)" })] }), description && description, description && _jsx(_components.div, { style: { height: "var(--lp-spacing-3)" } })] }); }; const YouTubeVideoData = ({items = [], limit, cols = 2, className = "", style = {}, ...rest}) => { const _components = { div: "div", p: "p", ..._provideComponents() }, {Columns, Note} = _components; if (!Columns) _missingMdxReference("Columns", true); if (!Note) _missingMdxReference("Note", true); const displayItems = limit ? items.slice(0, limit) : items; if (!displayItems || displayItems.length === 0) { return _jsx(Note, { children: _jsx(_components.p, { style: { color: "var(--text-secondary)", textAlign: "center" }, children: "No videos at this time." }) }); } const getEmbedUrl = href => { if (!href) return ""; const videoId = href.split("v=")[1]?.split("&")[0]; return videoId ? `https://www.youtube.com/embed/${videoId}` : href; }; return _jsx(Columns, { cols: cols, className: className, style: style, ...rest, children: displayItems.map((item, idx) => { if (!item || !item.href) return null; const needsSpacer = idx > 0 && idx % cols === 0; return _jsxs(_Fragment, { children: [needsSpacer && _jsx(_components.div, { style: { height: "var(--lp-spacing-6)", width: "100%" } }, `spacer-${idx}`), needsSpacer && _jsx(_components.div, { style: { height: "var(--lp-spacing-6)", width: "100%" } }, `spacer2-${idx}`), _jsx(YouTubeVideo, { embedUrl: getEmbedUrl(item.href), title: item.title || "", caption: `${item.author || ""} • ${item.publishedDate || ""}` }, item.href || idx)] }); }) }); }; const YouTubeVideo = ({embedUrl, title = "", author = "", hint = "", caption, className = "", style = {}, ...rest}) => { const _components = { iframe: "iframe", span: "span", strong: "strong", ..._provideComponents() }, {Frame, Icon} = _components; if (!Frame) _missingMdxReference("Frame", true); if (!Icon) _missingMdxReference("Icon", true); if (!embedUrl || typeof embedUrl !== "string" || embedUrl.trim() === "") { return null; } const isValidYouTubeUrl = embedUrl.includes("youtube.com/embed/") || embedUrl.includes("youtu.be/"); if (!isValidYouTubeUrl) { console.warn("Invalid YouTube embed URL:", embedUrl); return null; } const buildCaption = () => { if (caption) return caption; if (!author && !title) return null; return _jsx(_components.span, { style: { display: "flex", flexDirection: "column", alignItems: "center", textAlign: "center", lineHeight: 1.2 }, children: _jsxs(_components.span, { children: [author && _jsxs(_Fragment, { children: [_jsx(Icon, { icon: "microphone", size: 16 }), " ", _jsx(_components.strong, { children: author })] }), author && title ? `${" "} • ${title}` : title] }) }); }; const captionContent = buildCaption(); return _jsx(Frame, { className: className, style: style, ...hint ? { hint } : {}, ...captionContent ? { caption: captionContent } : {}, ...rest, children: _jsx(_components.iframe, { className: "mint-w-full mint-aspect-video mint-rounded-xl", src: embedUrl, title: title || author || "YouTube Video", allow: "accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture", allowFullScreen: true }) }); }; const TwitterTimeline = ({className = '', style = {}, ...rest}) => { const _components = { div: "div", iframe: "iframe", ..._provideComponents() }; return _jsx(_components.div, { className: className, style: { border: '3px solid var(--lp-color-accent)', borderRadius: "12px", overflow: 'hidden', height: '600px', ...style }, ...rest, children: _jsx(_components.iframe, { src: "https://feed.mikle.com/widget/v2/176804/", title: "Livepeer Twitter Timeline", style: { border: 'none', transform: 'scale(1.01)', transformOrigin: 'center' }, height: "652px", width: "100%", className: "fw-iframe", frameBorder: "0", scrolling: "no" }) }); }; const DiscordAnnouncements = ({serverName = 'Livepeer', items = [], limit, ScrollBox, scrollMaxHeight = 300, className = '', style = {}, ...rest}) => { const _components = { div: "div", hr: "hr", p: "p", span: "span", time: "time", ..._provideComponents() }, {Icon, Note} = _components; if (!Icon) _missingMdxReference("Icon", true); if (!Note) _missingMdxReference("Note", true); const sanitiseHTML = html => { if (!html || typeof html !== 'string') return ''; return html.replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(/\bon\w+\s*=\s*(['"])[^'"]*\1/gi, '').replace(/\bon\w+\s*=\s*[^\s>]*/gi, '').replace(/javascript\s*:/gi, ''); }; const displayItems = limit ? items.slice(0, limit) : items; if (!displayItems || displayItems.length === 0) { return _jsx(Note, { children: _jsx(_components.p, { style: { color: 'var(--text-secondary)', textAlign: 'center' }, children: "No announcements at this time." }) }); } const parseContent = content => { const withLinks = content.replace(/\[([^\]]+)\]$([^)]+)$/g, '$1 ↗'); return withLinks; }; return _jsx(_components.div, { className: className, style: { display: 'flex', flexDirection: 'column', gap: "var(--lp-spacing-4)", border: '1px solid var(--lp-color-accent)', borderRadius: "var(--lp-spacing-2)", padding: "var(--lp-spacing-4)", ...style }, ...rest, children: displayItems.map((announcement, index) => _jsxs(_components.div, { href: announcement.url, target: "_blank", rel: "noopener noreferrer", children: [_jsxs(_components.div, { style: { display: 'flex', alignItems: 'center', gap: "var(--lp-spacing-2)", fontSize: '0.875rem', marginBottom: "var(--lp-spacing-3)", width: '100%' }, children: [_jsx(Icon, { icon: "discord", color: "var(--lp-color-brand-discord)", size: 16 }), _jsx(_components.span, { style: { fontWeight: 600, color: 'var(--lp-color-accent)', fontSize: 'medium' }, children: serverName }), _jsx(_components.span, { style: { color: 'var(--lp-color-text-secondary)' }, children: "•" }), _jsx(_components.time, { dateTime: announcement.timestamp, style: { color: 'var(--lp-color-text-secondary)' }, children: new Date(announcement.timestamp).toLocaleDateString('en-US', { month: 'short', day: 'numeric', year: 'numeric' }) }), _jsxs(_components.span, { style: { fontSize: '0.875rem', color: 'var(--lp-color-text-secondary)', marginLeft: 'auto' }, children: ["View in Discord", ' ', _jsx(Icon, { icon: "arrow-up-right", size: 12, color: "var(--lp-color-accent)" })] })] }), _jsx(ScrollBox, { maxHeight: scrollMaxHeight, ariaLabel: `Announcement from ${serverName}`, children: _jsx(_components.div, { style: { color: 'var(--lp-color-text-secondary)', fontSize: 'small' }, dangerouslySetInnerHTML: { __html: sanitiseHTML(parseContent(announcement.content)) } }) }), index < displayItems.length - 1 && _jsx(_components.div, { style: { marginTop: "var(--lp-spacing-3)" }, children: _jsx(_components.hr, { style: { border: 'none', borderBottom: '1px solid var(--lp-color-border-default)', margin: '0' } }) })] }, announcement.id)) }); }; const ForumLatestLayout = ({items = [], limit, className = '', style = {}, ...rest}) => { const _components = { a: "a", div: "div", img: "img", ..._provideComponents() }; return _jsxs(_components.div, { className: className, style: style, ...rest, children: [_jsx(_components.a, { href: "https://forum.livepeer.org", target: "_blank", rel: "noopener noreferrer", children: _jsx(_components.img, { src: "/snippets/assets/media/heros/Hero_Livepeer_Forum.png", alt: "Livepeer Forum", noZoom: true, style: { border: '1px solid var(--lp-color-border-default)', borderRadius: "var(--lp-spacing-2)", marginBottom: '0', paddingBottom: '0' } }) }), _jsx(CardColumnsPostLayout, { cols: 2, items: items, limit: limit })] }); }; const ColumnsBlogCardLayout = ({items = [], cols = 2, limit, className = '', style = {}, ...rest}) => { const _components = { p: "p", ..._provideComponents() }, {Columns, Note} = _components; if (!Columns) _missingMdxReference("Columns", true); if (!Note) _missingMdxReference("Note", true); const displayItems = limit ? items.slice(0, limit) : items; if (!displayItems || displayItems.length === 0) { return _jsx(Note, { children: _jsx(_components.p, { style: { color: 'var(--text-secondary)', textAlign: 'center' }, children: "No blog posts at this time." }) }); } return _jsx(Columns, { cols: cols, className: className, style: style, ...rest, children: displayItems.map((props, idx) => _jsx(BlogCard, { ...props }, props.href || idx)) }); }; const CardColumnsPostLayout = ({cols = 2, items = [], limit, className = '', style = {}, ...rest}) => { const {Columns} = _provideComponents() || ({}); if (!Columns) _missingMdxReference("Columns", true); const displayItems = limit ? items.slice(0, limit) : items; return _jsx(_Fragment, { children: _jsx(Columns, { cols: cols, className: className, style: style, ...rest, children: displayItems.map((props, idx) => _jsx(PostCard, { ...props }, props.href || idx)) }) }); }; const CardBlogDataLayout = ({items = [], limit, className = '', style = {}, ...rest}) => { const _components = { div: "div", p: "p", ..._provideComponents() }, {Note} = _components; if (!Note) _missingMdxReference("Note", true); const displayItems = limit ? items.slice(0, limit) : items; if (!displayItems || displayItems.length === 0) { return _jsx(Note, { children: _jsx(_components.p, { style: { color: 'var(--text-secondary)', textAlign: 'center' }, children: "No blog posts at this time." }) }); } return _jsx(_components.div, { className: className, style: style, ...rest, children: displayItems.map((props, idx) => _jsx(BlogCard, { ...props }, props.href || idx)) }); }; const BlogCard = ({title, content, href, author = 'Livepeer Team', datePosted = null, excerpt = null, readingTime = null, icon = 'book-open', authorIcon = 'user-pen', dateIcon = 'calendar', cta = 'Read More', img = null, className = '', style = {}, ...rest}) => { const _components = { div: "div", span: "span", ..._provideComponents() }, {Card, Icon} = _components; if (!Card) _missingMdxReference("Card", true); if (!Icon) _missingMdxReference("Icon", true); const sanitiseHTML = html => { if (!html || typeof html !== 'string') return ''; return html.replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(/\bon\w+\s*=\s*(['"])[^'"]*\1/gi, '').replace(/\bon\w+\s*=\s*[^\s>]*/gi, '').replace(/javascript\s*:/gi, ''); }; const showScrollHint = content && content.length > 500; const titleStyle = { alignItems: 'center', color: 'var(--lp-color-accent)', fontSize: '1.25rem', marginLeft: '-2px', marginBottom: "var(--lp-spacing-2)", display: '-webkit-box', WebkitLineClamp: 2, WebkitBoxOrient: 'vertical', overflow: 'hidden', textOverflow: 'ellipsis' }; const authorStyle = { display: 'flex', fontSize: 13, color: 'var(--lp-color-text-primary)', gap: 6 }; const dateStyle = { display: 'flex', alignItems: 'center', fontSize: 12, color: 'var(--lp-color-text-primary)', gap: 6 }; const readTimeStyle = { display: 'flex', marginTop: 0, alignItems: 'center', fontSize: 12, color: 'var(--lp-color-text-primary)', gap: 6 }; const contentBgStyle = { height: 1, backgroundColor: 'var(--lp-color-border-default)', margin: '12px 0' }; const contentContainerStyle = { maxHeight: 300, overflowY: 'auto' }; const contentRegionLabel = title ? `Scrollable content for ${title}` : 'Scrollable content'; const scrollHintStyle = { fontSize: 11, color: 'var(--lp-color-text-muted)', textAlign: 'center', marginTop: 10, marginBottom: 0 }; const iconStyle = { position: 'relative', top: '-2px' }; return _jsxs(Card, { className: className, style: style, title: _jsxs(_components.span, { style: titleStyle, children: [_jsx(_components.span, { style: { alignSelf: 'top' }, children: _jsx(Icon, { icon: icon, size: 20, color: "var(--lp-color-accent)" }) }), _jsx(_components.span, { style: { marginLeft: "var(--lp-spacing-2)" }, children: title })] }), href: href, cta: cta, img: img, arrow: true, ...rest, children: [_jsxs(_components.div, { style: { flex: 1 }, children: [datePosted && _jsxs(_components.div, { style: dateStyle, children: [_jsx(_components.span, { children: _jsx(Icon, { icon: dateIcon, size: 14 }) }), _jsx(_components.span, { children: datePosted })] }), readingTime && _jsxs(_components.div, { style: readTimeStyle, children: [_jsx(_components.span, { children: _jsx(Icon, { icon: "clock", size: 14 }) }), _jsxs(_components.span, { children: ["Read Time: ", readingTime, " minutes"] })] })] }), _jsx(_components.div, { style: contentBgStyle }), _jsx(_components.div, { style: contentContainerStyle, role: "region", tabIndex: 0, "aria-label": contentRegionLabel, onScroll: e => { const el = e.target; const atBottom = el.scrollHeight - el.scrollTop <= el.clientHeight + 10; const hint = el.nextSibling; if (hint) hint.style.display = atBottom ? 'none' : 'block'; }, dangerouslySetInnerHTML: { __html: sanitiseHTML(content) } }), showScrollHint && _jsx(_components.div, { style: scrollHintStyle, children: "Scroll for more ↓" })] }); }; const PostCard = ({title, content, href, author = 'Unknown', datePosted = null, replyCount = null, icon = 'book-open', authorIcon = 'user-pen', dateIcon = 'calendar', cta = 'Read More', img = null, className = '', style = {}, ...rest}) => { const _components = { div: "div", span: "span", ..._provideComponents() }, {Card, Icon} = _components; if (!Card) _missingMdxReference("Card", true); if (!Icon) _missingMdxReference("Icon", true); const sanitiseHTML = html => { if (!html || typeof html !== 'string') return ''; return html.replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(//gi, '').replace(/\bon\w+\s*=\s*(['"])[^'"]*\1/gi, '').replace(/\bon\w+\s*=\s*[^\s>]*/gi, '').replace(/javascript\s*:/gi, ''); }; const showScrollHint = content && content.length > 500; return _jsxs(Card, { className: className, style: style, title: title, icon: icon, href: href, cta: cta, img: img, arrow: true, ...rest, children: [author && _jsxs(_components.div, { style: { display: 'flex', marginTop: "var(--lp-spacing-px-12)", fontSize: 13, color: 'var(--lp-color-text-secondary)', gap: 8 }, children: [_jsx(_components.span, { children: _jsx(Icon, { icon: authorIcon, size: 20 }) }), _jsx(_components.span, { children: author })] }), datePosted && _jsxs(_components.div, { style: { display: 'flex', marginTop: '10px', fontSize: 12, color: 'var(--lp-color-text-secondary)', gap: 8 }, children: [_jsx(_components.span, { children: _jsx(Icon, { icon: dateIcon, size: 20 }) }), _jsx(_components.span, { children: datePosted })] }), _jsx(_components.div, { style: { height: 1, backgroundColor: 'var(--lp-color-bg-subtle)', margin: '12px 0' } }), _jsx(_components.div, { style: { maxHeight: 300, overflowY: 'auto' }, role: "region", tabIndex: 0, "aria-label": title ? `Scrollable content for ${title}` : 'Scrollable content', onScroll: e => { const el = e.target; const atBottom = el.scrollHeight - el.scrollTop <= el.clientHeight + 10; const hint = el.nextSibling; if (hint) hint.style.display = atBottom ? 'none' : 'block'; }, dangerouslySetInnerHTML: { __html: sanitiseHTML(content) } }), showScrollHint && _jsx(_components.div, { style: { fontSize: 11, color: 'var(--lp-color-text-muted)', textAlign: 'center', marginTop: 10, marginBottom: 10 }, children: "Scroll for more ↓" })] }); }; function _createMdxContent(props) { const _components = { p: "p", ..._provideComponents(), ...props.components }, {Heading, Icon, Tip} = _components; if (!Heading) _missingMdxReference("Heading", true); if (!Icon) _missingMdxReference("Icon", true); if (!Tip) _missingMdxReference("Tip", true); return _jsxs(_Fragment, { children: [_jsx(Tip, { children: _jsx(_components.p, { children: "Uses automations to pull in the latest youtube videos, forum posts and blogs" }) }), "\n", _jsxs(Heading, { level: "2", id: "videos", children: [_jsx(Icon, { icon: "camera-movie", size: 24 }), " Videos"] }), "\n", _jsxs(_components.p, { children: ["Watch the latest videos on the ", _jsx(LinkArrow, { label: "Livepeer Youtube Channel", href: "https://www.youtube.com/@livepeer", newline: false })] }), "\n", _jsx(YouTubeVideoData, { items: youtubeData, limit: 2 }), "\n", _jsxs(Heading, { level: "2", id: "forum", children: [_jsx(Icon, { icon: "messages", size: 24 }), " Forum"] }), "\n", _jsxs(_components.p, { children: ["Contribute to trending ", _jsx(LinkArrow, { label: "Forum Discussions", href: "https://forum.livepeer.org/", newline: false })] }), "\n", _jsx(ForumLatestLayout, { items: forumData, limit: 2 }), "\n", _jsxs(Heading, { level: "2", id: "discord", children: [_jsx(Icon, { icon: "discord", size: 24 }), " Discord"] }), "\n", _jsxs(_components.p, { children: ["Add your voice to the latest ", _jsx(LinkArrow, { label: "Discord Discussions", href: "https://discord.livepeer.org/", newline: false })] }), "\n", _jsx(DiscordAnnouncements, { serverName: "Livepeer", items: discordAnnouncementsData, limit: 2, ScrollBox: ScrollBox, scrollMaxHeight: 200 }), "\n", _jsxs(Heading, { level: "2", id: "x-posts", children: [_jsx(Icon, { icon: "twitter", size: 24 }), " X Posts"] }), "\n", _jsxs(_components.p, { children: ["Follow, Like, Comment & Share on the latest ", _jsx(LinkArrow, { label: "Livepeer X posts", href: "https://x.com/Livepeer", newline: false })] }), "\n", _jsx(TwitterTimeline, {}), "\n", _jsxs(Heading, { level: "2", id: "blogs", children: [_jsx(Icon, { icon: "pencil-line", size: 24 }), " Blogs"] }), "\n", _jsxs(_components.p, { children: ["Read recent news from the ", _jsx(LinkArrow, { label: "Livepeer Blog", href: "https://blog.livepeer.org/", newline: false })] }), "\n", _jsx(ColumnsBlogCardLayout, { items: ghostData, limit: 2 })] }); } function MDXContent(props = {}) { const {wrapper: MDXLayout} = { ..._provideComponents(), ...props.components }; return MDXLayout ? _jsx(MDXLayout, { ...props, children: _jsx(_createMdxContent, { ...props }) }) : _createMdxContent(props); } return { discordAnnouncementsData, youtubeData, ghostData, forumData, ScrollBox, LinkArrow, YouTubeVideoData, YouTubeVideo, TwitterTimeline, DiscordAnnouncements, ForumLatestLayout, ColumnsBlogCardLayout, CardColumnsPostLayout, CardBlogDataLayout, BlogCard, PostCard, default: MDXContent }; function _missingMdxReference(id, component) { throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it."); }

Home

Livepeer

Showcase

Resources

Documentation Index

​ Videos

​ Forum

​ Discord

​ X Posts

​ Blogs

Videos

Forum

Discord

X Posts

Blogs