Proposal: Network Engineering SPE

Proposed by: Rich O’Grady (Co-Director, Livepeer Foundation) and Rick Staa (Technical Director, Livepeer Foundation)


Abstract

The Network Engineering SPE is a delegated pool of capital that funds scoped engineering RFPs and retroactive contributor grants, without requiring a standalone on-chain proposal for each initiative. The mission of the SPE is to fund smaller engineering initiatives to make the Livepeer network more observable, performant, and developer-centric. It targets the $2k–$20k range of work that the current SPE process makes too slow to fund. We’ve seen this model work: the Explorer upgrade proved what a vetted contributor with a clear scope and accountable oversight can deliver. This SPE scales that, while exploring a more retroactive model.

Requested duration: 3 month (pilot program) + 2 weeks (retro)

Requested budget: $95,000 USD-equivalent in LPT


The Problem

The Livepeer project needs the ability to execute fast and targeted actions to support users, operators and builders on the network. The current SPE model works well for large, multi-month programmes. It doesn’t work for the $2k–$20k engineering work the network often needs.

The friction is structural:

  • A full SPE proposal requires significant time before any work begins
  • On-chain vote cycles add weeks of delay — often longer than the work itself
  • As AI tooling compresses build cycles, this gap is getting worse, not better

The result: well-supported, clearly-needed work goes unfunded — not because the community doesn’t want it, but because there’s no efficient path to fund it.

This was validated by three public community discussions (March–April 2026) with strong consensus. The Water Cooler on 13 April returned a clear signal: move forward.


The Solution

The aim of this SPE is to build a delegated funding pool with a fast, accountable process which funds critical engineering work fast. This would sit alongside the formal SPE process, which primarily focuses on longer-term (3+ months) initiatives.

This SPE replicates and scales that model across two funding tracks: RFPs dividing up known work and distributing it amongst the community; and retroactive grants funding for work that has already been completed.

Note: Retroactive Grants don’t necessarily go through the Roadmap process.

Eligibility Areas

For the first round of SPE funding, there will be 3 primary focus areas, which are focused on Livepeer’s core stakeholder groups, each with different needs:

Priority 1: [Developers] Developer Portal — The 5-Minute API — Work on the Developer Portal’s critical path: the engineering that takes a developer from docs to first inference call in under five minutes, from any MCP-compatible tool. This includes the Python SDK, BYOC container tooling, payment and auth infrastructure, agentic harness tooling, and any library or scaffolding that removes onboarding friction.

Priority 2: [Delegators] Explorer — Participation & Observability — Work that makes the Explorer a better permissionless participation portal for operators and delegators. This includes staking interfaces, governance participation features, network observability dashboards, and tooling that surfaces real network behaviour to support informed decision-making.

Priority 3: [Orchestrators] Tooling & Infrastructure — Work that helps orchestrators run more reliably, scale capacity, and integrate with the evolving SDK-first architecture. This includes containerisation, orchestration tooling, runtime improvements, go-livepeer contributions, and infrastructure that affects network reliability and operational experience. Note: that this area requires particularly strong community validation before an RFP is promoted

Funding Track 1 — RFPs (~$5k–$20k, 2–8 weeks)

Full proposed process: RFP Process - Network Engineering SPE

Community members post Roadmap Suggestions on the forum, where the suggester drafts initial requirements and deliverables with the community - facilitated by the Livepeer Foundation. After an initial community validation via Discord, the Foundation then publishes a finalised RFP for contributors to apply to, and assigns it to a selected team or contributor within 7 days.

All decisions and disbursements are published with written rationale. Payment is split across three tranches: 25% on signing; 50% on delivery and verification by Review team; and 25% on impact paid at the end of the pilot (in August). Any incomplete work or assessments at the end of the pilot triggers a brief remediation window.

Three Suggestions have already been initially identified and will be scoped with community contributors and then validated by the community to become (or not become) RFPs:

Funding Track 2 — Retroactive Grants (<$5k, retroactive)

Full proposed process: Retro Grants Funding Process - Network Engineering SPE

Build first, then apply. Contributors post a public application on the forum after the work has shipped. The Review Team reviews on a monthly cycle and publishes an approve, partial approve, or decline decision with written rationale. Approved grants are paid in full in a single disbursement.

The primary bar is impact, not completion. Each application must name the problem, who had it, and who is already using the solution. Describe what was built, link to the work, and state the amount requested. Projected usage does not count.

