<aside> 💡

An RFP — Request for Proposals — is how the the Network Engineering SPE funds focused, time-boxed work from external contributors. Anyone can apply. Funding is released in tranches tied to verifiable outcomes.

</aside>

Why we run RFPs

RFPs translate Livepeer project priorities into concrete, fundable work packages so the right contributor can self-select in. They keep scope tight, payment outcome-linked, and decisions transparent.

Key design principles

Five principles guide every initiative funded through this SPE:

Pilot priority areas

The committed floor is three Suggestions shipped via the RFP mechanism by end of July; the aspiration is five. Three priority Suggestions are already identified for the pilot, each owned by the Foundation and scoped with the community:

<aside> 1️⃣

Developer Portal & Discoverability

The demand-side interface for Livepeer’s network. From discovery to first inference call in under 5 minutes, from any MCP-compatible tool.

</aside>

<aside> 2️⃣

Explorer as Participation Portal

A retainer team owning the Explorer repo — staking, governance, observability, and delegator experience.

</aside>

<aside> 3️⃣

Payment Clearinghouse & Remote Signer

The foundational auth + billing infrastructure that unblocks SDK adoption and agentic tooling.

</aside>

The lifecycle

flowchart LR
	A["Stage 1<br>Suggestion &<br>Promotion"] --> B["Stage 2<br>RFP & Team Selection<br>+ Tranche 1 (25%)"]
	B --> C["Stage 3<br>Delivery<br>+ Tranche 2 (50%)"]
	C --> D["Stage 4<br>Impact Assessment<br>+ Tranche 3 (25%)"]
	C -. incomplete .-> R["Remediation"]
	R --> D

1. Suggestion & Promotion

Anyone can start one. The community validates it.