The problem

Builders evaluating Livepeer today don't have a clear path from discovery to first inference call. Capabilities across gateways are not surfaced in a consistent, product-oriented way. There is no interface that takes a builder from "what can this network do" to "I've made my first call" in a measurable, reproducible window.

The result: high-intent builders bounce before they activate. The network doesn't get the real-time feedback it needs to prioritize what to build next. Demand-side signal — the thing the Foundation's strategy depends on — stays thin.

This is not a documentation problem. It's a surface problem. The documentation, the SDK, the gateway infrastructure, the payment primitives all exist. The activation layer that brings them into a single legible path for a developer — does not.

The direction

A Developer Portal that serves as the demand-side interface for the Livepeer network. The Foundation-owned surface where a builder moves from discovery to first use.

Scope includes documentation, a Python SDK, BYOC container tooling, payment and auth infrastructure, and the scaffolding required to deliver a measurable claim: docs to first inference call in under five minutes, from any MCP-compatible tool.

The five-minute API is the critical-path metric, not a slogan. It gets measured weekly on a fresh environment. Published Tuesdays. If it slips past 10 minutes, scope review. Past 15 minutes, timeline review.

Why now

The engineering foundations are in place. The Payment Clearinghouse, the Python SDK, the gateway replacement — six months of work that the community has seen shipped but whose demand-side implications have not been surfaced cleanly. The Developer Portal is the surface that makes that work legible.

Related work is also shipping from the broader ecosystem. The NaaP Epic 2 MVP delivers the dashboard, API manager, capacity planner, and SDK that any demand-side surface requires. NaaP and the Developer Portal point in the same direction. How the two integrate — whether NaaP becomes the Developer Portal's backend, whether specific components are adopted, or how the surfaces relate — is part of the scoping work ahead.

Funding this through the Network Engineering SPE lets it move at the pace the opportunity requires, with public accountability on deliverables and impact.

What the community helps scope

The problem statement is settled. The solution direction is settled. The scoping work ahead is:

• The specific RFPs and their sequencing. What ships first, what depends on what.

• How the Python SDK, BYOC tooling, payment infrastructure, and agentic harness components sequence against each other.

• How the Developer Portal integrates with existing demand-side infrastructure including NaaP.

• Where orchestrator needs intersect with developer needs — and where the Developer Portal surface needs to expose both.

• What "five minutes, on a fresh environment, from any MCP-compatible tool" means in concrete test terms.

Funding path

Network Engineering SPE, Priority 1 — Developer Portal — The 5-Minute API. The SPE funds scoped RFPs in the $2k–$20k range, with a Review Team drawn from the orchestrator community, a Technical Director sign-off on delivery, and all decisions published with written rationale. Pre-proposal: Network Engineering SPE — Pre-Proposal.