Examples of eligible work and impact:

  • OpenRouter integration — 5 developers discovered and integrated with Livepeer via OpenRouter.
  • Live video-to-video / BYOC full-stack runner — 3 community members running live video-to-video with BYOC end-to-end — a workflow the network had no viable path for before this.
  • Agentic harness tooling — 3 Livepeer solutions cutting time-to-working-agent-loop from days to hours using standardised scripts, tool definitions, and prompts.

Quantifying Impact

Impact means the network becomes more observable, more reliable, or more easy-to-use for Developers, Delegators or Orchestrators. The concrete impact signals that the Review team will look at are all about usage and adoption:

  • Named adopter — a specific person or team outside the author is using it in their own work.
  • Downstream dependency — another project or contributor is building on top of it.
  • Capability confirmed in the wild — someone who wasn’t involved in the build has run it successfully.

It is also expected that the work is maintained and still live by the end of the program. What impact is not: download counts, repo stars, or the builder using their own tool.

What This SPE Isn’t

Not a demand generation fund (coming soon). The Network Engineering SPE funds the engineering substrate: the infrastructure that makes demand solutions like Daydream, Frameworks, Blueclaw, Streamplace possible. Go-to-market, marketing, and end-user services are out of scope.

Not an open-ended bounty pool. Every disbursement requires a verified definition of done. Work must be complete, reviewable, address a recognised need and have verifiable impact.

Replacing the SPE Process. For larger pieces of work network engineering (e.g. 2+ months with multiple contributors), the onchain treasury process will still be used.


SPE Governance Structure

Custody: Funds held by the Livepeer Foundation.

Decision process: All decisions made live in weekly Review Team meetings via a simple 2-of-3 vote, with a written decision log published after each meeting. Any Review Team member with a direct financial interest in a decision must recuse.

Role Who Responsibilities Paid by SPE?
Review Team Lead & Technical Director Rick Starr (Livepeer Foundation) Refines scope of RFPs with Suggester; leads RFP team selection; signs off on technical quality for all RFP Track 1 work - sole gate on technical delivery, no broader Review Team vote required; produces pilot evaluation report No
Reviewer, RFPs TBD — Nominated by Orchestrators. Selected by Review Team Lead. Reviews and scores RFP applications against evaluation criteria; represents community interests in first-pass scoping; casts an independent vote on Tranche 2 and Tranche 3 payouts; publishes written rationale for any dissent or recusal Yes ($7,500 / 3 months, ~10 hrs/week)
Reviewer, Retro Grants TBD — Nominated by Orchestrators. Selected by Review Team Lead. Owns first-pass review of retroactive grant applications against the published rubric (supported by AI pre-screening); triages and quality-screens incoming applications; compiles monthly review shortlist; proactively surfaces strong unsubmitted community work; casts an independent vote on retroactive grant approvals Yes ($7,500 / 3 months, ~10 hrs/week)
Roadmap Manager Rich O’Grady (Livepeer Foundation) Facilitates community Suggestion sessions; manages the Suggestions pipeline; promotes validated ideas to the roadmap; signals funding path per item No
Program Manager Mehrdad (Livepeer Foundation) Runs and records weekly Review Team meetings; maintains the public decision log; tracks milestone status; manages remediation windows No
Contributors Community Deliver scoped outputs with full ownership and accountability Yes

This SPE will have AI-native workflows embedded from day one, reducing Review Team overhead, keeping the public record current, and ensuring consistent quality control without manual lift.

AI-led tasks include: retro grant pre-screening; automating meeting notes and updates; decision log drafting; application triaging.


Timeline

15 May 2026 — Funding Programs Live

Review Team seated. Weekly cadence established. First 3 RFPs posted publicly. Retroactive grants open. Public tracker live. Key assessment: did we launch on time with the right scope?

30 Jun 2026 — First Deliveries Verified

At least 1 RFP delivered. At least 1 retroactive grant awarded. Key assessment: is the quality bar holding? Is the 14-day selection target being met?

30 Aug 2026 — Pilot Complete

Minimum 3 RFPs delivered, with aspirational goal of 5. All impact assessments done. All spend published. Evaluation report out with a clear recommendation: continue, modify, or stop.


Budget Breakdown

Total requested: $95,000 USD-equivalent (4-month pilot)

Budget line Assumption Amount (USD-equiv.)
Review Team Member compensation (×2) 2 × $7,500 / 3 months (~10 hrs/week) $15,000
Track 1 — RFP pool Aim: 3 RFPs over pilot at ~$15k average $45,000
Track 2 — Retroactive Grants pool Aim: 5 retroactive grants at ~$3k average $15,000
Funding Buffer — for additional grants or RFP To either be allocated, returned to the onchain treasury or carried over to future SPE $20,000
Total $95,000 (in LPT)

