Hi Sparta(cool name btw!), thanks for the question. Yes, we see a clear opportunity for both WEAVE and Punch Compute to evolve alongside Livepeer 2.0.
From the start, the SPE has been intended to adapt as the technology and the ecosystem change. If something outside the original roadmap can create more value for Livepeer, we should be able to incorporate it and explain that change through our deliverable reviews and public updates. That means we can describe our direction, but it would be premature to give a precise picture of what both products will ultimately look like.
For Punch Compute, we are exploring three practical integration areas:
- Discovery: expose a defined Punch compute capability through Livepeer discovery and SDK interfaces, with the aim of enabling agents to find providers, inspect availability and pricing, and request work.
- Payments: connect paid workload usage to Livepeer’s payment and metering path. Punch’s future bookings, cancellations and unused-time rollover need an explicit mapping to that lifecycle.
- Node infrastructure: explore using Live Runner to expose Punch services through existing orchestrators, while Punch retains responsibility for provisioning, workload isolation and cleanup.
The existing Live Runner interfaces give us a concrete starting point, while the wider 2.0 design and engineering scope continue to evolve. We still need to validate this integration end to end. Punch was built specifically for Livepeer orchestrators, and we already compensate participating providers. Settling future Punch usage through Livepeer’s protocol is a separate integration step.
For WEAVE, the starting point was a tool that network participants could use to create new workloads and applications. We initially approached that through a dedicated agent harness. As established harnesses have improved, we see more value in building on their strengths and focusing WEAVE on what it can add around them: helping agents use shared network capabilities, and coordinating applications, workloads and incentives in ways that continue to benefit the community after delivery.
One direction we are exploring is incentive alignment between Livepeer and other ecosystems: arrangements where creating something useful elsewhere also creates demand for Livepeer services. That is the kind of synergy we want to develop further. We will share the concrete design when it is ready for an announcement.
There is also a connection between Punch’s compute providers and the long-term operating and incentive plan currently under treasury review. The proposed model would use available rewards from SPE treasury-managed assets to fund useful workloads and builder activity, with the principal remaining under treasury control. This would give the incentive program a funding source independent of Punch’s direct B2B or B2C revenue, and a way to support ongoing demand and fees for orchestrators. Its capacity would depend on actual available rewards; fee growth is the objective, rather than a guaranteed outcome. We would report incentive-funded usage separately from external customer demand.
We will publish the full mechanism once treasury review and authorization are complete and the operating plan is finalized. In the meantime, we welcome feedback from you and anyone interested in helping shape these connections with Livepeer 2.0.