The Shifting Role of the Orchestrator

1. General

• Proposed By: Doug Petkanics

• Proposed On: 2026-05-11

2. What Is The Problem?

As the network shifts to a world of heterogeneous realtime AI centric job types, the "most useful work" on the network looks a little bit different than it has in the past. Yet yesterday’s Orchestrator playbook of dedicated local hardware locked to a single job type doesn't yet match it.

3. Why It Matters To the Livepeer Ecosystem

Our network of Orchestrators are the beating heart of the Livepeer project, and the intention has always been that the greatest compensation flows to those contributing the most useful work. In the search for PMF during the realtime AI era, useful work means flexibly provisioning H100's for a model launch one week, hundreds of consumer grade 4090's for a social consumer experience the next, and pricing capacity in a variable fashion as market conditions and GPU requirements change over the course of the week. If Orchestrators stay locked to dedicated local hardware, and gateways treat price discovery as a one-way street rather than a negotiation, the network will over-invest in stranded capex, under-serve the demand-gen efforts hunting for PMF, and reward legacy behavior instead of the work the network actually needs at exactly the moment Livepeer is trying to become the infrastructure network that powers the future of realtime AI media. Dedicated hardware for a single job type works when that job type achieves scale, but flexibility and adaptiveness is more critical prior to finding PMF.

4. What Does Success Look Like?

• Capacity sourcing goes from "dedicated local hardware per job type" to a flexible mix of owned hardware, cloud, data center deals, decentralized services, and serverless passthrough APIs, sized to live demand.

• Demand visibility goes from "Discord rumors and folklore" to a NaaP Operator dashboard that shows, in realtime, the workflows on the network, fees flowing to each job type, GPU and compute requirements, average network pricing, and forecasts/requests for future capacity.

• Price discovery goes from "gateway-dictated, one job type, one price" to a job-by-job negotiation in which Orchestrators price variably to make sure they're only providing capacity that makes economic sense, and gateways pay enough to incentivize the capacity they need.

• Operator tooling goes from "manual, per-operator spreadsheets" to optimization modules that take market conditions, current job types in demand, LPT reward-cut incentives, and idle-time estimates as inputs to provisioning and pricing decisions.

• Stake flow goes from "agnostic to job mix" to LPT delegation flowing toward the nodes doing productive work at acceptable reward-cut levels, supported by improved staking-tool UX.

5. Open Questions

• Cloud margin paradox: How can the Livepeer Network be cheaper than just renting cloud capacity, if the node operators themselves need to access cloud capacity and then apply a margin? At scale, marketplace competition on idle hardware should still result in the lowest possible price; prior to scale, LPT incentives and the resourcefulness of a global operator base sourcing the most efficient capacity have to win out vs defaulting to the premium option.

• Negotiation protocol ownership: What does the minimum viable variable-pricing protocol at the gateway ↔ Orchestrator layer look like, and who is building and optimizing this?

• Staking UX: How do we evolve staking-tool UX so LPT delegation flows toward the nodes doing productive work at acceptable reward-cut levels, without disrupting existing delegators?

• Operator inclusivity: How do we keep smaller, hobbyist Orchestrators competitive when the new playbook rewards multi-cloud sourcing skill and API orchestration, and how do we surface and reward their broader contributions (community meetings, Discord support, dev entities) alongside flexible compute?

• Reward design: How prescriptive should the project be about "ideal" Orchestrator behavior versus letting the open marketplace settle it?

  This roadmap suggestion is the start of an early conversation so the community can take part in tackling these challenges. Looking forward to hosting discussions on this soon, before swinging into concrete build items and action.