If uptake for RFPs and/or retroactive grants are lower than expected at the 30 June checkpoint, the Review Team has the opportunity to reallocate between pools based on where community activity is strongest.

Any unspent funds or incomplete RFPs at pilot end are returned to treasury (with a small undefined, remediation window if work near completion).

All amounts sized using the 30-day moving average LPT price at the time of RFP approval.


Deliverables

Pilot success criteria (3 months):

1. Minimum 3 RFPs reach verified impact - At least 3 scoped engineering RFPs complete with a confirmed definition of done, verified by the Technical Director and community Review Team Members. Each delivery is published publicly with a written rationale and outcome assessment.

2. Minimum 5 retroactive grants funded - At least 5 retroactive grant applications reviewed and awarded, covering work that has already shipped and meets the published rubric. Each award is published publicly with written rationale, the amount approved, and the impact evidence submitted by the contributor.

3. Three public SPE updates published during pilot - One per month (June, July, August). Each update covers: RFPs active and delivered, retroactive grants reviewed and awarded, funds disbursed to date, and Review Team decisions with written rationale. Published within 7 days of the monthly Review Team meeting. Zero black-box decisions.

4. Pilot evaluation & impact report published by 30 Aug 2026 - A concise report covering: RFPs funded and delivered, retroactive grants awarded, total spend vs. budget, community signal on delivered work, and a clear recommendation: continue, modify, or stop. Written for a community audience, not an internal one.


Transparency and Accountability

  • Every RFP and retroactive grant decision published publicly with written rationale.
  • Public tracker RFPs: all RFPs, status, funds allocated and disbursed, Review Team decisions
  • Public tracker grants: all retro grant applications, decisions, amounts awarded, and impact evidence
  • Review Team Members publish justification for any overrule or recusal
  • Monthly written reporting to the community (per SPE norms) plus update at Water Cooler
  • All conflicts of interest disclosed and recused
9 Likes

The proposal is making again available microgrants into the ecosystem; It was structured according to what was originally intended for SPEs, as worded in LIP-90: Treasury proposals should be made by Special Purpose Entities, or (SPEs), that will themselves be responsible to routing the funding towards individual end-recipients or purposes. End recipients should not apply directly to the Livepeer treasury for funding.

The Livepeer Foundation did put a lot of thought and effort in the proposed solution, and I think it’s a step towards the right direction. Grants dispensed from the pilot phase could act as the cornerstone of an effort that brings new talent into Livepeer - for that reason the only low level suggestion I have is to designate the majority of the funds towards talent outside of the Livepeer instead of existing contributors.

5 Likes

Thanks Rich for the work !

The problem is clear and the structure looks solid.

One small thing from my orchestrator view. The proposal mentions that demand generation is out of scope and will come in a separate SPE later. It would have been nice to see both presented together, just to get a clearer picture of how tooling and demand evolve together. Any idea of when the demand gen SPE might land? Would love to see the two move in parallel.

Otherwise fully supportive, happy to see this move forward. :folded_hands:

5 Likes

I’m fully supportive of this SPE and treasury funds usage for retroactive funding.
Tooling is important, but as has mentioned, I would also love to see with demand gen SPE working together with tooling.
Another thing is, I’m not sure about the proposed commitment for reviewers. Is there a need for a 3-month 10-hour-a-week commitment? Are there enough applications to justify that time?
Happy to see that there are some applicants for funding already!!!

2 Likes

Hi everyone, thanks for the feedback thus far. To respond to the key parts of each comment:

This is a great point, which we had not communicated enough in our initial proposal: this SPE using RFPs as a mechanism to attract new talent to the ecosystem. The Foundation will actively look for proposals outside of our immediate contributor set and use our - and the community’s - network to seek more applications.

That said, for this initial SPE proposal, we see as the majority of applicants coming from within the existing Livepeer community. So long as quality remains high, we do not see this as a problem, particularly given that this SPE is an experiment.

This is very much noted. Myself, @salinsug and @rickstaa have discussed this internally within the Foundation and we see this as a sequencing question: there is no point trying to incentivise engineers and founders to build directly on the Livepeer network if it remains difficult to do so.

One of the Foundation’s priorities for Q2 is to drastically improve the developer experience of building on Livepeer and build the necessary pieces to enable demand on the network. Once the Network Engineering SPE has made the network more observable and easier-to-use, the broader Livepeer community can then lean into onboarding demand as a community.

