The Livepeer roadmap shows the priority work the network is focused on to scale real-time video AI demand. It highlights what is being executed now, what is coming next, and the longer-term direction shaping those priorities. Each item defines a problem and desired outcome, indicating where contributors can take ownership and drive execution.

Beyond

Roadmap

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: ClosedWinning Submission URL: <a target="" rel="noopener noreferrer nofollow" class="link" href="https://explorer.livepeer.org/treasury/47675980806842999962173227987422002121354040219792725319563843023665050472833">CloudSPE: Make Network Data More Observable</a>Claimed By: Cloud SPE<div data-type="horizontalRule"><hr></div><h3>Track Progress: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/metrics-and-sla-foundations-for-naap/3189">Forum Updates</a> - <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://discord.com/channels/423160867534929930/1462934576027533415">Discord Updates</a> - <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/Cloud-SPE/livepeer-treasury-proposals/milestones?sort=completeness&amp;direction=desc">GitHub Board</a></h3><div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Lack of trusted, network-wide performance and demand metrics makes it difficult to assess reliability, surface bottlenecks, or confidently onboard real-time AI workloads. Without clear visibility into latency, success rates, capacity, and workload behavior, Livepeer cannot demonstrate production readiness, establish meaningful Service Level Agreements (SLAs), or give builders confidence to deploy real workloads.To advance the real-time AI vision, Livepeer must first measure what matters by establishing unified, trustworthy network observability. A shared data foundation enables consistent SLA tracking, informs scaling and incentive decisions, and gives operators, gateways, and developers a clear, objective view of network performance as demand grows.<blockquote>Prior work: Builds on <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/shtukaresearch/livepeer-data-geography">ecosystem research</a> highlighting fragmented network data and the need for unified, network-wide observability.</blockquote><h2>2. Outcome</h2>Overall success is when Livepeer has a unified, trustworthy observability foundation for real-time AI and video workloads—defined by clear metric schemas and open data pipelines that aggregate network-wide performance and demand data into a single, queryable source. Orchestrators, gateways, and the community can access consistent real-time and historical views across key metrics, enabling analysis, insight, and action. This foundation directly enables SLA scoring, informed orchestrator selection, and continuous reliability improvements as demand grows.Key Metrics To Measure The Outcome Against:<ul><li>Unified Metrics Coverage: Number of core performance and demand metrics defined in a standardized schema and made available network-wide.</li><li>Data Source Integration: Number of distinct network data sources integrated into a unified aggregation layer and exposed through documented access paths.</li><li>Observability Completeness &amp; Reliability: Defined indicators showing freshness, completeness, and consistency of network telemetry (e.g. data latency, missing dimensions, ingestion success rates).</li><li>Reproducible Test Load Results: Availability of standardized test load execution producing repeatable, independently verifiable measurements for key SLA metrics.</li></ul><h2>3. Requirements</h2>Must Have:<ul><li>Unified Metric Definitions: A standardized set of network performance and demand metrics, grounded in stakeholder requirements and consistently defined across the network.</li><li>Network-Wide Aggregation: Metrics collected and aggregated across orchestrators and gateways into a single, queryable source of truth.</li><li>Public Data Access: Documented access to aggregated network metrics that the community can independently query and validate.</li><li>Verifiable Test Load Results: Standardized test load execution producing reproducible, independently verifiable results for key SLA metrics.</li></ul>Should have:<ul><li>Entity-Level Attribution: Metrics attributable to individual orchestrators, gateways, regions, and workflows.</li><li>Historical Coverage: Time-series data sufficient to observe trends, regressions, and improvements over time.</li><li>Operational Signals: Clear, interpretable signals derived from metrics (including test load results) that operators can use to diagnose performance and reliability issues.</li></ul>Nice to have:<ul><li>Health Thresholds: Defined thresholds or indicators that flag degraded or out-of-range network behavior.</li><li>Comparative Baselines: Network-wide averages or benchmarks for contextualizing individual performance.</li><li>Schema Extensibility: Metric definitions designed to evolve without breaking existing consumers.</li><li>Example Analyses: Illustrative analyses or queries demonstrating how aggregated data can be interpreted and used.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

In Progress

Make Network Data More Observable

Mehrdad Sadeghi

Author: Rich O’Grady, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: ClosedWinning Submission URL: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://explorer.livepeer.org/treasury/25461403410134747967575908568157474921037355484043895836877146101186991934108">Transformation SPE Proposal</a>Claimed By: Transformation SPE<div data-type="horizontalRule"><hr></div><h1>Track Progress: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/transformation-spe-release-notes/3142">Forum, Transformation SPE Release Notes</a></h1><div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Builders are the driving force behind discovering and validating new use cases for Livepeer, yet today the ecosystem lacks a structured approach to supporting them. Developers and founders face fragmented access to funding, no dedicated support, and limited visibility into how their efforts connect to Livepeer’s broader go-to-market strategy. Without a clear overview, opportunities are missed, and promising projects struggle to mature into impactful initiatives that expand Livepeer’s adoption and utility.By creating a dedicated builder-focused workstream, the ecosystem can introduce structure, coordination, and targeted and suitable funding mechanisms, which provide better value capture mechanisms (equity / token agreements) for the broader ecosystem. This ensures that projects are not only supported in their early stages but are also equipped to scale, capture value, and align with the network’s strategic goals. Ultimately, this workstream strengthens Livepeer’s ability to transform developer activity into sustainable, high-value outcomes that grow the ecosystem.<h2>2. Outcome</h2>Developers integrating with Livepeer have a clear onboarding flow with clear documentation, tutorials and support. There will be someone dedicated to onboarding demand and navigating any current complexities building on gateways (such as Daydream, Streamplace, Frameworks). There will also be a funding mechanism for microgrants or small-scale integrations.New use cases will have been possible via new larger partnerships (e.g. Base, Zora, Eliza), with a pipeline of potential partners and integrations. Gateways and platforms built on the network will have a structure to support and accelerate demand. Requirements will have been gathered and a pipeline of potential partnerships.Key Metrics To Measure The Outcome Against:<ol><li>Fees / minutes driven on the network.</li><li>partner integrations</li><li>NPS for new onboarding flow</li></ol><h2>3. Requirements</h2><ul><li>Creating a new ecosystem development team focused on onboarding &amp; supporting new builders.</li><li>Launch a knowledge hub or improve documentation on the website for easy onboarding and technical support.</li><li>Launch several key integrations with leading adjacent projects (e.g. Base, Zora, Eliza). within the <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/advisory-boards-phase-1-5-gtm-strategy-2025/3019">GTM bets</a> (e.g. open social or agent frameworks)</li><li>Seed the ecosystem with pre-packaged grant ideas and potential startups in video &amp; real-time AI.</li><li>Activate and connect with an IRL builder community during a major activation at ETH Devconnect.</li><li>Scope a funding mechanism to scale and accelerate promising projects with large ambitions.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Explore New Use Cases & Builder Opportunities

