How RFPs Work — Network Engineering SPE
The Network Engineering SPE commissions work through public RFPs. This post explains the process and what makes it different from the typical RFP format we were following previously.
SPE Treasury Proposal: Network Engineering SPE on Livepeer Explorer
The Five-Stage Process
Stage 1 — RFP Posted
The team identifies a scoped engineering need, defines the problem and high-level deliverables, and posts the RFP publicly on the forum.
Stage 2 — Applications Open (7 days)
Anyone can apply. Applications are posted as replies on the same forum thread. Your proposal should address the problem, outline your approach, name your deliverables, and state your ask. The community can comment and signal support throughout.
Stage 3 — AI Pre-Screening
All applications are pre-screened by AI against the eligibility rubric before the Review Team sees them. Applications that clearly miss scope, lack a concrete output, or are incomplete are returned with written feedback. This keeps review time focused on real contenders.
Stage 4 — Review Team Decision
The Review Team (Technical Director + 2 Reviewers) evaluates shortlisted applications. A simple majority decides. Decision is published with written rationale — approved, declined, or returned for revision.
Stage 5 — Pricing Agreement & Work Begins
Once selected, a Pricing Agreement is countersigned and work begins.
How Funds Are Released
Payment for Network Engineering SPE RFP is structured in three tranches:
| Tranche | % | Unlocks On |
|---|---|---|
| Signing | 25% | Countersigned Pricing Agreement. At the beginning of the work. |
| Delivery | 50% | Review team verifies deliverables against definition of done. |
| Impact | 25% | Retrospective report submitted within 30 days of delivery, covering community engagement (user testing, surveys, or interviews), what was learned, and how the work was adopted. |
Reporting & Accountability
Contributors are expected to maintain visibility throughout the engagement. There are three requirements:
- Monthly update — a progress post on the same forum thread at the end of each month. Examples are available here and you can use this guide to report your progress.
- GitHub milestone page — set up at the start of work, with issues linked to deliverables. Progress should be visible to anyone at any time. Explorer and Cloud SPE are great examples of this work.
- Retrospective report — submitted within 30 days of delivery as part of unlocking the impact tranche.
The impact tranche is tied to the retrospective report. We are not expecting contributors to drive adoption — that is not their job. What we do expect is that within 30 days of delivery, they engage the community: talk to users, run a survey, track activity, or conduct interviews. The findings are written up in a retrospective report covering what was built, who engaged with it, what was learned and how did others find adapting the work. There are no specific KPI metrics. The 25% releases once the contributor has done the engagement work and the report is accepted.
Questions?
Drop them in the comments. If you’re thinking about applying and want to do a quick tempcheck before investing time, reach out to (.adastra. on Discord).
— Mehrdad, on behalf of the Network Engineering SPE