The honest answer is: we don’t know. If we have an influx of requests there may need to be more input, particularly around coordination costs. We could look to cut this budget down $5,000 equivalent per reviewer, expecting to have 5-7 hours of commitment.

I welcome any further feedback as we would like to put our proposal onchain by end of day Wednesday 29th April. Thanks in advance!

1 Like

I really like the structure of this SPE and hope it can have future iterations as well.

This fills a gap where a full SPE proposal is too much for the tasks required. Also helps pave a way to provide support and possibly implement some targetd changes to the stack to enable builders to use the stack efficiently.

No specific feedback initially from me. The payouts over time and two funding tracks I feel like cover the targeted usecases and issues that could arise.

4 Likes

Network Engineering SPE — Update #1 (May 2026)

Period: 15 May 2026 – 31 May 2026

Status: On track

Summary: SPE launched on schedule, both funding lanes opened, and the first RFP ran end-to-end with a contract awarded within 11 days.

Completed Deliverables

Watercooler Presentations

Project Updates — Discord #📊│project-updates

Follow the discussions here

Planned by Next Update

  • RaidGuild Tranche 1 (audit plan + teardown scope) signed off.
  • More RFPs and grants.

ETA for Next Update: 30 June 2026

1 Like

Great to see the first update! Love the speed on the first RFP with RaidGuild. This approach brings a lot of clarity and transparency to the community. Keep up the great work!

2 Likes

Network Engineering SPE — Update #2 (June 2026)

Period: 1 June 2026 – 26 June 2026

Status: On track

Summary: All three funding lanes ran live this month — the first Direct Grant was awarded, the first RFP delivered Milestones 1 & 2, two retroactive grant applications were received, and new builder bounties opened.

Completed Deliverables

1 Like

Network Engineering SPE — Update #3 (July 2026)

Period: 27 June 2026 – 27 July 2026
Status: On track
Summary: RFP #1 closed out complete with a public retrospective, five retroactive grants were decided across five different builders, and Direct Grant #1 had Milestones 1 & 2 signed off.

Completed Deliverables

  • RFP #1 — Delegator UX Analysis (RaidGuild) — completed and closed

    Milestone 3 (design brief, instrumentation plan, draft prioritized backlog) and Milestone 4 (final backlog, final analysis report) both delivered, closing all four milestones with nothing deferred. 27 gaps scored by severity and split into Quick Wins and Follow-on RFPs, now a prioritized backlog milestone in the Explorer repo. Delivered beyond commitments: The Graph teardown, agentic delegation research, and one user interview.

  • Retroactive Grants — five decisions, five different builders

    Every decision ran the published process end to end: application, AI rubric pre-screen, Review Team decision.

    • Livepeer Workflow Kit (Shane) — approved. The Review Team independently verified funded execution through the hosted service — catalog and route discovery, paid Florence-2 inference, Nemo transcription — confirming live orchestrator-backed usage rather than local framework code. AI pre-screen · Review Team decision
    • Livepeer Discord Protocol Data Bot & Public Protocol Data API (Mike Zupper / Cloud SPE) — approved. The Review Team verified the live API returns canonical finalized records from Arbitrum block 6,072,093 through current blocks, with block-anchored ETH and LPT valuation. AI pre-screen · Review Team decision
    • Explorer Bounty Umbrella: Bug Fixes and UX Improvements (ECWireless) — approved. Three merged PRs against pre-existing maintainer-filed tickets. Decision · #710 · #712 · #713
    • Extend voting transparency to the governance page (ibs) — approved. Surfaces voter, staked LPT, vote choice and per-voter history on finalized polls. Decision · #683
    • Explorer Bounty Umbrella: Delegators View & History Event Filter (lpt.moudi.eth) — approved, releases on merge. Delegators tab on orchestrator pages and a 12-category filter on account history, both closing maintainer-filed issues. Decision · #719 · #720
    • Conflict of interest handled in the open: Rick Staa stepped down from the review board for the Protocol Data Bot grant only, as a prior user of the tool. Recusal
  • Retroactive Grants — sixth application received and pre-screened

    Realtime Flux Klein over Trickle (Moein / zargarzadehm). Closes a maintainer-filed example request, throughput tuned from ~11.65 to ~24 fps, independently stood up and run by a named orchestrator and a second community tester. Review Team decision pending.

  • Direct Grant #1 — Livepeer Payment Clearinghouse (John Mull / Elite Code Solutions) — Milestones 1 & 2 signed off

    Nine PRs merged in livepeer/clearinghouse this period. Shipped and demoed publicly: RFC 8628 device-code login via Auth0, default credit subscriptions on OpenMeter, MoonPay (ETH and LPT) through the Turnkey-managed remote signer, Stripe checkout, and bearer-token API keys with passkey login. The grantee reported the project running roughly 1.5 weeks behind schedule, with the stack usable by builders today.

