Proposed by: Rich O’Grady, Ecosystem Director, Livepeer Foundation.
Abstract
The Network Engineering SPE funds the work that makes the Livepeer network easier to participate in: builders, orchestrators, delegators and, if 2.0 lands as planned, validators. Round one proved the SPE’s value as a funding mechanism. It also showed that one pool with one technical reviewer and no clear outcomes can lack direction. So round two keeps the mission and changes the shape: four tracks, one named owner on each, one outcome per track to hit by the end of the year, and the capital sitting with those owners rather than being held centrally.
Request: $230,000 USD-equivalent in LPT, 1 Sep to 31 Dec 2026
Preceded by: the Network Engineering SPE pilot, 15 May to 30 Aug 2026, $95,000
Feedback session: Network Engineering Priorities - 11th August
Mission
The mission of the SPE is to make the Livepeer network easy to participate in: easy for all participants to build on, operate, validate and delegate for.
It focuses on the key actors within the Livepeer network:
- Builders - developers, agents and gateways bringing demand to the network.
- Orchestrators - node operators providing capabilities and completing jobs.
- Delegators - staking tokens to Orchestrators to secure the network.
- Validators - validating work completed by Orchestrators (with Livepeer 2.0)
To achieve this mission, the SPE will aim to unite key engineering leaders around one vision, and empower them with capital, talent and programmes. By working with the community, the SPE will give these leaders a clear mandate to remain accountable to, while providing operational support with mechanisms that can fund critical engineering work quickly.
The SPE will divide the work to be done into four tracks. These tracks focus the SPE on four personas, each with its own outcome, a single owner responsible and a set of milestones to achieve it. These owners can be funded by the SPE or receive a salary from another core organisation (e.g. the Livepeer Foundation or Livepeer Inc).
The capital from the SPE is deployed to fund the work to complete these milestones through a variety of mechanisms (RFPs, grants, bounties, fixed contracts). After discussing this in a recent feedback session, the SPE will use a variety of funding mechanisms to ensure that we find the right person for the right task at the right cost.
Rationale
What’s changed from the pilot SPE
This Network Engineering SPE will be structured differently from the pilot.
The pilot SPE structure was focused on three directional priorities with a combined pot for RFPs and grants (direct or retroactive). This model had a great deal of flexibility baked in. However, it (a) lacked concrete outcomes or goals that were clearly set at the beginning; (b) had a review bottleneck with the Technical Director; and (c) did not have strong enough accountability. See the full retro here.
This SPE is structured differently. It splits the work into four tracks, each around a core ecosystem stakeholder: Builder, Orchestrator, Delegator and Validator. Each track then gets one owner, one outcome by the end of the year, and a budget the owner controls.
The owner is on the hook for the outcome. They can route the funding allocated to other contributors to complete the work.
Four new tracks to focus work
The four tracks are places where our claim to be an open network still falls down in practice:
| Track | Owner | Outcome by 31 Dec |
|---|---|---|
| Easy to build Builder |
Mike Zupper | A developer can go from a clean machine to a working, paid call on the Livepeer stack using only the published documentation, without contacting an operator. Both payment paths work: funding from a wallet by default, and Pymthouse for anyone who does not want to hold one. |
| Easy to operate Orchestrator |
Josh Allmann | Livepeer has a network substrate that connects demand to supply end to end, where new capabilities can be introduced without building a new integration stack each time, with enough observability to gauge performance and diagnose issues, and every capability is discoverable with clear pricing by an application. |
| Easy to delegate Delegator |
Elliott Conway | Make self-custody delegation clear, competitive and economically informed for Livepeer 2.0, so delegators understand their rewards and can identify when moving stake may improve them. Success primarily means improving journey conversion and ultimately delegation volume, provided upstream interest does not decline. |
| Easy to validate* Validator |
Shane Burgett | Self-dealing and gaming Livepeer tokenomics are expensive and untenable, with the network protected from token exploitation through a combination of economic levers, network data and social consensus through a new class of participant, Validators. Lead testing of methods to further validate work on the network, protecting users from dishonest or low-quality operators. |
*We do not yet know whether validation means a full validator set with on-chain scoring, or existing participants carrying an extra responsibility. The shape of this track therefore has licence to change depending on how it evolves.
How funds reach contributors
For this SPE, owners will pick the mechanism per task. Different mechanisms can be used depending on whether the work is defined, a contributor has been identified, or the price of work still needs to be determined.
This decision emerged out of the roadmap session from August 11th, where community members suggested that there was no need to over-index on one or two mechanisms.
The suggested mechanisms that could be used are:
| Mechanism | When an owner reaches for it | Funding amount |
|---|---|---|
| RFP | Scope is clear but the right contributor is neither in the network nor known to us. | $5,000 to $30,000 |
| Direct grant | Scope is clear and the builder is obvious. Paid against milestones. Moved the most capital last round. | Up to $20,000 |
| Retroactive grant | Work has already shipped against a problem the community named publicly first. | Up to $10,000 |
| Scoping grant | The work cannot be specified yet, and specifying it is the deliverable. New this round. | Up to $5,000 |
| Bounty | Small and self-contained, worth opening to anyone. Spendable directly by a committee member, no application path. | $500 to $2,000 |
| Fixed contract | Sustained ownership of a surface over 2 to 4 months, with milestones set by the track owner. | $5,000 to $40,000 |
What this SPE isn’t
- Not funding the agent framework. The Livepeer agent will be funded separately, across Inc, the Foundation and the treasury.
- Not a demand generation or credits fund. Go-to-market and end-user product work will sit within another SPE proposal coming soon.
- Not protocol design. Livepeer 2.0 is designed and voted on elsewhere. This funds getting the people already here across to it.
- Not an open-ended pool. Every disbursement needs a verified definition of done.
SPE Governance Structure
Roles & responsibilities
| Role | Who | Responsibilities | Paid by SPE |
|---|---|---|---|
| Chairperson | Rick Staa | Ensures code reviews are completed in a timely fashion. Rules on architectural decisions that cross track boundaries where owners cannot agree. | No, paid by the Foundation |
| Committee | Rick Staa, Josh Allmann, Elliott Conway, Mike Zupper, Shane Burgett | Sets each track’s outcome, defines and reviews milestones, signs off and merges code, decides allocations brought by another member | Three of four, as track owners |
| Track owner | Josh Allmann, Elliott Conway, Mike Zupper, Shane Burgett | Presents three to five milestones, allocates the track budget, picks the mechanism per task, brings in contributors to do the work | $20,000 each, where not already paid by Inc or the Foundation |
| Foundation Operations | Rich O’Grady, Ben Perez, Mehrdad Sadeghi | Programme management, bringing in new contributors, treasury and payment operations, monthly reporting, final sign-off on release of funds. Buys in independent review per task so payouts do not queue behind one calendar | No, though bought-in review is paid from the bounty pot |
Committee operations
- Voting. When a member brings an allocation, a sign-off or a scope change forward, there is a simple majority vote. Where a committee member is absent, a Foundation Operations team member will step in so a decision is never held up by a diary. The Foundation Operations team also holds the final gate on payment and releases funds only once the definition of done is verified.
- Code review. Review is a named committee responsibility: every contribution funded by this SPE will aim to receive an approval or a rejection with reasons within a month.
- Conflicts of interest. We will introduce a rule that a track owner may direct no more than 50% of their own track allocation to themselves or to an entity they control. It will also be disclosed on the forum when it happens, with the member recused and Foundation Operations releasing the funds. Any contributors paid by the Foundation or Livepeer Inc will not receive further compensation from the SPE.
Timeline & Milestones
SPE Timeline
1st September - Track milestones finalised. Each track owner has finalised their respective milestones (see below).
8th September - SPE proposal passed. Funds secured, weekly committee meeting running and payment operations set up.
29th September - First monthly update published. Published on the forum, covering work funded and delivered per track, funds committed and disbursed, code merges and every committee decision with its rationale.
20th December - Retro completed. Each track assessed against its outcome, total spend against budget, and a recommendation per track: continue, change owner, or stop. Community session held alongside it.
Milestones
Each track will have its own milestones, which will be tracked and reported on by their respective owners. These will be developed before the proposal goes onchain.
For this pre-proposal, there are some directional commitments tied to the outcomes detailed above. These are per track:
Easy to build
• First call works without a wallet or setup
• Clients can discover, price, pay for and invoke services through standard interfaces
• Payments and metering work across supported service types without bespoke integration
• You can see what a job costs, before and after you run it
• Docs and SDK match what’s actually deployed.
Easy to operate
• Live Runner covers the operator path end to end
• Discovery path for capabilities, hardware, pricing, etc
• Operators can determine why a job failed, including failures outside their control
• A capability can be onboarded self-serve and validated before deployment
• There is a credible path from today’s network architecture to 2.0
Easy to delegate
• Delegators and node operators can understand reward history and why rewards changed
• Validator activity, scores and health are understandable if Validators 2.0 proceeds
• Core delegation terms and actions become clearer: rewards, fees, risks, unbonding, delegation, switching and exit
• Funnel conversion is measurable against a baseline so changes can be evaluated
• If MFS is adopted, delegators can see which nodes out- or under-earn relative to stake, and where moving stake could unlock more rewards
Easy to validate
• Validators act as guardians, with mechanisms to protect Livepeer’s economics
• LPT is protected from exploitation: self-dealing and tokenomics gaming
• Token exploitation is visible in network data, and the community has the evidence it needs to act
• Real testing has begun on the long-term challenge: validating the work itself, protecting users from false data and low-quality work
Note: In the coming days, formal milestones will be defined for each track. The aim is to publish these in time for the final proposal, once we have received feedback from the community.
Budget Breakdown
$230,000 USD-equivalent in LPT for one four-month cycle, sized on the 30-day moving average LPT price at approval.
Budget Overview
| Line | Allocation | What it funds |
|---|---|---|
| Track owner, Validate | $20,000 | Accountable ownership and delivery of the Validate outcome. ~15 hours/week, 4 months. |
| Track owner, Delegate | $20,000 | Accountable ownership and delivery of the Delegate outcome. ~15 hours/week, 4 months. |
| Track owner, Build | $20,000 | Accountable ownership and delivery of the Build outcome. ~15 hours/week, 4 months. |
| Build track, contributors | $50,000 | SDK, payment clearinghouse, service registry and schema contract, discovery, docs and capability templates, metering and spend transparency |
| Operate track, contributors | $30,000 | Operator tooling, diagnostics and real job state, Live Runner developer experience, capability supply, migration tooling and the 2.0 upgrade path |
| Delegate track, contributors | $20,000 | Explorer delegator experience, lockup transparency, staking guidance, subgraph engineering, including audit remediation, and research into what 2.0 changes for delegators |
| Validate track, contributors | $30,000 | Provisional, released only if the track activates |
| Bounties, grants and research | $20,000 | Cross-track work no single track owns: a bounty pot spendable directly under a per-item cap, scoping grants, retroactive grants, and bought-in review |
| Buffer | $20,000 | Held against LPT price movement, so a falling price is not a pay cut mid-milestone |
| Total | $230,000 |
Budget Notes
- Reallocation between tracks is possible at the end of each month with a published decision.
- A track owner works inside their allocation and brings anything larger to the committee.
- A track owner may direct no more than 50% of their own track allocation to themselves, using established milestone-based mechanisms (e.g. grants or bounties).
- No contributors funded by Livepeer Inc or the Livepeer Foundation will receive further funding from the SPE.
- The three track owners for Validate, Delegate and Build will each be compensated with a fixed contract of $5,000 per month. Payments can be withheld for extreme neglect of their role.
- Payouts in LPT at a 7-day average price at the point of payment.
- We will manage the treasury position on receipt rather than sitting on $230,000 of LPT for four months, so contributors get what they were promised whatever the price does.
- Anything unspent carries over to the next round, or goes back to the treasury if there isn’t one. Incomplete work at 31 December gets a short remediation window first.
Transparency and Accountability
- Monthly written updates on the forum: work funded and delivered per track, milestones signed off and missed, funds committed and disbursed against allocation, and every committee decision with its rationale.
- A public per-track financial record of allocation, commitment and disbursement, updated monthly rather than reconciled at the end.
- Every conflict disclosed at the point of the decision, with the recusal published.
- Every self-allocation by a committee member published against the 50% cap and reviewed by the committee.
- A closing retro and community session by 20th December.
Key Terms
- Track. A body of work built around one core ecosystem stakeholder, with one owner and one outcome.
- Foundation Operations. The Foundation team running programme management, payments and reporting, and holding the final gate on releasing funds.
- Builder. Anyone building on the network: developers, agents and gateways putting work through it.
- Orchestrator. An operator running hardware that serves jobs on the network, also referred to as an operator.
- Delegator. Someone staking LPT to an orchestrator and earning a share of their rewards and fees.
- Validator. Under 2.0, a participant that independently checks and scores what the network did. Whether that is a new role or an existing one carrying an extra responsibility is not yet decided.
- Payment clearinghouse. The auth and billing layer that lets a client pay for network work without using a crypto wallet.
- Live Runner. The runtime an orchestrator deploys to serve capabilities on the network.
- Capability. A specific job type an orchestrator advertises and can be paid to run.
- Passthrough. Serving a capability by routing it to a third-party provider rather than running it on your own hardware.
- Service registry. The single place capabilities, hardware and pricing are advertised so a gateway can discover and price them.
- Subgraph. The indexed on-chain data that feeds the Explorer, console and dashboards. Not real-time, and not used for orchestration.
- Explorer. The public interface where delegators and orchestrators stake, vote and see network activity.
CTA: Please Give Your Feedback
We want to ensure that we are funding network engineering that is valued by the community. Much of what is included above is based on the feedback of the community within the roadmap session from August 11th. We also know that there are some blind spots.
We want to move fast. But we also want to get this right. We therefore ask you to give feedback on:
- Focus - have we chosen the right tracks and outcomes, and included the right work?
- Budget - have we over- or under-budgeted for the work that is at hand?
- Governance - what can we do to improve the governance structure of the SPE?
Thanks in advance for your feedback, questions and ideas.
