Introducing Retroactive Grants — Network Engineering SPE
The Network Engineering SPE is a community-funded initiative that supports engineering contributions to the Livepeer network. This post introduces the Retroactive Grants track — a way for contributors who have already created real impact to get compensated for it.
If you’ve built something that the Livepeer community is already using, and you can prove it, read on.
SPE Treasury Proposal: Network Engineering SPE on Livepeer Explorer
What is the Retroactive Grants track in one paragraph?
This track funds measurable impact that already exists — not work done, not effort invested, not potential. There is no upfront approval or grant to apply for before you build. You create something, the community uses it, the impact is visible right now — then you apply.
Grant ceiling: <$5k per application. One-week review turnaround. Payments batched at end of each month. All decisions written and public.
Who can apply?
This pilot primarily focuses on existing Livepeer contributors — people already active in the network community. In practice, we will not be accepting applications from anyone without an established presence. Your application must also be supported by existing contributors who will be verified before your submission proceeds to review.
What qualifies?
Contributions must fall within one of these three areas:
- [Developers] The 5-Minute API — Work that reduces time-to-integration for developers and AI agents. Python SDK, BYOC container tooling, payment and auth infrastructure, agentic harness tooling, libraries or scaffolding that remove onboarding friction.
- [Delegators] Governance & Network Observability — Work that makes the network more legible and governable for LPT holders. Dashboards, Explorer improvements, data pipelines, and tooling that surfaces real network behaviour.
- [Orchestrators] Tooling & Infrastructure — Work that helps orchestrators run more reliably and scale capacity. Containerisation, orchestration tooling, runtime improvements, go-livepeer contributions, infrastructure that improves network reliability.
If you’re unsure about whether your work will be accepted, reach out to jj.a.ss.o.nn_everestnode on Discord before submitting an application.
The five-stage process
Stage 1 — Create measurable impact
You identify a gap, discuss it, build something useful, ship it, and the community adopts it. The impact must be real and verifiable at the time you apply — not projected, not promised.
Stage 2 — Apply on the Forum
Create a new post in the Retroactive Grants Funding category on the Livepeer Forum — when you create a new post, a template will be provided for you to fill. Your application must include:
- Who had this problem, and how do you know? Name the need and the people who had it.
- Who is already using this, and can they confirm it? Name at least one identifiable community contributor who can verify the work helped them.
- What was built and why? Describe what you shipped and the problem it solves. Link to any prior community discussion or tempcheck.
- Link to the work. Merged PR, deployed tool, published docs, or equivalent. No link, no review.
- Amount requested. Max $5k USD-equivalent. Include a brief rationale — especially if above $2k.
All applications are public. The community can comment, ask questions, and signal support.
Note: Before applying, you must have at least one community proof point — a Discord thread where your work received positive signal, an acknowledgement from a Review Team member, or evidence of adoption (other people actively using your output). Applications without a proof point are returned, not declined.
Stage 3 — Community Attestation
Once your application is posted, at least one identifiable community contributor must reply to your forum post, attest to your impact, and share their thoughts. These must be real, named, identifiable community contributors who used your work meaningfully, can speak to the value of your contribution and explain how the work you proposed for retroactive grant has helped them.
Applications without minimum of one attestation will not proceed to formal Review Team evaluation.
Stage 4 — Review Team Evaluation
All applications are first pre-screened by AI against the eligibility rubric. Applications that clearly fail on scope, lack a reviewable output, or are missing proof points are returned with written feedback.
Applications that pass are evaluated by the Review Team (Technical Director + 2 Reviewers) against four criteria, in order of weight:
- Impact — The primary test, assessed on two axes:
- Importance of the need — How critical is the problem solved? Does it unblock adoption, fix a reliability issue, or address a recognised gap?
- Breadth already solved — How many people already benefit from this work, right now? Must be evidenced with named, identifiable community contributors — not projected. “Three orchestrators are already running this” qualifies. “This will help many developers” does not.
- Quality & completeness — Is the output production-ready? Merged, deployed, documented?
- Relevance — Does it fall within the eligible engineering areas?
- Proportionality — Is the amount requested reasonable relative to the impact demonstrated?
A simple majority (Technical Director + at least 1 Reviewer) is required. All decisions are published with written rationale — approved, partially approved, or declined.
Stage 5 — Payment
Approved grants are paid in LPT (USD-equivalent, priced on a 30-day moving average at time of approval). Payments are batched and disbursed at the end of each month for all applications approved that month. Budget is drawn from the retroactive bounty pool (25% of the total SPE pilot budget).
Declined applications may be resubmitted with stronger evidence. Partial approvals disburse the approved amount only.
What qualifies? Contributions must fall within one of these three areas:
- [Developers] The 5-Minute API — Work that reduces time-to-integration for developers and AI agents. Python SDK, BYOC container tooling, payment and auth infrastructure, agentic harness tooling, libraries or scaffolding that remove onboarding friction.
- [Delegators] Governance & Network Observability — Work that makes the network more legible and governable for LPT holders. Dashboards, Explorer improvements, data pipelines, and tooling that surfaces real network behaviour.
- [Orchestrators] Tooling & Infrastructure — Work that helps orchestrators run more reliably and scale capacity. Containerisation, orchestration tooling, runtime improvements, go-livepeer contributions, infrastructure that improves network reliability.
Small tasks and builder ideas will also be added to this board as they come in, you can contribute to them and add them to your application.
What we won’t fund
- Work with no confirmed users or adoption
- AI-generated or low-effort submissions
- Speculative work built without evidence of real community need
- Work already funded through previous grants
- Incomplete or proof-of-concept implementations
- Delivery with no adaption
Review Cadence
We aim to reach a full Review Team decision within 1 week of passing community attestation — but we ask applicants for patience.
Payments are batched and disbursed at the end of each month for all applications approved that month.
Questions?
Drop them in the comments below this post or reach out to jj.a.ss.o.nn_everestnode on Discord
— Mehrdad, on behalf of the Network Engineering