Author: Rick Staa, Livepeer FoundationFunding Mechanism: RFP (Funded by Transformation SPE)Submission URL: ClosedWinning Submission URL: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/rfp-explorer-maintenance/3072">Forum Post</a>Claimed By: RaidGuild<div data-type="horizontalRule"><hr></div><h1>Track Progress: <a target="" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/rfp-explorer-maintenance/3072">Forum</a><a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/rfp-explorer-maintenance/3072"> Updates</a> - <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://github.com/livepeer/explorer/milestones">Github Board</a></h1><div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Restore the Livepeer Explorer to a secure, maintainable, and high-performance state, as the current deprecated and unreliable Explorer limits visibility into the network, introduces security and stability risks, and prevents informed decision-making; recent outages, poor performance, and data quality issues make this work urgent to re-establish a trusted source of truth and enable future network and governance dashboards.<h2>2. Outcome</h2>Overview:Overall success means the Explorer becomes a clean, secure, well-tested, high-performance codebase with no critical bugs, modern dependencies and a clear backlog. It delivers faster UX, a simplified data layer, and integrated voting transparency. It emerges as trusted infrastructure with a 6-month roadmap and an active maintainer team.Key Metrics To Measure The Outcome Against:<ul><li>Resolution of existing issues in the Explorer repository.</li><li>Degree of improvement in voting transparency based on the new voting-transparency feature.</li><li>Degree of improvement in data quality, performance, codebase health, and security compared to the initial state.</li></ul><h2>3. Requirements</h2><h2>Must Have</h2><ol><li>A clean, maintainable Explorer codebase with unnecessary or duplicated components removed.</li><li>A well-tested foundation supported by automated checks and reliable build processes.</li><li>A simplified, efficient data-fetching layer that eliminates redundant calls and improves responsiveness.</li><li>All critical bugs resolved and the backlog reviewed, cleaned, and brought up to date.</li><li>A fully delivered voting-transparency feature connected to the correct data source.</li><li>Regular public progress updates throughout the engagement.</li></ol><h2>Should Have</h2><ol><li>A six-month maintenance roadmap plus clear contributor documentation and workflows.</li><li>A well-organized, clearly labeled issue board that supports ongoing maintenance.</li><li>A support plan with defined response and resolution timelines, including a minimum 60-day post-delivery support window.</li><li>Collaboration with the Foundation and advisors to align fixes and scoped enhancements with network priorities.</li></ol><h1>Out of Scope</h1><ol><li>Full UI/UX redesigns or new visual styles for the Explorer.</li><li>Major new product features beyond the voting-transparency integration.</li><li>Broad data-gap analyses or network-wide data mapping efforts.</li><li>Protocol, client, or on-chain changes required to expose entirely new data.</li></ol><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Upgrade Explorer Infra & Voting Transparency

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/pre-proposal-protocol-r-d-special-purpose-entity/3160">Pre Proposal</a>Winning Submission URL: <a target="" rel="noopener noreferrer nofollow" class="link" href="https://explorer.livepeer.org/treasury/67253869199932483234551664403036205881217777786063955710174984983936506090761">Protocol R&amp;D SPE</a>Claimed By: Side Stream<div data-type="horizontalRule"><hr></div><h1>Track Progress: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/pre-proposal-protocol-r-d-special-purpose-entity/3160">Forum Updates</a></h1><div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer’s protocol secures meaningful on-chain value and increasingly supports real-time AI workloads that depend on reliability, safety, and predictable upgrades. Today, vulnerability response, protocol maintenance, and core development rely on limited shared resources, slowing iteration and making it harder to proactively evolve the protocol as the network grows.To strengthen Livepeer’s long-term foundations, the network needs a dedicated, always-available protocol development and security function with clear ownership, coordinated workflows, and the ability to respond quickly to issues, ship safe upgrades, and maintain essential infrastructure such as a public testnet. Establishing this structure now ensures the protocol remains secure, resilient, and scalable as demand increases.<h2>2. Outcome</h2>Overall success is when Livepeer operates a clearly defined, continuously supported protocol development and security function. Immunefi response and upgrade workflows are formalized and resourced, a stable public testnet is launched for validation, and a lightweight triage and release pipeline is operating and used continuously ship <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Protocol-Engineering-Work-Completed-Under-Prior-Livepeer-Grants-2c6660222d0880349a36f0c6f27bd0ce?pvs=21">prioritized backlog upgrades</a>. This creates a predictable, accountable foundation for safe protocol evolution as the network scales into transcoding and real-time AI workloads. Key Metrics To Measure The Outcome Against:<ol><li>Immunefi Response Readiness: A defined and resourced workflow enabling timely triage and patch preparation.</li><li>Public Testnet Preparedness: A stable testnet launched or fully scoped with a clear operational plan.</li><li>Triage &amp; Release Pipeline: A lightweight prioritization and release process established and in active use.</li><li>Backlog Delivery Velocity: One or more prioritized backlog features or patches progressed through triage → testing → deployment per release cycle.</li></ol><h2>3. Requirements</h2>Must Have:<ul><li>Immunefi Response Workflow: A clearly defined and resourced first-response process for vulnerability triage and patch preparation.</li><li>Public testnet: A stable public testnet for protocol validation, audits, and developer testing.</li><li>Triage &amp; Release Pipeline: A documented process that enables protocol upgrades to move from prioritization through testing to mainnet deployment.</li><li>Backlog upgrades delivered: One or more high-priority protocol upgrades shipped via the triage and release pipeline (examples: fee ticket distinction, reward call delegation).</li></ul>Should have:<ul><li>Release Cadence &amp; Prioritization Model: Initial structure for ongoing triage and predictable upgrade cadence beyond the first release.</li><li>DevEx Improvements: Early tooling or workflows that improve the safety and reliability of protocol development and testing (exam.g., CI integration or simulation tooling).</li></ul><h3>Nice to Have</h3><ul><li>Backlog refinement: A clearly prioritized list of protocol improvements and longer-term R&amp;D needs.</li><li>Contribution pathways: Clear guidance for how community developers can propose or test protocol changes (e.g., governance proposals or testnet workflows).</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Establish Dedicated Protocol Security & Development Capacity

