# Proposal: Demand Growth SPE, Builder Pilot **URL:** \ **Category:** Treasury\ **Created:** [November 3, 2026, 7:25pm UTC](https://forum.livepeer.org/t/proposal-demand-growth-spe-builder-pilot/3386 "2026-11-03T19:25:11Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![honestly\_rich](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.livepeer.org/honestly_rich/32/1381_2.png) [@honestly\_rich](https://forum.livepeer.org/u/honestly_rich)\ **Post date:** [November 3, 2026, 7:25pm UTC](https://forum.livepeer.org/t/proposal-demand-growth-spe-builder-pilot/3386/1 "2026-11-03T19:25:11Z")
**Author:** Rich O’Grady, Livepeer Foundation **SPE Term:** December 2026 to March 2027 **Budget:** $145k ceiling _(working)_ **Date:** 3 Nov 2026 **Community Discussion:** [Roadmap Session 1](https://docs.google.com/document/d/1ARAYARBh6dfxk53fC4N8KGlxLNwKAGNglZQvFrG4AZo/edit?usp=sharing), [Roadmap Session 2](https://docs.google.com/document/d/1v0ib8gSCILXT_fVJQ0vpH1BHMPzRLu2zjSAlECKokig/edit?usp=sharing), [Discord Thread](https://discord.com/channels/423160867534929930/1558044886547304468) ## Abstract The Network Engineering SPE is building a second door to the network alongside the Livepeer Agent: an open, self-sovereign builder stack that developers can build on. This four-month pilot, running from December 2026 to March 2027, opens that door to startups, teams and builders. Its goal is at least 5 teams putting considerable demand through the network, each more than $1,000 in fees and credits by March. A rolling programme that onboards 30 teams is how we find them, backed by $50k of credits, hands-on onboarding, a simple walletless way in built with the Network Engineering SPE, and a $15k retroactive grant pool for the projects that show results. By the end of March, we will know which builders find real value in the network today, and in what. That evidence becomes the roadmap for the next SPE. ## Mission This SPE exists to answer one question: will developers pay to build applications on the Livepeer network, and what value do they get from it that they can’t get elsewhere? It answers it by putting the network in front of real startups and developers, with a simple way in, credits to start and hands-on support, and seeing who stays and pays. The answer matters because independent demand is what will sustain Livepeer for the future, and it tells the community where to invest next. ## Rationale ### Why this SPE? In the vision for Livepeer 2.0, the Livepeer network was described as the open inference network: purpose-built for AI video workloads, designed for the agentic era. With the changes in _A Path to Livepeer 2.0_, its orchestrators will: - serve open models locally; - connect APIs; - provide compute; - run media capabilities that don’t need a GPU, such as layering audio, clipping, captions, resolution changes, overlays and object-aware augmentation. Livepeer Inc’s Agent is one door to the network. It’s built for creators who generate, edit and augment video inside the agent they already use. Another door is being built by the Build Track of the Network Engineering SPE. Its [self-sovereign open builder stack](https://github.com/Cloud-SPE/Network-Engineering-SPE/blob/main/docs/design-docs/self-sovereign-open-builder-stack-draft.md) is a shared, open-source engine that handles what every application needs (finding capabilities, checking prices, running jobs and tracking cost) through an HTTP API and MCP interface. Teams can run it themselves or use a hosted option, without holding crypto, on infrastructure they can run themselves. With a second door opening, the question is who walks through it, and why. We don’t yet know who will build on the network and pay for it outside the Agent: whether for cost, the breadth of models and media capabilities, openness, or something not yet named. None of these has been tested with independent startups or developers. Without payment abstraction, meaningful outreach to new customers isn’t possible. Building on a new network costs time and money before customers pay, orchestrators can’t see demand coming, and on an open network the numbers are hard to trust. ### How this SPE will test it 1. **Get 5 teams putting considerable demand through the network.** The goal is at least 5 teams each putting more than $1,000 in fees and credits through the network by March. Support is concentrated on the teams with the most demand: priority onboarding, credits up to the top tier and the capabilities their workloads need. 2. **Run a programme to find them.** From January, projects join each month and are onboarded hands-on with credits. Onboarding 30 teams is a means to an end: a funnel wide enough to find the 5 that go deep. The rules will be set in December. 3. **Find teams building in video and media.** Focused outreach finds individuals and teams who need compute for video and media work, with a focus on builders new to Livepeer, and brings them into the programme. 4. **Reward results, not pitches.** A $15k retroactive grant pool goes to projects that have already put real usage through the network, selected by an Orchestrator Panel of five. There are no upfront cash grants. 5. **Give projects a simple way in.** Built with the Network Engineering SPE and a clear onboarding surface where builders or their agents get an API key and make a first call within 5 minutes, with or without a wallet, with tested docs and public dashboards (exact product decisions are made in December.) 6. **Fund usage with up to $50k of credits.** Credits are released when a project is admitted, up to the maximum for its tier; projects then pay a growing share. Pymthouse, rebuilt on the Build Track’s builder engine, processes payments and credits for the walletless route; projects that self-host their clearinghouse receive credits there. Every credit settles on-chain as network fees. ### What we will know by the end of March - which builders find real value in the network today, and in what; - which uses turned into paying demand, and kept paying as credits tapered; - why builders chose the network, or left it; - what the network has to fix to serve them. ### What this SPE leaves out - **Upfront cash grants.** Projects get credits, spent only as network fees. The only cash is retroactive, for projects that have already shown usage. - **Building the product.** The builder engine, onboarding surface, docs and dashboards are built and supported by the Network Engineering SPE. - **Running capacity.** This SPE funds demand-led capacity but doesn’t run it. The Operate Track manages supply and capacity: it spends only when a programme customer needs GPUs. - **A single official route.** A console will be the the easiest way in, not the only one; projects can self-host their clearinghouse or use the network permissionlessly. - **Picking winners.** Many projects try the network; retroactive grants and the evidence decide what is worth backing next. ## SPE Governance Structure ### Tracks The pilot runs on three tracks. Each track has its own KPI, all pointing to the same goal: 5 teams each putting more than $1,000 through the network by March: | Track | Funded and led by | What it covers | KPI | | --- | --- | --- | --- | | **Programme Management** | This SPE: $30k; selected by RFP | Runs the programme day to day: finding teams, onboarding, and driving awareness, concentrating support and credits on the teams with the most demand, feeding capacity needs to the Operate Track, case studies and monthly reporting | 5 teams each putting more than $1,000 through the network; 30 teams onboarded as the pipeline | | **Build Track** | Network Engineering SPE; led by Mike | Stewards the credits platform and onboarding infrastructure: payment abstraction, the onboarding surface, product decisions in December, docs, dashboards and the credits ledger, and hands-on technical integration. Links what the network runs to something companies can use. | Onboarding surface live by 15 January; sign-up to first call in 5 minutes. | | **Operate Track** | Network Engineering SPE; led by Josh | Orchestrators and supply. Under a new allocator design, orchestrators can dedicate GPUs to specific demand. Keeps orchestrator docs and onboarding simple, runs the orchestrator feedback loop, and provides demand-led capacity. Growth-focused rather than engineering-focused. | Supply matched to each programme customer’s demand | Alongside the tracks, there will be two additional functions within the SPE: **SPE Lead.** Seeks the mandate from the community, holds the track owners accountable, and selects the Orchestrator panel and the RFP. Currently overseen by Rich O’Grady at the Livepeer FOundation. **Orchestrator Panel.** Five orchestrators who select the $15k of retroactive grants and guide the decision on the RFP. ### Who this SPE works with - **Network Engineering SPE.** Funds and runs the Build Track and the Operate Track, which deliver the programme’s product and supply. - **Pymthouse.** The payment and credits processor that runs the console and the walletless route. It holds only the credits released to it for projects on that route. - **Livepeer Foundation.** Stewards the SPE’s treasury and contracts Pymthouse. ### Decision rights | Decision | Who proposes | Who reviews | Consulted | | --- | --- | --- | --- | | Programme rules, credit tiers, maximum and taper | Programme Management | SPE Lead | Pymthouse | | Admit a project to the programme | Programme Management | SPE Lead | Build Track | | Release credits to clearinghouse | Build track | SPE Lead | Foundation | | Demand-led capacity | Programme Management | Operate Track | SPE Lead | | Builder experience: scope and priorities | Build Track | SPE Lead | Programme Management | | Orchestrator Panel members | Orchestrator Panel | SPE Lead | Orchestrator community | | Retroactive grants | Eligible projects | Orchestrator Panel | Programme Management | | | | | | ## Milestones and timeline ### December - **Programme Management:** RFP drafted, posted and winning application selected; programme rules and credit tiers published; Panel of five Orchestrators confirmed; target teams identified. - **Build Track:** Pymthouse contracted; product decisions made; Builder page drafted. - **Operate Track:** orchestrator docs and onboarding updated. ### January - **Programme Management:** 10 teams onboarded; credits released as projects are admitted; first monthly report. - **Build Track:** onboarding surface live by 15 January; docs tested; first projects live. - **Operate Track:** capacity plan for the first programme customers. ### February - **Programme Management:** 20 teams onboarded; first teams past $1,000; mid-point review. - **Build Track:** dashboards and credits ledger live; blockers triaged into fixes. - **Operate Track:** orchestrators dedicating GPUs to programme demand through the allocator (exact details tbd). ### March - **Programme Management:** 5 teams over $1,000; 30 teams onboarded; retroactive grants selected. The SPE Lead completes the value proposition review and roadmap by the end of March. - **Build Track:** all projects live within 14 days; docs and dashboards updated. - **Operate Track:** plan to hand demand-led capacity to orchestrators. ### Where this pilot is most likely to break Some risks and mitigations that the SPE needs to be indful of: 1. **The Network Engineering SPE renewal doesn’t fund the Build and Operate Tracks’ programme work.** Both are committed in its December renewal before this SPE’s vote. If that slips, then the remaining funds in the Network Engineering SPE will be dedicated purely to the Operate and Build tracks. 2. **Payment abstraction isn’t ready and fees can’t be told apart from credits.** Pymthouse is part of the January readiness check; fiat and KYC compliance can follow later. Every clearinghouse that receives credits reports paid and credit-funded fees separately each month: Pymthouse directly, and self-hosted projects as a condition of receiving credits. 3. **Network isn’t ready.** The onboarding surface and Pymthouse depend on the Build Track’s builder engine and runtime being ready for 1 January, and on enough capabilities being live to build on, including those the Agent brings online and Mike’s BlueClaw workloads. There will be a readiness check with the Network Engineering SPE and the programme starts only when it is passed. 4. **Too few teams go deep or hit problems and leave.** Outreach aimed at teams with real compute needs in video and media, a funnel of 30 teams, and support concentrated on those with the most demand. Also have hands-on onboarding from the Build Track, the capacity they need from the Operate Track, and weekly priorities that turn blockers into fixes. 5. **Conflicts of interest between SPE members and builders** Conflicts are disclosed, and admissions and credit releases are published in the monthly report. 6. **Credits are spent without real usage.** Credits released per admitted project, a maximum per tier, a taper, a published definition of “active”, abuse controls and on-chain settlement. ## Budget Breakdown **Total:** $145k from December 2026 to March 2027, requested at the 30-day moving average LPT price. | Line | What it covers | Amount | | --- | --- | --- | | **Programme Management** | Finding teams and running the programme, December to March; selected by RFP. | $30,000 | | **Credits** \* | Released to clearinghouses as projects are admitted, up to a maximum per project. | $50,000 | | **Pymthouse operation** | Running payments and credits processing for the walletless route. | $10,000 | | **Demand-led capacity** | Spent only when a programme customer needs GPUs, through the Operate Track: temporary, open and handed to orchestrators once demand is proven. Exact shape is tbd | $20,000 | | **Retroactive grants** | Selected by the Orchestrator Panel for projects that have shown usage. | $15,000 | | **Contributor Fund** | Working with additional contributors where necessary, released by the SPE Lead. | $20,000 | | **Total** | | **$145,000** | **Funded by the Network Engineering SPE:** the Build Track and the Operate Track, as part of its December renewal. **Treasury and custody.** The SPE’s treasury is stewarded by the Livepeer Foundation, which holds and releases funds against the budget. **Credits management.** Credits stay in the SPE treasury until released. Any not spent roll over to the next SPE. When a project is admitted, credits are released to its clearinghouse up to the maximum for its tier, then topped up against usage on an established cadence. Pymthouse receives only what the walletless route needs. ## Measuring Success ### Deliverables 1. At least 5 teams each putting more than $1,000 in fees and credits through the network. 2. A rolling programme with published rules and 30 teams onboarded as the pipeline. 3. At least $10k of retroactive grants selected by the Orchestrator Panel. 4. At least $20k of credits released to clearinghouses as projects are admitted, with Pymthouse processing the walletless route. 5. A review of the network’s value proposition, projects worth exploring next, and a roadmap for the next SPE. ### KPIs, as evidence for the review - **Traction:** 5 teams each putting more than $1,000 through the network (Programme Management). This is the headline measure. - **Demand:** $5k in fees paid by projects themselves (net of credits), with a stretch goal of $10k. - **Pipeline:** 30 teams onboarded to the programme (Programme Management). - **Network Engineering SPE commitments:** onboarding surface live latest by 15 January with the ability to match demand with supply. ## Transparency and Accountability - **Programme rules** published in December, including what counts as an “active” project. - **Monthly report and forum post:** projects, usage, credits released and spent, fees net of credits, and progress for each track. - **Public dashboard and credits ledger,** updated weekly, with data from Pymthouse and self-hosted projects’ reporting. - **Retroactive grant decisions** published with reasoning; Panel members step aside on any project they have a stake in. ## Key Terms **Builder.** A startup, team or developer building on the Livepeer network. **Onboarding surface.** The console, docs and Builder page where builders or their agents get an API key and go. **Clearinghouse.** The service that handles payments and holds released credits for a project: Pymthouse, or the project’s own. **Pymthouse.** The hosted clearinghouse: payment and credits processor that runs the walletless route. **Active project.** A project putting credits through the network each week, as defined in the programme rules. **Retroactive grant.** Cash awarded after a project has shown real usage, never upfront. **Network fees net of credits.** Fees projects actually pay themselves, excluding the share covered by credits. ## Open questions - **Network Engineering SPE renewal:** funding and scope for the Build and Operate Tracks’ programme work, agreed before this SPE’s vote. - **Product decisions:** the scope and priorities of the builder experience on the website and Pymthouse, made in December. - **Readiness check:** what level of network readiness must be live for the programme to start. - **Programme rules:** tiers, maximum per project, taper and the definition of “active”, set in December. - **People:** Programme Management selected by RFP in late November or early December; and who sits on the Orchestrator Panel. ## Thank you, and over to you This pre-proposal has been shaped by many people: those who joined the roadmap sessions, added comments in the docs and pushed back on Discord, and the contributors, orchestrators and Network Engineering SPE leads who gave their time to test the thinking. Thank you to you for all your work. Before it goes to a vote, I’d welcome detailed feedback, especially on: 1. **The goal:** is 5 teams each putting more than $1,000 through the network the right test of whether builders find real value here? 2. **The budget:** is $145k split the right way across the tracks? And should we be asking for more or less? 3. **The tracks:** are the responsibilities between this SPE and the Network Engineering SPE’s Build and Operate Tracks clear, and is anything missing? 4. **The risks:** what have we missed, and are the mitigations strong enough? Please reply in this thread, or reach out to me directly if you’d rather talk it through. The more specific the feedback, the more useful it is. Thank you in advance.