Embody SPE Update — On-Chain Feedback Response, Avatar Progress, Pipeline Pause, and Proposal Revision
Hi everyone,
Thank you to everyone who provided feedback — both on-chain and in discussion. We want to address each piece of feedback directly, share development updates, and explain the changes we’re making to the proposal.
Responding to On-Chain Feedback
Feedback 1: Architecture definition
On-chain vote reason (eliteencoder.net, 353,540 LPT, Against):
“Although I support the spirit and direction of this proposal, I have open questions about the role of ‘agent workload distribution’. The project plan refers to an ‘orchestrator registry’, but does not propose or define any specific protocol or mechanism for deploying these custom workloads. The proposal appears to leave the details up to ‘agents execute research’.”
This is fair feedback and we want to explain our reasoning.
We intentionally avoided presenting a detailed architecture in the proposal. Here is why:
The pace of development in AI infrastructure right now means that if we commit to a specific architecture today, we may be implementing something architecturally different within a week. The intent stays the same — but the technical approach evolves rapidly. Locking in an architecture in a proposal document would either constrain us to outdated choices or create a gap between what was promised and what was delivered.
What we did instead:
- We included specific technical details in each work package
- We provided enough information to demonstrate feasibility and that this work can be done
- The building blocks are already publicly available — agentic workflows (attended and unattended), human-in-the-loop and fully autonomous patterns, harness engineering — all of this exists on the internet and on GitHub today
Every step of the workload lifecycle does not differ fundamentally from primitives you can already find in the open-source ecosystem. The differentiation is not in inventing new architecture — it is in adapting these proven patterns for Livepeer specifically. There is no magic or complex proprietary architecture that needs to be explained. The value is in the integration, adaptation, and the registry/incentive layer on top.
That said, we hear this feedback and we will provide more technical depth in future updates as implementation progresses and architectural decisions become concrete.
Feedback 2: “Build it and they’ll come” concern
On-chain vote reason (0xeb62…cb3e, 37.35 LPT, Against):
“I’m not convinced that the reason for lack of swapping is the tech hurdle only. I’m worried this is a ‘build it and they’ll come’ situation. Would’ve wanted to see a few past cases where facilitators wanted to use LP and couldn’t.”
We want to clarify an important distinction. This proposal is not about building a service and hoping people will come. It is about building it so that they CAN come — and making sure the incentives are there so that people have the capability to take the risk to enter Livepeer.
This is about bringing people in — building the on-ramps, the tooling, the registry, and the incentive structures that allow workload creators and consumers to enter Livepeer effortlessly.
Without this foundation, the path for new entrants will remain cumbersome regardless of how good the underlying technology is. We are not building a product and hoping for adoption. We are building the infrastructure that enables adoption to happen.
To the specific request for past cases: the demand signal we see is not “people tried to use Livepeer and couldn’t.” It is “people are building AI workloads and don’t know Livepeer exists as an option.” The barrier is discoverability and onboarding, not technical inability. Weave addresses this by creating a registry and deployment path that makes Livepeer visible and accessible to workload creators who are currently building on centralized alternatives.
Proposal Updates
Based on the discord feedback we received from @cryptomandias and Shannon, we are making the following changes:
1. Shifting weight from supply to demand
We are updating the proposal to place more weight on demand generation than on supply growth alone.
- The orchestrator package will move from $30k to $10k
- Each of the remaining packets will increase by $10k
Allocations will remain flexible so we can respond to real conditions and incoming challenges as the work progresses.
2. Registry model clarification
The Weave registry will include a verified/unverified indicator:
- Verified workloads: those that pass our review pipeline
- Unverified workloads: can still be submitted and listed. Orchestrators remain free to deploy them according to their own risk appetite
3. Project prioritization — Scope and Daydream first, Embody second
We initially planned to start with Embody workloads. After evaluating what is best for the ecosystem, we are changing the order.
We will prioritize projects based on their maturity and their potential to accumulate new users.
Applying this metric, we will go first with Scope/Daydream — projects that have clearer near-term paths to bringing new participants into the Livepeer ecosystem. Embody will come second, once we have completed the adaptation work with Scope for Weave. There is also a potential for comfystream workloads to be the second WEAVE adapted workload family considering their strong maturity and broader consumer capture reach.
We recognize that the strongest path to ecosystem growth is to start with the projects most ready to onboard new users, and build from there. We will always use this maturity-and-adoption metric to sequence our work.
We appreciate the constructive feedback and are committed to adapting this proposal to deliver the most value to the Livepeer ecosystem. Happy to discuss any of these points.
DeFine — Embody SPE Team