Author: Ben Perez, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: ClosedWinning Submission URL: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://explorer.livepeer.org/treasury/25461403410134747967575908568157474921037355484043895836877146101186991934108">Transformation SPE</a>Claimed By: Transformation SPE<div data-type="horizontalRule"><hr></div><h1>Track Progress: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/transformation-spe-release-notes/3142">Forum, Transformation SPE Release Notes</a></h1><div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer has acute pain points around current capital. On chain liquidity is low, leaking value of LPT holders through high slippage. Inflation is high against external benchmarks, which acts as a barrier to new participants. The treasury is not accumulating new LPT and the current treasury is not actively deployed and so does not generate any yield. We need to address all of this in a holistic way now, as actions in one area can have unintended second-order consequences if not managed carefully.<h2>2. Outcome</h2>Overview:Overall success is creating a working group that collaborates to assess the ecosystem holistically, enabling clear decision-making and actively managing ecosystem capital through more strategic deployment.Key Metrics To Measure The Outcome Against:<ul><li>Improvements in liquidity depth and market efficiency.</li><li>Reduction of treasury concentration risk and clearer capital allocation strategy.</li><li>Measurable progress toward sustainable inflation and data-driven utility models.</li></ul><h2>3. Requirements</h2><ul><li>Establish a Capital Management working group with clear mandate and decision structure.</li><li>Propose a plan to increase DEX liquidity for key LPT pairs on Arbitrum.</li><li>Propose adjustments to inflation parameters to support long-term network health.</li><li>Propose whether to maintain or modify the treasury cap and outline a strategy for accumulating LPT.</li><li>Implement an active capital management approach that funds ecosystem operations and reduces risk.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Improve Livepeer’s Capital Management

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: ClosedWinning Submission URL: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://explorer.livepeer.org/treasury/25461403410134747967575908568157474921037355484043895836877146101186991934108">Transformation SPE</a>Claimed By: Transformation SPE<div data-type="horizontalRule"><hr></div><h1>Track Progress: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/transformation-spe-release-notes/3142">Forum, Transformation SPE Release Notes</a></h1><div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer’s current payment model requires developers and gateway operators to manage crypto payments and private keys as part of running media workflows. This increases operational complexity and security risk, raises onboarding friction, and concentrates usage around a small number of centralized gateway providers, limiting access to the network and constraining growth.To support Livepeer’s evolution into a scalable real-time AI and video network, the protocol needs a simpler and safer foundation for payments and gateway access. A standalone payment signer and local gateway SDK allow applications and gateways to use the network without directly managing crypto keys or payment logic, reducing gateway complexity and improving security. This work unlocks account-based payment services (clearinghouses), enables more direct and lower-latency interactions with orchestrators, broadens participation by builders and gateway operators, and prepares the network to support higher-scale real-time AI workloads aligned with the updated network vision.<h2>2. Outcome</h2>Overall success is when Livepeer offers a developer-friendly payment and gateway access layer that allows applications to use the network without managing crypto wallets or payment infrastructure. Gateways can safely delegate payment signing to a standalone signer, and developers can interact with the network through a lightweight local SDK, including directly from browser or server environments, without operating a full gateway stack. This enables low-latency, direct interactions with orchestrators required for real-time use cases such as cloud gaming and interactive AI, while significantly lowering the barrier to onboarding and experimentation. Key Metrics To Measure The Outcome Against:<ol><li>Payment Signer Adoption: At least two gateway operators or ecosystem partners successfully using signer mode in testing or production.</li><li>Local SDK Functionality: A minimal, documented SDK enabling applications to submit jobs and handle payments from at least one environment (browser or server)</li><li>Integration Examples: At least one working reference integration demonstrating end-to-end usage of payment signer and local SDK.</li></ol><h2>3. Requirements</h2>Must have:<ul><li>Clearinghouse Design Document: A written design and phased roadmap defining the clearinghouse model, signer mode, and future extension paths.</li><li>Payment Signer Mode: A standalone go-livepeer signer that signs payment tickets with payment keys isolated from media workflows, without changing orchestrator job flows.</li><li>Local Gateway SDK (MVP): A minimal SDK enabling applications to interact with Livepeer from a browser or server without operating a full gateway.</li><li>End-to-End Validation &amp; Documentation: Signer mode and SDK validated through an end-to-end real-time AI workflow, with clear setup documentation for developers and operators.</li></ul>Should have:<ul><li>Reference Example: One minimal example showing how an application uses the local SDK together with signer mode.</li><li>Operator Adoption Guidance: Clear instructions for operators to deploy and test signer mode in a non-production or pilot setting.</li></ul>Nice to have:<ul><li>Developer Utilities: Small utilities for validating signed tickets and troubleshooting local SDK interactions.</li><li>Transcoding Compatibility: Optional support for transcoding workflows alongside real-time AI workflows.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Simplify Crypto Payments & Enable Local Gateway SDKs

Author: Rich O’Grady, Livepeer FoundationFunding Mechanism: Livepeer FoundationSubmission URL: ClosedWinning Submission URL: ClosedClaimed By: Livepeer Foundation<div data-type="horizontalRule"><hr></div><h1>Track Progress: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/t/transformation-spe-release-notes/3142">Forum, Transformation SPE Release Notes</a></h1><div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer needs to define its core opportunity which can form the foundation of a GTM effort.Since its launch in 2017, Livepeer’s mission has been to offer the world’s open video infrastructure, building a respected and trusted brand rooted in decentralized video technology enabled by cryptoeconomic primitives.More recently, Livepeer has expanded into AI through multiple ecosystem initiatives, but without a dedicated GTM effort to unify them around a clear network value proposition. Defining the core opportunity now is necessary to align these efforts, focus resources, and prevent further fragmentation as the ecosystem grows.<h2>2. Outcome</h2>Success means delivering a detailed market intelligence report which can be used for lead generation.Building on detailed interviews with prospective customers, the report should equip the Livepeer ecosystem with a clear overview of the market landscape and a breakdown of ideal customer profiles (ICPs) with clear value propositions for each.All of the work should tee up the core teams behind the Livepeer network’s GTM. For Network ProdEng, the report should provide direction for core requirements and competitor benchmarking. For Livepeer Marketing, it should give clear ICPs to target. For BD, it should provide a pipeline of potential customers and the basis for a sales deck.Key Metrics To Measure The Outcome Against:<ol><li>Engagement from content pieces published</li><li>Number of new customer opportunities identified</li><li>Total number of new customer interviews</li><li>Leads generated by the report</li></ol><h2>3. Requirements</h2><ul><li>Develop a detailed interviewee list and research questionnaire, with internal sign-off before interviews begin.</li><li>Produce a first draft of the market landscape analysis for internal review and approval.</li><li>Deliver a first draft of the Ideal Customer Profile (ICP) and Customer Value Proposition for internal review and sign-off.</li><li>Conduct interviews with prospective users and partners, with a structured summary of insights.</li><li>Present findings to the community for visibility, transparency, and feedback.</li><li>Compile a database of 50 companies and organisations, including logos, for inclusion in a visualised market map.</li><li>Publish a final report incorporating all research phases, community feedback, and validated insights.</li></ul>

Map Livepeer’s Market Landscape & Future Customers

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/c/treasury/18">Apply Here</a>Winning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer needs an improved gateway product to respond to real-world customers and truly diversify demand.This opportunity is to improve the gateway developer experience, providing an easier way for builders to build and deploy apps and services and onboard demand directly on the network at scale.Currently Livepeer’s network demand is overly-reliant on gateways controlled by a handful of entities, mostly operated by Livepeer Inc. A healthy Livepeer network will have many gateway nodes run by many different entities sending many jobs to many Orchestrators. However, building and deploying a gateway is too complex for most builders currently.Livepeer as a network has a clear opportunity to differentiate its offering against other generic compute providers, but it is currently not possible to capture this realtime opportunity. Working with key ecosystem demand partners (Daydream, Embody, Frameworks, Streamplace) alongside several new potential actors, this team is critical to the long-term success of the network.<h2>2. Outcome</h2>Overall success is when Livepeer improves its gateway offering to meet the needs of new customers wanting to build on the network.The new gateway experience should make use of several concurrent an emerging developments: local gateways SDKs, observable network data, payments clearinghouses, and SLA-compliance communicating where they fit into the broader network product vision.Developers should be able to onboard seamlessly to the Livepeer network with relevant SDKs, clear documentation and demo applications. The developer experience should be tested with 3-5 core design partners eager to build realtime applications directly on the network, with a concise report on how to unlock demand for the future.Key Metrics To Measure The Outcome Against:<ul><li>Number of new demand-generating applications launching on the Livepeer network.</li><li>Time to go from 0 to production-ready realtime AI application or service.</li></ul><h2>3. Requirements</h2>Must have:<ul><li>Developer onboarding path: Steps mapped to take a builder from workflow definition to successful deployment of an app.</li><li>Core runtime &amp; SLA improvements: Measurable gains in workflow reliability, latency stability, failover behavior, and predictability under real-time workloads.</li><li>Documentation and tutorials: Simple examples and walkthroughs showing how to go from 0 to 1 and bring demand to the network.</li><li>SDK and tools: A well-designed SDK with examples, including CLI wrappers and sample apps that simplify common developer tasks.</li><li>Customer-centric approach: Dedicated time taking meetings with potential customers fed by a concurrent BD team.</li><li>Gateway Product Retro &amp; Report: A clear report on the learnings from the initial testing, clarifying developer needs and opportunities for the future.</li></ul>To explore:<ul><li>SDK Integration &amp; Iteration: Use of local SDKs to validate how payment abstraction integrates with application workflows and inform SDK improvements.</li><li>Crypto Payment Abstraction Module exploration: An MVP module encapsulating account-based crypto-abstracted payment flows handling real payment flows, balance tracking, and reporting.</li><li>Usage dashboard - dashboard of network usage for developers, exploring collaboration with network observability team or a new account-based system.</li><li>Diagnostics &amp; error handling: Clear, actionable error reporting at the gateway interface to understand failures and routing behavior.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul><table style="minWidth: 50px"><colgroup><col><col></colgroup><tbody><tr><td colspan="1" rowspan="1"></td><td colspan="1" rowspan="1"></td></tr><tr><td colspan="1" rowspan="1"></td><td colspan="1" rowspan="1"></td></tr><tr><td colspan="1" rowspan="1"></td><td colspan="1" rowspan="1"></td></tr></tbody></table>