Watercooler Presentations

  • 30 June — Elliot (RaidGuild): Delegator UX RFP walkthrough — teardown, 27 gaps, persistent delegation widget proposal.
  • 30 June — John (Elite Code Solutions): Clearinghouse — Docker runtime stack merged, live Auth0 device-login demo, price oracle, OpenAPI spec.
  • 7 July — Elliot (RaidGuild): final Delegator UX output, backlog milestone opened in the Explorer repo, Vercel instrumentation plan.
  • 14 July — John (Elite Code Solutions): Payment House — subscription credits, MoonPay and Stripe, API keys, and an honest read on schedule.

ETA for Next Update: end of August 2026

Retrospective: Network Engineering SPE

The Network Engineering SPE was set up as a pilot, the first of its kind, to answer a single question: whether the network can fund small, scoped engineering work quickly enough to matter. We mean the $2k to $20k range, where a full SPE proposal costs more than the work itself and the vote cycle runs longer than the build. Three months on, we believe it can, though not quite in the shape we first designed. We built the programme around three funding mechanisms: the one we expected to carry it (RFPs) turned out to be the slowest; the one we added halfway through (Direct Grants) moved the most capital; and the one we expected least from (bounties) brought five builders into Livepeer repositories, several of them contributing for the first time in a long while.

In total the pilot funded eleven pieces of work across those three mechanisms, from a $500 bounty through to a five-figure Direct Grant, involving more than ten different contributors and teams. $38,150 has reached builders so far, with a further ~$20.6k allocated and settling before or shortly after close. Every award carries a written rationale published on the forum.

Why we’re closing now. Voting on the pilot closed on 11 May, so this retro lands almost exactly three months in, the window we scoped for it. The pilot was always meant to test the mechanism rather than run indefinitely, and it has done that. With resources and priorities now moving towards Livepeer 2.0, we think the right call is to close the pilot on schedule rather than extend it, and to carry these learnings into the follow-on proposal.

What we set out to solve

Before this SPE, Livepeer already had several ways to fund work: ad-hoc payments for small one-off fixes at one end, RFPs for defined pieces of work, and a full SPE or treasury proposal with its own governance vote at the other. What was missing was a fast, lightweight route for the middle: small, scoped engineering in the $2k to $20k range, a few days to a few weeks of work, that was too large to wave through as an ad-hoc payment, yet where a full proposal and vote, or even an RFP’s competition cycle, cost more time than the work itself. More often than not that work either didn’t get funded, or got funded so slowly that the effort of deciding outweighed the effort of doing. The pilot’s job was to close that gap: to stand up a lightweight, credibly neutral and auditable way to move funding to scoped engineering work in weeks rather than quarters, and to learn where it strained.

The three funding mechanisms

We launched with two mechanisms and added a third as we went. RFPs are a public competition for a defined piece of work, best used when we need a contributor who isn’t already in the network. Retroactive Grants fund work that closed a problem the community had already named, assessed once it has been delivered. Direct Grants, which we introduced mid-pilot and capped at $20k with milestone payouts, are for clear-scope work with an obvious builder that fits neither of the other two. Bounties sat inside the Retroactive mechanism at its small end: individual fixes of a few hundred dollars each.

Whatever the mechanism, each ran on the same spine: a published process, an AI rubric pre-screen against criteria posted before the application arrived, a Review Team decision, and a written rationale on the forum, including a published recusal wherever a reviewer held a prior interest. One standard, applied in the open.

Key Learnings

RFPs are slow must be used strategically. (RFP mechanism.)

We committed to three RFPs and, in the end, ran one. An RFP really earns its cost only when the right contributor is neither already in the network nor already known to us. Where we knew who should do the work, a public competition added weeks and changed very little; and where we genuinely did need new talent (the runtime RFP we later deprioritised), a two-week window and a single forum post would still have reached nobody new, because the cycle was too short and the distribution too narrow. The remaining RFP budget moved across to Direct and Retroactive Grants at the 30 June checkpoint, as the pre-proposal allows.

Recommendation for future: keep RFPs, but use them strategically, reserved for when we need talent from outside the network, and when we do, budget three weeks to a month per cycle, leave the window open for longer, and distribute the RFP well beyond the forum.

Two mechanisms weren’t enough, so we built a third. (Direct Grants.)

