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 |  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 |  Seven decided, seven different builders, five of them bounties, each with a published rationale |
| Three public SPE updates published | #1 (4 Jun) · #2 (26 Jun) · #3 (27 Jul) |
| 15 MAY: FUNDING PROGRAMS LIVE | |
| Review Team seated, weekly cadence established | Seated and announced at Water Cooler; weekly sync ran throughout |
| Funding mechanism processes published | RFPs · Retroactive Grants · Direct Grants, added in-pilot |
| Retroactive grants open, public tracker live | Forum categories live, builder ideas & bounties board public |
| 30 JUNE: FIRST DELIVERIES VERIFIED | |
| At least 1 RFP delivered | Milestones 1 and 2 signed off by 26 June |
| At least 1 retroactive grant awarded | Two decided in June, four more in July |
| 14-day selection target met | 11 days, published to awarded |
| 30 AUGUST: PILOT COMPLETE | |
| All impact assessments done |  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 | Disbursements below; final reconciliation at pilot close |
| Evaluation report with recommendation | 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,850 | 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.