Coming Soon

Improve Gateway Product To Meet Customer Needs

Author: Rich O’Grady, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>With Livepeer’s new focus on realtime AI &amp; video, the creation and focus of the Daydream community and product, and the development of new gateway services (Streamplace, Frameworks, Embody), each part of the Livepeer story needs to be coherently weaved together.The market for video is exploding as it merges with AI. This opportunity is to lead a team dedicated to advancing the Livepeer brand, connecting the network product, token and ecosystem. As both a compute network and specialised video infrastructure, Livepeer needs to communicate its value propositions to new customers and investors.<h2>2. Outcome</h2>By the end of this 6-month period, Livepeer will have formed its own category and positioned itself as a market leader in providing specialised infrastructure for real-time video and AI. It will have identified its market and have the foundations of a go to market, which can be taken forward in collaboration with other teams.Some key metrics include:<ol><li>Number of inbound, qualified developer leads</li><li>Social followers and/or social engagement</li><li>Discord members increase</li><li>Discord member engagement</li></ol><h2>3. Requirements</h2>Any proposal should include the following:<ul><li>Speak with customers, builders and core stakeholders to position the Livepeer project, and build a compelling narrative within the market landscape.</li><li>Create ICPs, lists of potential leads from targeted marketing campaigns and key GTM materials to support BD team.</li><li>Upgrade the Livepeer brand, with a new design and core assets, integrating the new brand across online assets and IRL activations.</li><li>Create and distribute high quality content across core social channels, driving Livepeer forward as a thought leader in its category.</li><li>Improve the Livepeer website, communicating the core value proposition throughout and having clear, simple pathways for each of the personas.</li><li>Manage 2x high-profile IRL activations to build brand, attract new talent and capital to the Livepeer ecosystem and create a movement towards the overall vision.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes &amp; KPI targets</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Drive Awareness Of AI-Centric Livepeer Brand & Vision