Within a few weeks we ran into work that fit neither RFP nor Retroactive: the scope was clear and the builder obvious, but it was too large for a bounty and too specified for a competition. So we published Direct Grants, held it to the same process, and it went on to move the most capital of the three: both the Payment Clearinghouse and the subgraph audit ran through it. No process designed up front will anticipate every kind of work, and being able to add a mechanism mid-pilot, in the open and under the same rules, is a large part of what kept work moving.

Recommendation for future: treat the set of mechanisms as something we can edit. Keep Direct Grants as a permanent path, and keep the freedom to publish a new mechanism mid-cycle when real work doesn’t fit the existing ones.

Retroactive grants work when the problem was named first. (Retroactive Grants.)

Retroactive funding is not payment for whatever happened to ship. Every grant we approved traced back to a problem the community had already surfaced and written down (a Roadmap Session output, a maintainer-filed issue, an opportunity session) before anyone built against it. That prior step is what makes retroactive review possible at all: it gives the Review Team something concrete to measure impact against, and it keeps the mechanism from drifting into a subsidy for work nobody asked for.

Recommendation for future: keep the “problem named first” gate as a firm requirement, and lean on the grantees’ own published retros, as we do now, as the record of who benefited from each piece of work.

Bounties did the most, and carried the most paperwork. (Bounties, within Retroactive.)

Five bounties, five community builders, a few hundred dollars each. Some were new to Livepeer, others were coming back. Either way, that is the outcome we wanted from this mechanism: new people, merged pull requests. We ran them wrong, though. A $500 bounty went through the full retroactive path (a formal application, an AI pre-screen, a Review Team decision and a published rationale), which is really a process built for $5,000 of risk. The work stood on its own merit, and the Technical Director had usually signed it off before the paperwork even began; more than once a contributor spent longer on the form than on the fix itself.

Recommendation for future: give the SPE a ring-fenced bounty budget with a hard per-bounty cap at the small end, and let SPE members run it autonomously: scope, award, review and pay directly, with no application path, keeping only the paper trail for the work itself. We can reserve the heavier review for the larger retroactive applications, where it earns its keep.

Review capacity, not the mechanism, is where the latency sat. (All mechanisms.)

We had assumed review load would spread naturally across a seated Review Team. In practice it didn’t: technical sign-off concentrated on the Technical Director, who was carrying Explorer, subgraph, protocol and live-runner work all at once. Concentrating on one person that holds the most context isn’t wrong in itself, but here it put a queue between work being finished and a contributor being paid, which is precisely the latency this SPE exists to remove. The fix turned out to be cheap once we saw it: we paid an external reviewer a small bounty that had domain knowledge and was long term contributor (ECWireless, on the Explorer work), and he cleared payouts that had been waiting on a single calendar. The deeper point is that review is a fundable, distributable job rather than a fixed cost of one seat.

Recommendation for future: budget a dedicated reviewer line from day one, and lean into peer review, contributors reviewing each other’s work in public, as ECWireless did on the Explorer, so the load is shared rather than routed through one person. It is also worth exploring, in the next phase, how far the AI pre-screen can go towards agent-assisted impact judging, so that demonstrated impact does more of the work of deciding what gets paid.

AI pre-screening held the quality bar at speed. (All mechanisms.)

Every decision ran the same path (an application, an AI rubric pre-screen against published criteria, a Review Team decision, a written rationale) across RFPs, retroactive grants and direct grants alike. It bought us two things at once: decisions quick enough to be useful, and decisions anyone can audit after the fact. One standard, applied at speed, without adding headcount.

Recommendation for future: keep it as the default spine for every mechanism, and keep investing in the rubric itself, which is the highest-leverage part of the whole system.

Speed was rarely the bottleneck. Deciding what to fund was. (All mechanisms.)

This was the claim the SPE set out to test, and across all three mechanisms it held. RFP #1 went from published to awarded in eleven days against a fourteen-day target; retroactive decisions ran on a published monthly cycle; bounties went from a merged pull request to payment within weeks. Almost every time we were slow, it was because we hadn’t yet decided what to fund, and very rarely because the machinery couldn’t move. That hesitation had a specific cause: Livepeer 2.0 was still being defined, and we held back rather than fund work against a direction that was about to change.

Recommendation for future: the funding rails are proven, so don’t spend the next phase rebuilding them. The Roadmap and opportunity sessions are working and should stay as they are; what was missing was a settled direction to point them at. Livepeer 2.0 now gives us that, so the next phase should open with priority areas already agreed against it, and let the rails run at the speed they have already shown.

What it added up to