Author: Rich O’Grady, Livepeer FoundationFunding Mechanism: Livepeer FoundationSubmission URL: ClosedWinning Submission URL: ClosedClaimed By: Livepeer Foundation<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer must proactively engage with and acquire customers who will drive meaningful demand to the Livepeer network.As the AI and video landscapes merge and evolve, application developers increasingly require accessible, cost-effective platforms for building real-time video and AI products.This opportunity will identify, prospect, and design technical solutions for new customers while ensuring their needs directly inform the roadmap of Livepeer’s products. By filling a gap where gateway teams often lack dedicated business development resources, the aim is to serve as the bridge between market demand and network capability, ensuring Livepeer remains relevant, developer-friendly, and strongly aligned with real-world use cases.<h2>2. Outcome</h2>Success is tens of thousands in fees onboarded by real-world customer.It is the creation and nurturing of a strong customer acquisition pipeline, hitting a range of ICPs and testing core value propositions. It consistently brings new demand-generating applications onto the Livepeer network. The group will validate real customer needs, architect solutions that make it easy to build on Livepeer, and channel these insights directly into product direction.Key Metrics To Measure The Outcome Against:<ol><li># of qualified customer conversations per month</li><li># of new integrations or pilots launched</li><li>Revenue or fees generated from newly onboarded customers</li><li>of product insights / feature requests contributed to roadmap</li></ol><h2>3. Requirements</h2><ul><li>A clear breakdown of ICPs across verticals (e.g., AI apps, video platforms, robotics, monitoring, gaming tools).</li><li>A structured process for building a customer acquisition pipeline and prospecting, qualifying, and engaging potential customers, sharing updates with the community.</li><li>An effective solution architecture and engineering framework to help onboard customers build real-time video + AI on Livepeer.</li><li>A mechanism for testing value proposition hypotheses, capturing customer insights and feeding them back into the gateway product team to make improvements.</li><li>A plan for collaboration with gateways, ensuring smooth handoff between BD → technical onboarding.</li><li>A clear success narrative that ties customer acquisition directly to network demand growth.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Find, Understand & Onboard Real-World Customers

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>With payment signer mode and local SDK foundations in place, Livepeer can now abstract away direct crypto handling and significantly simplify gateway and application integration. The next open question is which payment abstractions, currencies, and SDK services meaningfully improve developer experience and unlock demand for direct, low-friction, low-latency compute on the network. Without a clear, evidence-backed understanding of developer needs and usage patterns, improvements to onboarding, SDK design, and payment flows risk being misaligned with where they deliver the most impact.This opportunity focuses on researching, validating, and piloting account-based payment flows on top of the new signer and SDK foundations, including the use of a community-funded reference payment provider (clearinghouse) as a learning vehicle. The goal is to determine where payment abstraction meaningfully improves onboarding, which SDK capabilities developers actually need, and which payment models and currencies are most appropriate, producing a clear blueprint for scaling non-crypto-native usage while preserving direct, decentralized access to the network.<h2>2. Outcome</h2>Overall success is when Livepeer demonstrates that account-based, crypto-abstracted payment flows materially improve developer onboarding and simplify gateway operations, enabling applications and ecosystem programs to use the network without managing crypto wallets, keys, or on-chain balances. This is validated through a reference implementation, potentially a community-funded clearinghouse, used to exercise payment flows, settlement options, reporting, and local SDK integration. The resulting learnings are captured in a clear blueprint that guides how payment abstraction and SDKs can unlock new demand, support grants and growth initiatives, and inform future payment providers while preserving decentralized network access.Key Metrics To Measure The Outcome Against:<ol><li>Validated Payment Abstraction Findings: Documented insights identifying which payment abstractions, currencies, and SDK services most effectively reduce onboarding friction and simplify gateway operations.</li><li>Working Reference Implementation in Use: A working reference implementation used by developers or ecosystem programs to exercise end-to-end payment flows and local SDK integration across at least two representative use cases.</li><li>Blueprint Published: A public blueprint and supporting documentation translating findings into clear guidance for future payment providers and SDK evolution.</li></ol><h2>3. Requirements</h2>Must have:<ul><li>Research Report &amp; Findings: A written report summarizing developer needs, use cases, and evidence-backed conclusions about which payment abstractions, currencies, and SDK services deliver the most impact.</li><li>Reference Payment Implementation: A working reference implementation to validate account-based, crypto-abstracted payment flows. This may take the form of a community-funded clearinghouse and should support real payment flows, balance tracking, and reporting.</li><li>Blueprint &amp; Recommendations: Clear documentation of findings and trade-offs, resulting in a blueprint for future payment providers and SDK evolution.</li></ul>Should have:<ul><li>SDK Integration &amp; Iteration: Use of local SDKs to validate how payment abstraction integrates with application workflows and inform SDK improvements.</li><li>Developer Onboarding Examples: Simple examples or walkthroughs showing how developers, grants, or ecosystem programs onboard using the proposed payment abstractions.</li></ul>Nice to have:<ul><li>On-Chain Differentiation Exploration: Optional exploration of on-chain metadata or differentiation mechanisms to improve transparency and reporting.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Explore Account-Based Payments & Evolve Local SDKs

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer’s pipelines for transcoding and real-time AI currently lack a unified way to preserve and emit provenance metadata, making it difficult for applications to maintain content authenticity as video moves through the network. This limits creators, platforms, and distribution partners who increasingly rely on verifiable media in an era of AI-generated content, and prevents developers from understanding which transformations, models, or workflows produced a given output.Establishing a shared, network-level provenance and signing mechanism allows authenticity metadata to flow end-to-end through both transcoding and real-time AI workflows. This enables CDN and downstream integrations, gives builders trusted signals about how content was produced, and supports safer AI applications, deepfake-resistant experiences, and pipeline debugging. By embedding authenticity and provenance directly into Livepeer’s core pipelines, the network strengthens its role as open, reliable video and AI infrastructure and creates a durable foundation for future trust and verification capabilities.<h2>2. Outcome</h2>Overall success is when Livepeer reliably preserves and emits signed provenance metadata end-to-end across both transcoding and real-time AI workflows. Applications can pass authenticity data into Livepeer and receive outputs with trusted metadata intact, describing how content was transformed, which models or processes were applied, and which nodes executed the work. This enables CDN integrations, authenticity-aware video experiences, safer AI applications, and improved pipeline debugging, while establishing Livepeer’s first production-grade authenticity and provenance primitive shared across workload types.Key Metrics To Measure The Outcome Against:<ol><li>Authenticity Metadata Coverage: Percentage of active transcoding and real-time AI workflows producing outputs with preserved, signed provenance metadata.</li><li>Downstream Authenticity Utilization: Number of downstream consumers (e.g. CDNs, platforms, applications) actively integrating Livepeer-emitted provenance metadata.</li><li>Pipeline Non-Regression: Provenance preservation and signing do not materially increase latency, error rates, or resource usage across transcoding or real-time AI pipelines.</li></ol><h2>3. Requirements</h2>Must Have:<ul><li>Opt-in provenance passthrough: When enabled, provenance metadata must be preserved end-to-end across transcoding and real-time AI workflows and remain verifiable downstream.</li><li>Signed metadata emission: Support for emitting signed, machine-readable provenance metadata alongside outputs when requested.</li><li>Workflow-agnostic provenance schema: A single structured schema usable across transcoding and real-time AI, supporting content authenticity, transformation history, execution attribution, and policy metadata.</li><li>Accessible provenance exposure: Emitted provenance metadata must be exposed in a documented, consumable form so applications and downstream systems can reliably use it.</li></ul>Should Have:<ul><li>CDN and distribution compatibility: Output formats and metadata should be compatible with at least one downstream distribution or CDN provenance workflow.</li><li>AI-specific provenance fields: Support for AI-related metadata such as model identity, version, or transformation type.</li><li>Workflow usage demonstration: Provenance support demonstrated on at least one real-time AI workflow or video pipeline in active ecosystem use.</li></ul>Nice To Have:<ul><li>Execution attribution signals: Optional metadata allowing orchestrators or workers to attest that they performed a given transformation, useful for debugging and early reliability analysis.</li><li>Metadata validation &amp; filtering: Basic handling of malformed, missing, or partial provenance metadata at ingest to support robustness and debugging.</li><li>Future extensibility: A design that can later support compute attestation or verification layers without breaking compatibility.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Enable Verifiable Content Metadata & Authenticity

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer’s ability to support growing real-time AI demand is increasingly constrained by limited and inflexible compute supply. As real-time AI usage scales, peak demand exposes gaps in available capacity and resilience. At the same time, many GPU owners cannot contribute compute because running an orchestrator requires stake, ongoing operational management, and complex setup and scaling workflows, creating a high barrier to supply participation.As Livepeer transitions from early real-time AI traction to sustained production usage, the network needs a more flexible and resilient supply layer. Improving orchestrator setup and runtime operations reduces friction to scale real-time AI workloads, while a robust, open-source GPU pool framework lowers the barrier for external GPU owners to contribute compute. Performance-aware selection ensures that scalable, reliable orchestrators are consistently rewarded as demand grows, enabling the network to scale reliably under real-world load, advancing Livepeer’s vision as scalable infrastructure for real-time AI media.<h2>2. Outcome</h2>Overall success is when Livepeer can reliably scale real-time AI compute supply under real demand. Orchestrators can adjust capacity dynamically with minimal operational friction and operate real-time AI workloads through simpler, more predictable setup and operations. External GPU owners contribute compute through orchestrators via a proven, open-source pool model, validated by a real-world reference pool demonstrating reliable performance at scale. Performance-aware selection consistently favors higher-performing orchestrators, reinforcing network reliability and performance as real-time AI adoption grows.Key Metrics To Measure The Outcome Against:<ol><li>Active AI Compute Capacity Growth: Net increase in the number of GPUs actively serving real-time AI workloads, relative to a defined baseline.</li><li>Dynamic Supply Adoption: Number of orchestrators actively serving real-time AI workloads using pools or dynamic worker attachment.</li><li>Operational Friction Reduction: Evidence that deploying and scaling real-time AI workloads requires less manual effort.</li><li>Performance-Aware Selection Impact: Evidence that selection informed by reliability and performance signals consistently routes workloads toward higher-performing orchestrators.</li></ol><h2>3. Requirements</h2>Must Have:<ul><li>Dynamic supply support for orchestrators: Orchestrators can adjust real-time AI compute capacity at runtime (e.g. add or remove GPU workers) while maintaining reliable job execution.</li><li>Open-source GPU pool framework: A public, open-source pool mechanism enabling external GPU owners to contribute real-time AI compute via orchestrators.</li><li>Simplified orchestrator operations: Documented, low-friction workflows that reduce the effort to deploy, scale, and operate real-time AI workloads as an orchestrator.</li><li>Reference pool deployment: A reference deployment demonstrating reliable operation of the pool model under sustained real-time AI workloads.</li><li>Performance-aware selection integration: Enhanced orchestrator selection using reliability and performance signals, with gateway-configurable SLA-informed decisioning.</li></ul>Should Have:<ul><li>Basic operational visibility: Operator-facing metrics exposed via lightweight tools (CLI or minimal dashboard) for worker status, capacity, and job activity.</li><li>Worker performance differentiation: Mechanisms to identify and deprioritize underperforming workers within dynamic supply or pool configurations.</li><li>Integration with existing Livepeer clients: Pool, dynamic supply, and selection capabilities integrate with existing Livepeer orchestrator and gateway clients without protocol changes.</li></ul>Nice to have:<ul><li>Configurable pool incentives: Flexible fee or reward-sharing configurations between orchestrators and external GPU contributors.</li><li>Forkable pool dashboard: A simple, forkable reference dashboard that visualizes pool and worker status, intended as a starting point for operators rather than a fully supported product.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Improve Orchestrator Onboarding & Compute Supply

Author: Rich O’Grady, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer needs to diversify demand by exploring new markets at the intersection of AI &amp; video.As Doug Petkanics, Founder &amp; CEO of Livepeer, laid out in his <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://blog.livepeer.org/a-real-time-update-to-the-livepeer-network-vision/">real-time update</a>, the ecosystem should look to enable “startups in each category going after building real-time AI platforms that serve gaming, that serve robotics, that serve synthetic data generation, that serve monitoring and analysis, and all the additional relevant categories.”<img data-width="100%" data-align="left" alt="" data-featurebase-content-key="6908e89ba49bec81d940e862/post/693d41957a87d23b47bd6e13/019b2948-c397-790c-9d5f-10c945af0a77/b64u-YWFhc3d3dy5wbmc.png" data-featurebase-content-filename="aaaswww.png" src="https://6908e89ba49bec81d940e862.featurebase-attachments.com/c/post/693d41957a87d23b47bd6e13/019b2948-c397-790c-9d5f-10c945af0a77/b64u-YWFhc3d3dy5wbmc.png?X-Amz-Expires=3600&amp;X-Amz-Date=20260201T200000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260201%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=756d29ed0baabd8973327f78baff4b5b80ac87d9627b1066dc224bbdd5f85b53">While in the past, grants, hackathons and startup programs have been used, they’ve proved ineffectual in: (a) equipping high-quality founders with what they need for success; and (b) ensuring loyalty to build with and on the Livepeer network.This opportunity will therefore explore the use incentives (like investment or credits) to bootstrap these businesses into existence. Each will represent a chance at success, and will bring more demand and proof.<h2>2. Outcome</h2>A new program will seed, incubate, and accelerate new products built on the Livepeer network targeting different verticals enabling real-time video AI. It will have some value capture for the Livepeer ecosystem and aim to align these startups with the long-term success of the Livepeer network.Key Metrics To Measure The Outcome Against:<ol><li>of new startups build on Livepeer</li><li>of new gateways on the network</li><li>Fees / minutes added on the network</li></ol><h2>3. Requirements</h2><ul><li>Define the verticals (e.g., gaming, robotics, synthetic data, monitoring) where Livepeer aims to seed real-time video AI startups.</li><li>Outline the incentive model — investment, credits, grants, infrastructure support — and how it ensures long-term alignment with the Livepeer network.</li><li>Detail the value-capture mechanism (e.g., revenue share, token alignment, equity, network lock-ins, gateway commitments).</li><li>Design a structured incubation/acceleration process, including founder support, technical enablement, mentorship, and milestones.</li><li>Specify selection criteria for identifying high-quality founders and teams most likely to succeed in these verticals.</li><li>Define the budget and resource allocation needed (investment pool, engineering support, ecosystem ops, evaluators).</li><li>Establish a governance process for selecting startups, distributing incentives, and measuring performance.</li><li>Outline technical requirements for integrating with the Livepeer network, including gateway creation, usage commitments, or API integration.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Incentivize New Bets Across Real-Time Video AI Verticals

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL:<a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://forum.livepeer.org/c/treasury/18"> Apply Here</a>Winning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Livepeer’s shift toward real-time AI has diversified demand, but reliable, high-quality transcoding remains a foundational capability for building real-world video applications. Today, the network cannot consistently convert decentralized transcoding capacity into production-grade workloads, limiting adoption by platforms that require predictable performance, modern codecs, and operational reliability.As decentralized video platforms (e.g. Streamplace) and streaming gateway providers (e.g. Frameworks) gain traction, Livepeer must strengthen and modernize its transcoding stack so applications can depend on it directly, not only through Livepeer Studio, but via multiple gateways across the ecosystem. Improving core transcoding capabilities now ensures Livepeer continues to fulfill its mission as the open video network of the world, offering a complete, production-ready media primitive alongside emerging real-time AI workflows.<h2>2. Outcome</h2>Overall success is when Livepeer reliably converts decentralized transcoding capacity into sustained, production-grade workloads. Performance is predictable under real load, modern codecs and formats are supported, and multiple independent gateways—not just Livepeer Studio—can onboard and operate real applications. Transcoding becomes a dependable, first-class network primitive that strengthens Livepeer’s role as the open video network of the world. Key Metrics To Measure The Outcome Against:<ol><li>Transcoding Demand &amp; Fees: Sustained growth in production transcoding minutes and fees generated on the network.</li><li>Gateway Adoption: Number of independent gateways actively offering production transcoding services.</li><li>Application Usage: Number of distinct applications running sustained, non-test transcoding workloads.</li><li>Performance Predictability: Defined and consistently achieved success-rate, latency, and error targets under representative load.</li></ol><h2>3. Requirements</h2>Must Have:<ul><li>Production-Grade Transcoding Capability: Core transcoding functionality that delivers reliable, predictable performance suitable for sustained real-world workloads.</li><li>Modern Codec &amp; Format Support: Support for contemporary codecs and formats required by production video applications.</li><li>Operational Predictability: Resource management and load handling that maintain consistent behavior under variable demand and prevent overload.</li><li>Multi-Gateway Operability: Transcoding capabilities that can be operated by multiple independent gateways, not tied to a single distribution channel.</li></ul>Should Have:<ul><li>Clear Documentation &amp; Onboarding: Documentation and examples sufficient for applications and gateway providers to adopt transcoding without bespoke support.</li><li>Hardware Diversity Support: Demonstrated support for multiple hardware classes to expand operator participation and network capacity.</li><li>Basic Observability: Performance and utilization signals sufficient for operators and gateways to diagnose failures and understand behavior under load.</li></ul>Nice To Have:<ul><li>Unified Media &amp; AI Workflows: Ability to compose transcoding with real-time AI processing (e.g. transcription, video understanding) into a single pipeline.</li><li>Developer &amp; Operator Tooling: Optional tooling that reduces friction in managing transcoding workloads and infrastructure.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Upgrade Transcoding Capabilities

Author: Mehrdad Sadeghi, Livepeer FoundationFunding Mechanism: Livepeer FoundationSubmission URL: ClosedWinning Submission URL: ClosedClaimed By: Livepeer Foundation<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>The roadmap is a canonical piece for the Livepeer network, creating clarity around what is needed and where resources should go. However, it is incomplete without a proper process to drive accountability over delivery. It’s important to maintain the current momentum and put the guardrails in place to ensure the network stays on the correct path.<h2>2. Outcome</h2>Overview:Overall success is an accountability mechanism that ensures everything promised by contributors is delivered within the timeline agreed upon in their proposal, and that the community is updated at each step of the process.Key Metrics To Measure The Outcome Against:<ul><li>Number of milestones delivered on time vs. missed deadlines.</li><li>Number of deliverables actually delivered vs. promised.</li><li>Comparison of the improvement in transparency and visibility of information compared to the past.</li><li>Average number of updates per project per milestone.</li></ul><h2>3. Requirements</h2><h3>Must</h3><ul><li>Establish shared standards and expectations for contribution, including definition of high-performing</li><li>Define a milestone-based tracking mechanism with the correct incentives to continuously drive accountability from contributors.</li><li>Define communication between different working groups.</li><li>Bring transparency and visualize the progress of work over the deliverables of contributors and timeline.</li><li>Implement a consistent update cadence for all contributors, tied to milestone progress.</li><li>Define a standardized process for verifying completed work and approving milestone payouts.</li><li>Provide documentation around the onboarding process for contributors and using the accountability system.</li></ul><h3>Should</h3><ul><li>Provide a simple, public dashboard where the community can track progress, delivered work, delays, and updates.</li><li>Provide templates and guidelines that make it easier for contributors to create clear milestones, deliverables and updates.</li><li>Create a funnel where accountability updates from contributors feed into marketing and social media amplification.</li></ul><h3>Nice To Have</h3><ul><li>Introduce lightweight automation to reduce manual overhead (e.g., auto-tracking updates, reminders, or status changes).</li></ul><ul><li>Simplify processes through integrating new technologies such as AI agents.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Drive Contributor Accountability Across Roadmap Items