It is easy to read the grants as a list; they matter more as a connected whole, and the clearest way to see that is to look at who benefited from each piece of work.

The Delegator UX Analysis (RaidGuild) served delegators weighing self-custody against custodial staking, and left the Explorer team with a prioritised backlog of 27 scored gaps, split into Quick Wins and follow-on work, a ready-made input to a future Explorer proposal. The Explorer bug fixes (ECWireless), the delegators view and history filter (lpt.moudi.eth) and the governance voting transparency work (ibs) all benefited the same audience directly: the delegators and voters using the Explorer day to day.

On the demand side, the realtime Flux Klein example over Trickle (zargarzadehm) and vllm-realtime (Gideon Jones) gave builders working, public examples of new network capabilities to build against, and generated practical feedback that feeds the next round of development. Moein’s performance work alone took Flux Klein from 11.65 to 24 fps. These sat alongside the live-runner and runtime work J0sh was already driving in go-livepeer, which was supported directly rather than route through a lengthy RFP: the objective was the same, advancing a hard piece of core infrastructure, but the most efficient mechanism was to accelerate work already under way rather than onboard new contributors into a complex area. That core work is a good part of what made the demand-side experiments possible in the first place. Brad (ad-astra) contributed to the same core-infrastructure track, across go-livepeer and the BYOC and AI-runner pipelines.

The subgraph audit (BuildersDAO) speaks to a reliability risk we have already felt first-hand, when the subgraph went down, the issue took two full days of work, significant impact on delegators and 36 hours of recovery time; now the audit is on the way, and BuildersDAO will publish its own retro once the work lands.

The Payment Clearinghouse (John Mull) benefited developers who want to reach the network without standing up their own gateway. Its first two milestones shipped device-code login, credit subscriptions, a fiat on-ramp and API keys, and it doubled as a live test bed for the new remote-signer architecture, feeding directly into the hosted payment infrastructure. It is also the pilot’s clearest lesson in scope discipline. The remaining milestones are behind schedule, in large part because John was asked to support the livepeer-agent workflows while the live runner wasn’t yet ready, which split his effort between what the ecosystem needed right then and what the grant had actually scoped. That is as much on us for not stepping in sooner as it is on the grantee, and it is a reminder to hold scope firmly once milestones are agreed.

Two of the retroactive grants, the Workflow Kit (Shane) and the Protocol Data Bot and public Protocol API (Mike Zupper), clearly serve builders and community members who want easier workflows and open access to protocol data. On Mike’s side the adoption is already visible: more than ten orchestrators are now using the Discord bot to track their protocol data day to day, which is exactly the audience the grant was aimed at.

Underneath all of it, five community builders (ECWireless, ibs, lpt.moudi.eth, Moein and Gideon) are now contributing inside the codebase, several of them for the first time.

A word on the record itself, since it comes up: impact assessments in this programme are the grantees’ own published retros. The retroactive-grant builders have published theirs; the RFP’s impact is captured in this document; and the two Direct Grants still in flight (the Payment Clearinghouse and the subgraph audit), together with Gideon’s vllm-realtime bounty, will carry their retros as that work completes.

So what’s Next

The mechanism works well enough to run again with these changes built in, and what it funds next is a decision for the community to make. The Roadmap Session on Tuesday, ahead of Water Cooler, walks through this retro and then opens the floor: which priority areas to fund, which parts of the mechanism to change, and any other feedback from participants, members and the wider community. If you took funding from this SPE, applied for it, reviewed for it, or looked at it and found the door too narrow, that session is the place to say so.

Acknowledgements

As ever with the SPE model, the SPE itself didn’t build anything. It simply moved funding to the people who did, and all of the impact here came from contributors across the ecosystem.

Thank you to everyone it funded: RaidGuild (and especially ECWireless) for the Delegator UX work and for showing up in the community throughout; ECWireless for the Explorer fixes; Shane for the Workflow Kit; Mike Zupper for the protocol API and the payout bot; John Mull for taking on payments; ibs for making governance more legible; lpt.moudi.eth for the delegators view and history filter; Moein (zargarzadehm) for the Flux Klein example and the performance work; the Rahimi Team for the Explorer UX scoping insight; and BuildersDAO for taking on the subgraph.

A particular thank you to Josh, whose go-livepeer work most of this was built on, and to the orchestrators and community members who stood up runners on their own hardware and quietly tested other people’s work in public, among them @pon11118, @titannode and Sean (@.originstory).

And finally to the team who did the unglamorous half of this, Rich O’Grady , Rick Staa, Brad (@adstra) and Jason (@everest_node), for reviewing, writing the rationales, and recusing themselves when they had to. The decisions were only auditable because they wrote them down.