Author: Ben Perez, Livepeer FoundationFunding Mechanism: Livepeer FoundationSubmission URL: ClosedWinning Submission URL: ClosedClaimed By: Livepeer Foundation<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>Optimise and deploy capital to support roadmap acceleration and create sustainable ecosystem health<h2>2. Outcome</h2>Overview:Success is ensuring that Livepeer is:<ul><li>Efficient and cost effective for people to participate in the network</li><li>Deploying capital to its most important projects</li><li>Iterating on value creation and capture through LPT</li><li>Continuing to grow its treasury and reduce its risk</li></ul>Key Metrics To Measure The Outcome Against:<ol><li>2% Depth</li><li>Treasury Runway</li><li>Inflation rate</li><li>Fee Revenue coverage</li></ol><h2>3. Requirements</h2><ul><li>Implement further capital strategies that increase market depth and proactively manage inflation</li><li>Manage capital and reduce risks by increasing the utility of LPT and using yield-based strategies to increase the treasury.</li><li>Optimise treasury operations to sustainably fund operations without increasing sell pressure</li><li>Model of the tokenomics and economy of Livepeer to take a more principled approach to decisions</li><li>Creating a network of experts and knowledgeable parties to help Livepeer achieve Tier1 capital practices</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Manage And Increase Capital  For Ecosystem Success

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>With more reliable gateway infrastructure, improving network performance, expanding network-wide observability, and emerging payment abstractions maturing, Livepeer is already supporting a growing set of real-time AI and media capabilities exposed through gateways and applications. As these foundations continue to mature and enable new gateway products and services, the next challenge is how these capabilities are surfaced to builders in a clear, product-oriented way, so developers can understand what is available, how it behaves, and how to begin using it.This opportunity focuses on defining the right network-level capability discovery and activation layer for Livepeer. It explores how builders should discover, understand, compare, and begin using real-time AI and media building blocks across gateways, whether through a marketplace-style interface or another discovery approach, without committing to a single product form. The work will produce a clear product direction, a documented builder journey from discovery to first use, and a lightweight prototype to validate key assumptions and inform a future execution phase.<h2>2. Outcome</h2>Overall success is when Livepeer has a clearly defined and validated direction for a developer-friendly, network-level capability discovery and activation surface that complements the Explorer. The work defines how real-time AI and media capabilities are discovered, compared, and selected across gateways, and how developers move from exploration to first experimentation and toward building real applications that generate network demand. This direction is validated through a lightweight, working prototype that exercises the discovery and activation flow end-to-end and informs future phases of product execution.Key Metrics To Measure The Outcome Against:<ol><li>Discovery &amp; Activation Direction Defined: A clearly documented decision defining how network capabilities are discovered and activated, including the rationale, key decisions, and trade-offs, informed by real developer or ecosystem feedback.</li><li>Working Prototype Validated End-to-End: A lightweight, working prototype that implements the discovery and activation flow from capability discovery to first experimentation, validated through real developer or ecosystem usage.</li></ol><h2>3. Requirements</h2>Must have:<ul><li>Capability Discovery &amp; Activation Report: A concise document defining the network-level capability discovery and activation approach, the builder path from discovery to first usage, key design decisions and trade-offs, and how it integrates with existing surfaces.</li><li>Working Prototype for Validation: A lightweight, working prototype that implements the discovery and activation flow end-to-end and validates key assumptions through real user interaction.</li></ul>Should have:<ul><li>Builder &amp; Gateway Feedback: Documented feedback from builders and gateway operators based on hands-on prototype use, validating clarity and usability.</li><li>Activation Touchpoints: Demonstration of how capability discovery leads to first experimentation (e.g., via gateway endpoints, SDKs, or runnable examples).</li></ul>Nice to have:<ul><li>Observability Signal Exploration: Early exploration of how capability-specific signals (e.g., latency, availability, or readiness) could be surfaced to inform discovery and selection in future phases.</li><li>Payment Abstraction Considerations: Consideration of how payment abstractions or clearinghouses could enable low-friction experimentation from the discovery surface in later roadmap phases.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Define Network Capability Discovery & Activation

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>As Livepeer scales beyond transcoding into real-time AI workloads, builders and enterprises need confidence that compute was performed correctly and according to expectations. While the network has made progress on <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://medium.com/livepeer-blog/livepeer-transcoding-verification-improvements-the-next-level-of-network-security-328b47350e24">verification for non-deterministic GPU transcoding</a>, there is no general, network-level verifiable compute mechanism that extends these guarantees to AI-based computation. This limits the network’s ability to reason about correctness, reliability, and accountability as new workloads are introduced.Delivering verifiable compute for real-time AI addresses this gap by establishing a flexible, extensible verification framework that enables independent validation of how computation was executed. This strengthens SLAs, improves reliability, and enables developers to build safety-critical and production-grade applications. By extending verification beyond transcoding, Livepeer can scale real-time AI workloads while maintaining trust and long-term credibility as open AI infrastructure.<h2>2. Outcome</h2>Overall success is when Livepeer provides a network-level verifiable compute capability that allows developers and applications to independently assess whether real-time AI workloads, and existing transcoding workloads, were executed correctly. Builders can rely on consistent verification signals to reason about correctness, detect misbehavior, and assess confidence in network results at scale. This verifiable compute layer becomes a core trust primitive for Livepeer, strengthening SLAs and enabling the network to support real-time AI workloads with confidence.Key Metrics To Measure The Outcome Against:<ol><li>Verification Signal Availability: Real-time AI workflows emit verifiable compute signals that applications can consume to assess execution correctness or confidence.</li><li>Production Usage Signal: Verifiable compute signals are active in at least one production pipeline and are actively consumed by a builder or application.</li><li>Operational Non-Regression: Verification improves visibility into correctness and reliability without materially degrading performance or latency.</li></ol><h2>3. Requirements</h2>This work should cover the following:<ul><li>A clear network-level approach for verifiable compute that allows applications to assess correctness, reliability, or confidence of real-time AI workloads on Livepeer, building on existing transcoding verification mechanisms.</li><li>An extensible verification model that can evolve over time to support different verification techniques and workload types, rather than committing to a single mechanism.</li><li>Definition of developer-consumable verification signals that applications could use to assess trust in compute results, without assuming full determinism or perfect correctness.</li><li>Analysis of key trade-offs and constraints, including performance overhead, cost, decentralization impact, and limitations inherent to non-deterministic AI workloads.</li><li>Consideration of how Livepeer’s verification direction could align or interoperate with external verification or trust frameworks where appropriate, rather than re-implementing all components in-house.</li><li>A concise artifact (e.g. document or lightweight prototype) describing the proposed approach, assumptions, guarantees, limitations, and recommended next steps for future roadmap phases.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Establish Verifiable Compute Foundations for Real-Time AI

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>As Livepeer’s real-time AI workloads mature, the network will need to scale beyond manually operated setups to support higher-capacity compute participation, including operators running managed GPU clusters or data center infrastructure. These participants can contribute significant idle compute, but operating at this scale requires more structured and repeatable setups, such as automatable onboarding and teardown workflows, strong workload isolation, real-time operational visibility, and defined security boundaries, to safely add and reclaim capacity as their own demand fluctuates.Supporting low-friction onboarding of high-scale compute through compatibility with common orchestration frameworks (e.g. Kubernetes), along with the data and guarantees needed for automated participation, is necessary to unlock these new sources of supply while preserving decentralization and network integrity. This positions Livepeer to meet growing real-time AI demand and continue evolving as open infrastructure for AI media at global scale.<h2>2. Outcome</h2>Overall success is when Livepeer has a validated, repeatable onboarding model for professional compute participation. Providers can dynamically contribute and reclaim idle GPU capacity using familiar orchestration frameworks (e.g. Kubernetes), making large-scale, reversible participation practical. As a result, Livepeer unlocks new sources of high-quality compute supply, strengthening the network’s ability to support real-time AI media workloads at global scale.Key Metrics To Measure The Outcome Against<ol><li>Onboarding Model Defined: One or more documented onboarding models suitable for professional compute providers, including how idle capacity can be contributed and reclaimed dynamically.</li><li>Orchestration Compatibility Validated: Feasibility of integrating common orchestration environments used by professional providers (e.g. Kubernetes-based cluster) with Livepeer workflows.</li><li>Provider Readiness Signal: Validation from at least one professional compute operator (e.g. data center or managed GPU cluster) that the proposed onboarding approach meets their operational expectations.</li></ol><h2>3. Requirements</h2>This work should cover the following:<ul><li>A clear and automated way for managed GPU clusters to attach to and detach from the Livepeer network, enabling higher-capacity participants to add and reclaim compute without disrupting ongoing workloads or network operation as demand changes.</li><li>Compatibility with modern orchestration and fleet-management environments (e.g. Kubernetes-style systems), without requiring custom or manual workflows.</li><li>Execution models that provide robust workload isolation (e.g. container- or microVM-based assumptions).</li><li>Availability of the runtime and performance signals needed to automate participation and capacity decisions.</li><li>A concise description of how higher-capacity compute can participate in Livepeer without compromising decentralization or network integrity.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Enable High-Scale Compute Participation

Author: Rick Staa, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>As Livepeer’s protocol and security foundations mature, long-term trust in the network depends on progressively decentralizing critical security and governance responsibilities. While the Security Committee has played an essential role in safeguarding the protocol during earlier phases, its responsibilities should increasingly transition to transparent, community-driven stewardship as the ecosystem grows.Publishing a decentralization roadmap provides clarity on how this transition can occur responsibly over time. It aligns stakeholders around shared expectations, preserves protocol safety, and reinforces Livepeer’s commitment to decentralization as a core principle, building on the operational security foundations established in prior roadmap initiatives.<h2>2. Outcome</h2>Overall success is the publication of a clear, phased roadmap describing how Security Committee responsibilities could be progressively decentralized to the broader community. The roadmap outlines key responsibilities, risks, and trade-offs, and proposes an approach for community consultation and gradual implementation beginning in a future phase. This creates shared understanding and a credible path toward more decentralized protocol governance without compromising security.Key Metrics To Measure The Outcome Against:<ol><li>Decentralization Roadmap Published: A publicly available, phased roadmap for decentralizing Security Committee responsibilities.</li></ol><h2>3. Requirements</h2>This work should cover the following:<ul><li>Research and summarize comparative governance and security committee models.</li><li>Assess risks and constraints specific to Livepeer’s protocol and ecosystem.</li><li>Define a phased approach for decentralizing Security Committee responsibilities.</li><li>Outline options for community consultation and feedback.</li><li>Identify potential milestones or decision points for future implementation.</li><li>Produce a clear, accessible roadmap document describing findings and recommendations.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Publish Security Committee Decentralization Roadmap

Author: Rich O’Grady, Livepeer FoundationFunding Mechanism: On-chain Treasury - SPE ProposalSubmission URL: TBDWinning Submission URL: TBDClaimed By: TBD<div data-type="horizontalRule"><hr></div><h2>1. Purpose</h2>The Livepeer network must service larger enterprises to capture the video infrastructure market.To scale significant demand on the network, Livepeer needs to serve enterprise clients that can bring billions of minutes and millions in fees to the network. With improvements made to the core network product from an SLA, compliance and user interface, an enterprise offering is becoming more possible.To get there, the Livepeer network needs to build for real customers. Once we have defined ICPs, spoken to customers to understand needs and upgraded the network product meet requirements, a unified, robust product offering to meet the needs of enterprise customers wanting large-scale video compute.<h2>2. Outcome</h2>The desired outcome of this phase is to operationalize and test an initial enterprise offering with real customers, validating Livepeer’s ability to meet enterprise-grade requirements in practice.This includes onboarding a small group of qualified enterprise design partners, delivering a functional version of the enterprise product (with agreed-upon SLAs, support workflows, compliance assurances, and UI/API improvements), and gathering performance, reliability, and usability feedback based on real workloads running on the network.By the end of this phase, Livepeer should have demonstrated that it can reliably serve enterprise-level compute demand, identified remaining gaps, and refined a repeatable onboarding and service model that can scale to a broader enterprise customer base.Key Metrics To Measure The Outcome Against:<ol><li>Demand / fees on the network</li><li>Number of enterprises onboarded</li><li>Achieve target or near-target SLA performance across uptime, job success rate, latency, and error rate.</li></ol><h2>3. Requirements</h2><ul><li>Build &amp; nurture a pipeline of potential enterprise customers interested in building real-time video AI applications.</li><li>Define clear criteria and a structured plan for selecting and onboarding enterprise customers with a dedicated team.</li><li>Work with new services and</li><li>Specify the scope and capabilities of the trial enterprise offering, including SLAs, support, and UI/API features.</li><li>Outline the technical readiness steps, including infrastructure configuration, monitoring tools, and enterprise-grade security controls for job execution and orchestration.</li><li>Establish a customer success, communication, and escalation process tailored to enterprise users.</li><li>Describe how enterprise workloads are protected, including mechanisms for secure custom job orchestration and confidentiality of models, prompts, and data during execution.</li><li>Provide a measurement framework with specific KPIs, benchmarks, and data-collection methods.</li><li>Commit to and present progress updates and delivery of a final Enterprise Trial Report summarizing findings.</li></ul><h2>4. Proposal Guidelines</h2>Your proposal must include the following in your proposal. Here is a guideline for what we are looking for: <a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.notion.so/Livepeer-RFP-Proposal-Template-2710a348568780efb7b8de39c112e716?pvs=21">Livepeer RFP — Proposal Template</a><ul><li>Company Overview &amp; Capabilities</li><li>Experience and why you are a great fit for this work</li><li>Milestones (with funding amount, timeline, deliverables, demo day for each)</li><li>Outcomes</li><li>Budget &amp; Governance (how funds will be distributed)</li></ul>

Scale Demand Growth With Enterprise Product

Help Center

Improved

Fixed

livepeernetwork

Community Suggestion

Completed

In Review

Seeking Applications

The roadmap is organized into three execution phases that describe how the Livepeer network progresses toward sustained, large-scale demand. Phase 1 focuses on making the network secure, usable, and production-ready. Phase 2 builds on those foundations to drive momentum, scale usage, and convert demand into repeatable growth. Phase 3 represents the network operating at enterprise scale, with the reliability, trust, and capacity required to support long-term real-time video AI workloads.