— Mehrdad, on behalf of Network Engineering SPE


The section below is the reference record behind the narrative above: the commitments scorecard and the full budget.

Appendix: Retro Report and Budget

15 May to 11 August 2026 · Treasury proposal · Pre-proposal

Commitments Scorecard

Commitment Status
PILOT SUCCESS CRITERIA
Minimum 3 RFPs reach verified impact :warning: Partial. One RFP issued, delivered and closed complete (Delegator UX Analysis, RaidGuild, all four milestones, nothing deferred). Remaining RFP budget reallocated to Direct Grants and Retroactive Grants at the 30 June checkpoint.
Minimum 5 retroactive grants funded :white_check_mark: Seven decided, seven different builders, five of them bounties, each with a published rationale
Three public SPE updates published :white_check_mark: #1 (4 Jun) · #2 (26 Jun) · #3 (27 Jul)
15 MAY: FUNDING PROGRAMS LIVE
Review Team seated, weekly cadence established :white_check_mark: Seated and announced at Water Cooler; weekly sync ran throughout
Funding mechanism processes published :white_check_mark: RFPs · Retroactive Grants · Direct Grants, added in-pilot
Retroactive grants open, public tracker live :white_check_mark: Forum categories live, builder ideas & bounties board public
30 JUNE: FIRST DELIVERIES VERIFIED
At least 1 RFP delivered :white_check_mark: Milestones 1 and 2 signed off by 26 June
At least 1 retroactive grant awarded :white_check_mark: Two decided in June, four more in July
14-day selection target met :white_check_mark: 11 days, published to awarded
30 AUGUST: PILOT COMPLETE
All impact assessments done :counterclockwise_arrows_button: Impact assessments are the grantees’ own published retros. The retroactive-grant retros are in, and the RFP’s impact is captured above. The two Direct Grants still in flight (Payment Clearinghouse, subgraph audit) and Gideon’s vllm-realtime bounty will publish theirs as the work completes.
All spend published :counterclockwise_arrows_button: Disbursements below; final reconciliation at pilot close
Evaluation report with recommendation :white_check_mark: This document. Recommendation: continue, with the mechanism changes above

Budget

The SPE was funded with 43,000 LPT against a $95,000 USD-equivalent budget at the time of the proposal. Every payment is priced at the 7-day moving average LPT price on its execution date, so LPT amounts move against the same USD figure as the price moved through the pilot. Work that is allocated but not yet paid is listed as still due and settles before or shortly after pilot close.

Line items Budget Allocated to Paid (LPT) Still due Notes
Track 1 RFP pool $45,000 One RFP issued. Remainder reallocated at the 30 June checkpoint
Explorer UX RFP, 4 milestones RaidGuild 6,169.10 Complete, closed with a public retrospective
Honorarium, Explorer UX scoping Rahimi Team 280.19 Scoping input ahead of the RFP
Track 2 Retroactive Grants pool $15,000 Seven decided, five of them bounties
Workflow Kit Shane 3,155.97 Retroactive grant
Protocol Data Bot & Protocol API Mike Zupper 2,209.18 Retroactive grant
Explorer bug fixes & UX (#709) ECWireless 631.19 Bounty
Governance voting transparency (#482) ibs 315.60 Bounty
Delegators view & history filter lpt.moudi.eth 382.94 Bounty
Flux Klein example over Trickle Moein 382.94 Bounty
vllm-realtime Gideon $500 Bounty. Decided, payment pending
Explorer bounty review, per PR ECWireless $500 Review bought 4 Aug to clear the merge queue
Direct Grants Mechanism added in-pilot, funded from buffer $20,000 Buffer reallocated to the third mechanism
Payment Clearinghouse, M1 & M2 John Mull 4,197.44 Paid
Payment Clearinghouse, remaining milestones John Mull $8,350 Gated on remote signer documentation, then merge
Subgraph audit BuildersDAO $6,500 Approved 6 Aug, audit under way
Review Team Reviewer compensation $15,000 6,985.33 $5,000 June and July paid. August and closing period still due
Budget (proposal) $95,000
Budget LPT (proposal) 43,000
Paid to date 24,709.86
Still due ~$20,650 Allocated, not yet executed
LPT unspent 19,175.96 considering staking yield, before the still-due items settle

Full line-by-line payout log, with recipient addresses and Safe transaction links: Network Engineering SPE payout log. On-chain transactions from the SPE multisig 0x10305D0aD3971108Bf5D6da1EC0A39E9d046ec7f.

4 Likes