A Path to Livepeer 2.0

[dob]

Abstract

The world of video, and media creation generally, has evolved significantly in the 10 years since Livepeer was originally conceptualized as the world’s open video infrastructure. What was once a highly relevant transcoding protocol, has needed to evolve to keep up with the ways in which the media landscape has changed - particularly in the eras of agentic first development, infrastructure provisioning, and media creation. It’s time to confront the challenges head on that the protocol faces, and pursue an updated vision and protocol design, so that a bright future lies ahead for Livepeer, LPT, and the strong community that make up the project. This introductory Litepaper draft focuses on two things:

1. Summarize an updated vision for the Livepeer as an agentic-first, open video agent platform - including the reasons why that is a big opportunity, why the network can succeed and differentiate, and how it can drive demand to the network at scale.

2. Detail a series of potential protocol updates to align incentives for the succeed as a backing infrastructure at scale for all generative video (and media) execution. Ensure that value flows to LPT participating in the network in proportion to rising use of the network.

A note on history

There is a decade of historical context that explains how the project has arrived at this point and why some of the challenges on the network need to be addressed. The goal of this paper is NOT to re-summarize all of that history. For additional context on the LPT value capture history see:

• LPT Value Accrual and Where We Are At

Agentic-first Livepeer Vision

For anyone paying attention to how fast technology, video, and media creation more broadly are changing, it is abundantly clear that the future of these categories are being shaped by AI. It’s well known that coding agents are dramatically speeding up development cycles for software creation, and in the media world AI models and increasingly capable workflows and tools are unlocking growth in hundreds of use cases across the content stack. Humans will always play an important role in terms of the taste, craftsmanship, and creativity of producing high quality media assets, but it will be their AI agents that are inevitably executing on the media creation tasks underneath the hood after the goal is defined.

While any agent can request inference from a specific model over an API, far more than that goes into the workflow required to create a high quality video or media asset. Often times these final assets start as concept statements from prompts, and then they generate scripts, use the scripts to generate sample images for different scenes, solve for consistency across scenes, generate clips, generate voiceovers and dialogue, generate background music, imprint captions, stitch them all together solving for transitions and more. These workflows bundle together many different skills and playbooks, sometimes have 40+ steps, and involve the human directors giving input, approvals, or suggestions at many gates along the way to get to the desired outputs.

While many companies, ranging from Higgsfield to Runway to Adobe and more, are racing to produce their own proprietary versions of these specialized media agents, the race is on for an open source, community powered option that will win the market due to a series of systemic advantages. The Livepeer 2.0 vision lays the groundwork for a future that recognizes agents will be the primary consumers of media centric infrastructure and capabilities in service of all use cases.

Livepeer’s opportunity is to be the open video agent platform - combining a world class open source media planning and execution agent, a community contributed library of high quality media skills and agent playbooks, and an open infrastructure that competes to provide all the world’s known AI media capabilities at the lowest cost and highest availability.

To deliver on this, specific roles need to be played at each layer in the Livepeer project stack:

• The Livepeer Protocol is a stake based protocol aligning LPT’s value with real network usage. It is responsible for the incentives, coordination, payments, and security.

• The Livepeer Network is an open infrastructure exposing the world’s known media AI models, and best in class media creation skills and capabilities. It needs to support all the known open and proprietary media compute capabilities - a departure from the GPU-only execution environment of the network today, expanding to executing calls the 3rd party services when needed.

• The Livepeer Agent is a video agent harness for multimodal media creation. It is software that bundles the best evolving skills and playbooks to be a powerful media planning harness accessible through all popular agents today via MCP.

Using Livepeer Agent, any user will be able to create and edit high quality media assets directly from their Claude, ChatGPT, Codex, Openclaw, or agent harness of their choice. All media creation compute tasks will run through, and generate fees for, the Livepeer Network.

The Livepeer Agent is already prototyped and producing amazing outputs today. See:

• Demo video of Livepeer Agent Launch Teaser, created entirely using the Livepeer Agent itself!

• Demonstration of using the Livepeer Agent.

Supporting all media capabilities through the Livepeer Network Orchestrator Role

To date, the majority of services provisioned by an orchestrator were GPU based: namely transcoding and AI media inference. Orchestrators primarily competed by bringing their own GPUs and charging for these services. They were happy when the services were used at scale, like with transcoding, as it would keep their GPUs humming and earning in a predictable manner.

However with a diverse set of hundreds of different models and AI media capabilities, operators face a conundrum: all of these models need to be available on the network for use by Livepeer Agent in a performant way, however it isn’t profitable to dedicate GPUs to keep sparsely used capabilities warm in memory. If the Livepeer network is going to succeed at powering Livepeer Agent, the network needs to adapt to a couple of different execution models for node operators in order to ensure all needed capabilities are available:

1. Run open models locally. For popularly in demand capabilities, host and run open models locally on GPUs as nodes do today.

2. API calls to remote services. Expose any additional capability through API passthrough - call remote services and APIs to deliver on media requests from Livepeer agent.

3. Additional capabilities. Additional media compute capabilities are used by Livepeer agent, such as ffmpeg commands that mux together audio/video generations, change resolutions, and more. Host these as well via live runner architecture.

This opens up the opportunity for many nodes on the network to not require GPUs at all. Nodes can specialize in exposing 100’s of capabilities via API passthrough. Or CPU-only nodes can run other specialized capabilities not requiring GPUs. The Livepeer Agent uses many different capabilities in production of a high quality media asset - from audio generation, background music generation, storyboard images, video scene generation, stitching, muxing, clipping, captions, and more - it can call out to many nodes, paying each one along the way, in production of these assets.

Visibility into the particular capabilities used on the network, pricing, earning potential, and more can be observed through the network dashboards, enabling node operators to identify which capabilities to add to their stack if they’d like to compete to generate fees.

Livepeer Protocol Updates

To deliver on the vision of being the best open video agent platform, the Livepeer protocol itself needs to address a series of challenges that the project faces in the transition from deterministic and verifiable transcoding protocol to a marketplace and execution environment for diverse AI media capabilities. Namely, incentives need to be updated to reward those productively helping the network and minimize incentives flowing to free riders while maintaining a high quality of service amongst providers. Participants need to understand the clear reasons that LPT will capture value in correlation with growing usage of the network. While there is a lot of nuance to be spec’ed out in the proposed design, the following four high level suggested protocol updates all work together in order to address these key issues.

1. Introduce a Burn Mint Equilibrium model to contribute to LPT supply reduction in proportion to fees.

2. Introduce a stake-elected validator set to determine rewards eligibility for node operators.

3. Remove 100 node operator cap, and replace it with a fixed-bond requirement per node.

4. Extend the unbonding period to penalize misbehaving nodes with long capital lockup.

Each of these topics deserves its own paper, outlining all the parameters, implications, benefits, attacks, and more. In this post, I’ll summarize each so that everyone can absorb a high level understanding, and then we can kick off separate discussion threads for feedback and discussion on specific design choices we can consider in implementing these mechanisms in detail.

Burn Mint Equilibrium (BME)

The Burn Mint Equilibrium (BME) is a commonly adopted token economic model across DePIN protocols that provision services coordinated by a network token. There are different flavors depending on network characteristics, but at a high level, BME for Livepeer should work as follows:

1. Nodes price services in USD and users pay fees in USD to use the network. (This is our opportunity to consider shifting from ETH to USDC for fee payments).

2. Those fees are used to buy LPT from liquidity pools, such as DEX’s, creating buy pressure on the token in proportion to fees.

3. A governance determined percent of that LPT is burned, reducing supply.

4. Node operators are compensated with newly minted inflationary LPT, in proportion to how much honest work they performed.

Initially, during the bootstrapping phase, while issuance is higher, node operators are earning more in LPT than the value of the fees flowing in. However inflation comes down on a predictable schedule. As fees rise, this creates greater and greater LPT burns, corresponding with less LPT mints, and governance controls parameters to find an equilibrium between these values resulting in LPT value accrual with rising fees, and predictable token supply.

This model does away with Livepeer’s participation target based variable inflation incentives, and network ownership percentage based concept. Instead it favors a model where token holders in all roles understand how value of LPT increases over time in proportion to the increasing usage of the network. More to come on BME and Livepeer’s specific parameters and inflation schedule in topic-specific posts.

The Validator Set

In a world of diverse job types - from AI inference on GPUs, to API passthroughs from 3rd party services, to arbitrary media-centric compute execution - it has to be acknowledged that it is impossible for a protocol to cryptographically verify that work is done correctly in a deterministic on-chain way. API based services don’t all sign their responses to authenticate them, non-deterministic GPU based AI inference doesn’t return the same results for the same set of inputs, and trusted execution environments don’t extend to the types of computations required by the latest in AI Media. In addition to verification challenges as to whether work was performed correctly, there has been a further challenge, where any node can self-deal work to itself in order to be perceived as generating fees, even if that work was not really in demand in an organic way.

Combine these two issues, and it is clear that subjective judgement needs to be applied to determine who is actually doing productive work - and therefore who is eligible for LPT rewards. Yet, in an open and trustless network, that subjectivity has to be applied according to a fair, accessible, math-based decentralized protocol, secured by economic incentives of the parties involved. The following proposal introduces such a mechanism to Livepeer.

1. Introduce a stake-elected validator set.

2. The top 100 validators by total delegated stake, are responsible for determining rewards eligibility for each node doing work on the network. Note: 100 may not be necessary. This can be parameterized by governance.

3. Each validator can assign a score between 0 and 1.0 to each node.

4. The median score for a node, will determine the % of rewards that node is eligible for. A median score of 1.0 means a node is doing honest work and earns 100% of their eligible rewards in proportion to the fees they generated. A score of 0.0 means they receive 0% of rewards. A score in between, say 0.5, means they receive 50% of the rewards they were eligible for.

This mechanic directly implies that if a node is perceived as not doing any work, only self dealing itself work, or actively harming the network by performing incorrect work, there is a decentralized mechanism to set their rewards to zero.

The validator is a new role in the Livepeer network. Though it is worth considering whether our existing orchestrator set, of which there are 100, already elected by delegated stake, should inherit the slots initially for continuity.

Validators and their delegators will earn a portion of network inflation that is determined by governance parameters, and the same reward cut mechanic can apply. However, it is worth noting that the majority of inflation should be flowing to node operators who are doing work in the BME model, and instead governance will determine the minimum viable compensation for validators necessary to secure the network with a high quality of service.

How will validators determine the scores to assign to nodes? As these scores are determined outside of the protocol, there are countless ways, ranging from naively assigning only 1.0’s and 0’s based on observations, to running testing frameworks to evaluate nodes, to observing onchain data from known gateway users as a proxy for real usage, to deploying agents to assist in the scoring, and many creative options beyond in the arms race against attacking nodes. It’s up to validators to campaign on and share their methodologies in order to attract stake. It’s up to delegators to elect majority honest and well intentioned validators.

I envision this area is the ripest for community driven contribution and development. A whole slew of dashboards, transparency reporting, testing frameworks, scoring agents, community communication standards, can all be built out and developed to assist in these processes - which secure the quality of service of the network. In the end, the goal is that nodes doing real productive work to help the network earn LPT rewards, and attackers do not.

Fixed Bond Requirement Per Node and Longer Capital Lockup

Addressing the last two closely related protocol updates together: one of the biggest pain points for the network so far has been that many have felt like the majority of rewards were being earned by large delegators and node operators who were not actually productively doing work. This is because rewards were flowing in proportion to stake, rather than fees earned. The intention was that more stake would equal the opportunity to compete for more work, though this broke down as the network transitioned away from transcoding only, and required high QoS for diverse job types. To address this issue, I suggest the following changes.

1. Separate out the concept of a node, from the stake elected validators, and drop the 100 node limit.

2. Anyone can buy a node slot with a fixed LPT bond. (For example between 10K-50K LPT). If you have excess stake available, then bond again to run nodes in multiple slots. Though each node is subject to validators reward ratio scores independently.

3. LPT rewards are delivered in a liquid and unbonded state in proportion to fees that the node earns in a round.

4. Extend the unbonding period significantly, for example to 90 rounds or more, ensuring a long term alignment amongst node operators, and a harsh capital lockup penalty for misbehaving nodes.

Given the long capital lockup, and the fact that all nodes are subject to validators scores, there is a strong deterrent to bond for a node slot unless you intend to do real productive work and compete for rewards. Non-performing “ghost nodes” would see their reward ratios set to zero, yet they wouldn’t be able to access their LPT to switch to another anonymous ghost node, nor to cash out, for the extended unbonding period. While you could see operators taking this risk for one node, it would be unlikely they’d commit significant stake and capital for many nodes after they’ve learned their lesson.

As LPT rewards are paid out in liquid form, node operators can accrue LPT and consider running more nodes in the future, or use the LPT to cover their cost without having to incur an unbonding period.

Regarding the intention of more LPT equates to more work, this one requires some nuance to consider. Pure stake based job selection is a non starter for the quality-of-service reasons mentioned above. With every node posting a fixed bond amount this takes stake on a per node basis out of play. However with Livepeer agent being the primary allocator of work on the network, the best chance of an operator getting assigned a job is having more nodes available for that agent to choose from.

Agents will naturally optimize for redundancy, failover, performance history, latency, locality, and more criteria - all of which are bolstered by having multiple registered identities, and ideally a diverse set of capabilities, geographies, and performance/price characteristics. Savvy node operators will learn how to optimize their setups over time, and even if the many node identities and bonds are delivered by one common set of infrastructure, this is still a good proxy for more stake == more work. Those node operators are risking more capital with long term lockup. As the network usage grows increasing fees and LPT value, there is more incentive for operators to buy LPT in order to bond for additional slots, creating an LPT sink in the process.

How much bonded LPT will be required for a slot? This is a parameter which can be set by governance, and can start low and rise over time based on LPT float and network demand. It may be prudent to consider a bonding-curve type approach where each subsequent node slot is more expensive than the previous, though unregistering a node reduces the price back to the previous value.

In Summary

Livepeer has an incredibly strong starting point to be well positioned for a future in the agentic-first media and infrastructure world - a widely distributed token with market integrations incentivizing a great community, a robust technical video stack supporting both generative AI capabilities and traditional video compute, and highly competent node operators who flexibly deploy local compute and can orchestrate 3rd party services to back the needs of the media agents of the future.

Building on these strengths, the proposed changes in this Livepeer 2.0 vision combine a product that enables a direct go to market for the Livepeer network accessible to millions of agentic-first users out there, with protocol updates that ensure incentive LPT only flows to those that are doing real productive work, and value is captured by LPT as network usage grows.

There is a lot to spec out and build to deliver all the moving parts of Livepeer 2.0 - especially the dramatic protocol incentive changes. But the good news is that product validation, a go to market, and network growth are completely unblocked today - Livepeer Agent can be used, and network usage can grow, prior to the full token economic overhaul.

I personally think this is a long overdue set of cohesive updates for the Livepeer project. It sets us up with a clear mission for an agentic-first future, and attempts to align the right incentives and value capture around the token. I look forward to pushing hard on this, at a fast pace, to bring it into reality along with the rest of the Livepeer community.

-Doug

—–

A note on feedback on this thread: The above proposal is enormous in scope, and any point mentioned could be worthy of a paper and long subsequent discussions. There are many open questions, of which I have some strong opinions on answers, but also require community input and feedback on, such as:

• What is the role of delegation in helping to activate new nodes who haven’t invested in stake?

• Should our existing Orchestrator set automatically inherit the validator slots for continuity?

• What are the BME params and the updates to the inflation issuance curve?

• If we remove the 50% participation target and participation drops significantly, is that actually a negative impact or a non issue?

• What should initial param values be for the fixed-bond to run a node, or the length of the unbonding period?

• What’s an acceptable payout level target for the validator set?

• And more!

I encourage people to share any support, concerns, confusion on the broad vision in responses within this thread. But as for collecting feedback, ideas, and debates on individual mechanisms such as the ones mentioned above, please let’s take those up in topic specific threads where they can get the attention they deserve without detracting from the big picture opportunity. I’ll be creating a couple of these threads shortly in the coming days, but others can feel free to ask specific questions in new threads as well that they create.

[chrishobcroft]

Hey - really into the Livepeer 2.0 direction, and using a stake-elected validator community to solve the “you can’t cryptographically verify AI work” problem is a clever move.

There is one thing that keeps coming up in my mind, and I’d genuinely like to understand the design intent:

If node rewards are LPT minted in proportion to validator-assessed fees, then the rational play, for a node and for the validators scoring it, looks like concentrating on whoever generates the largest, most reliable stream of fees. That gives a healthy “reward the useful nodes” loop, which is great. But I can also see it quietly starving the long tail: niche capabilities, brand-new operators, and small or experimental users whose demand is real but tiny.

As someone building a small, single-purpose service on the network, that long tail is exactly where I live - and I’d argue it’s a big part of what keeps the network resilient and interesting, since it’s where new capabilities get proven before they’re “hot.” A “breeding-ground” if you will.

So my honest question: are there mechanisms envisioned to keep it worthwhile to serve diverse, small, and emerging demand - not just the biggest fee source? e.g. anything that rewards breadth of demand served, capability diversity, or availability to low-volume users alongside raw fee volume?

Not a gotcha at all - I think it’s very answerable, and I’d love to see it considered early rather than discovered later.

[j0sh]

This is all very exciting, and I love seeing the ideas percolating here.

These are large changes in protocol mechanics amidst a rich design space. I appreciate how deeply some of these issues are interconnected and how the proposed solutions build off one another. A couple things that stood out to me:

USD

Very happy to see that that USD payments are now potentially an agenda item.

Is the thought to have PM be denominated in USD rather than ETH, or a larger change in payment mechanics? FWIW: I believe we can preserve many of the properties that makes PM well-suited to Livepeer, while moving to a deterministic “accrual” mechanism for payments (in any currency).

A large increase in the orchestrator set may affect payments (eg, reserve) … so a lot of interconnected things to evaluate.

Validators

Looking forward to learning more about how validators would avoid the same types of concerns that some folks have with orchestrators; that is, non-performing validators which don’t do much other than piggy-back on the findings of others.

With LPT rewards as a proportion fees, zero fees mean zero rewards. This feels like it moves the validator towards determining eligibility for fees rather than rewards. The shift might sound subtle, but the implications are deeper when it comes to enforcement.

One way to narrowly test-drive the validator concept without protocol changes would be to have orchestrators that test other orchestrators, rather than offer organic GPU capacity. Those tests could be executed as ordinary jobs on the Livepeer network by anyone, including the testers or orchestrators themselves. (There’d actually be two layers of paid execution on the network: the tester’s own test, and the workload on the target orchestrator.)

That gives “test orchestrators” a source of income functionally similar to a validator (rewards + any leftover fees) and could be funded by existing processes. Anyone could pay to run a test, or the tester could apply for grants, Treasury allocations, etc. Self-dealing doesn’t have to be a bad thing if fees accrue network value, which they would through BME.

Testers could publish their findings (just as a validator would) and gateways or discovery services can then act on those, eg by withholding traffic from misbehaving nodes. Paired with fee based rewards, misbehaving nodes would effectively be zeroed out if they don’t receive work.

There’s already testing precedent, for example the NAAP dashboard, but having NAAP probes themselves be paid jobs on the network would complete the circle in a world where rewards are based on fees. At this point, a separate validator set seems almost extraneous, unless we wanted protocol-enforced mechanisms to deny fees.

Staking, Fee Based Rewards and the Inflationary Schedule

One part that I’m unclear on is the role of staking in a fixed bond world. Is the bond capped? With potentially thousands of nodes on the network, trying to allocate and track stake sounds painful, especially if the stake needs to be split among many nodes due to bond caps.

Very curious to hear more details of the proposed inflation schedule. Perhaps this is me being crusty, but I confess to liking the current inflation system: it offers a hands-off mechanism to modulate token liquidity, rewards network participants over the long term, and acts as a signal for participants’ network confidence. Preserving those properties would be nice in any revised schedule.

Having token rewards be tied fees is a great idea. Having it tied to stake can still be helpful for protocol mechanics. So, why not both? Eg: rewards = mint(min(fee percentage, stake percentage)). LPT rewards in proportion to fees, up to the proportion of their stake. I’m imagining that the mint would keep the current inflationary schedule, but this can be tweaked.

An orchestrator with 5% of LPT staked would be eligible to earn up to 5% of rewards as long as they process at least 5% of fees. This has the effects of

1. Preserving the current staking mechanics
2. Having stake better reflect work capacity
3. Encourage delegator movement: a high-performing orchestrator with low stake is more attractive than an oversubscribed orchestrator which has a large stake but relatively little work.
4. Further decreases the real inflation rate if unqualified rewards are simply never minted.

Adversarial self-dealing is still possible in this scenario but really only economical with BME if the marginal price of buyback LPT increases more than the value of the emitted rewards. In theory they should balance since those rewards need to be cashed out eventually, but who knows.

Of course all this is just a sketch based on some thoughts after yesterday’s presentation and there would be many, many details to consider for any proposal. Looking forward to learning more.

[hthillman]

I am in favor of most of the tokenomics upgrades proposed, particularly the Cobb-Douglas-inspired reward distribution.

I’d echo Josh’s point about USD payments. Managing payments with an unstable asset like ETH is an accounting mess. I understand that some orchestrators prefer to be paid in a non-sovereign asset, but almost no application developers or companies manage their finances in ETH. Even if gateways vary their payout based on the fluctuating price of ETH to maintain a stable USD value, they still have to deal with managing ETH purchases in a volatile FOREX market. Most end users will never do enough volume to participate in futures markets, so unless/until we make stablecoin payments a first-class citizen we are foisting extra operational complexity onto users of the network. I’m sympathetic to the censorship-resistant and cross-jurisdictional properties of ETH and similar native assets, but I believe network usability for demand-side end users should be a priority.

[kilout]

The agentic gives Livepeer exactly the kind of story it’s needed. Open infra behind the media agents everyone will be using.

One point I’d flag on the validator set: subjective 0-1.0 scoring by a stake-elected committee seems vulnerable . The rational play for a validator is to piggyback on others findings rather than do costly evaluation work themselves. And since the final score is a median, if most validators passively copy each other, the median reflects the herd rather than actual node quality. j0sh’s suggestion of test jobs as ordinary paid work on the network feels more robust. It produces verifiable data instead of opinions… and builds on precedent that already exists (NAAP). A hybrid could work well -objective testing frameworks as the baseline, with validators only stepping in to arbitrate disputed cases.

Still plenty to work out on the bond/BME details, but the direction is right and it genuinely makes me excited about where the network.

Great work all !

[Pon]

Thanks for putting this proposal together. I like the general direction of Livepeer 2.0, especially the idea of expanding beyond transcoding into broader AI/video workflows and making LPT more directly connected to real network usage.

I have a few questions around the mechanics, because these details seem very important for making the transition fair and safe.

First, on stake locking and delegation: would it make sense to let delegators choose different lock-up periods? For example, someone who is willing to lock their stake for longer could receive higher rewards, while someone who wants more flexibility could choose a shorter lock-up with lower rewards. This might give delegators more choice instead of putting everyone into the same structure. How would lock-ups work for delegators compared with node operators?

Second, this seems like a major change from the current Livepeer model. How do we make sure the network does not get stuck halfway between the old orchestrator/delegator system and the new validator/reward system? Is there a clear migration path with phases, testing, fallback options, and clear criteria before each step goes live?

Third, if validators are responsible for judging which nodes are useful and therefore influencing rewards or penalties, how do we make sure that process is fair? What prevents validators from copying each other, favoring certain operators, penalizing others unfairly, or being gamed? Should validators themselves be checked by other validators, hidden test jobs, audits, or some kind of reputation/slashing system?

Finally, I wonder about reward concentration. If there is not enough real job volume, or if job routing naturally favors the biggest GPU providers, rewards could end up concentrated among a small number of large operators. Some concentration is probably expected if an operator provides great service, but too much could hurt decentralization. How will smaller operators or specialized providers still get a fair chance to participate and earn?

Overall, I think the direction is promising, but the details around delegation, migration, validator accountability, and fair job distribution seem critical to making it work in practice.

[dob]

Thanks to everyone who has taken the time to absorb and reflect on the initial Livepeer 2.0 vision. Between this thread, the presentation, Discord comments, and the Google Form responses we’ve received quite a bit of feedback from our community - the people most invested in operating the network, staking and delegating, and building out its core capabilities. Rather than respond line by line to very specific details of mechanism-level feedback, which can all be done in time through various topic-specific threads and community calls, I’ll try to draw attention to the common themes and biggest challenges that we have to address.

On the positive side, some themes that were most universally well received included:

• Livepeer Agent: People expressed strong enthusiasm for the Livepeer Agent demos. They saw how its role in orchestrating complex, end-to-end media generation workflows can increasing the network’s utility within the agent ecosystem. Initially many people didn’t fully grasp that the agent was an MCP server that can be talked to through Claude, Codex, GPT and other harnesses. It would then use the network to execute the compute capabilities required. But upon seeing a few demos and walkthroughs the idea became clearer and the potential clicked.

• LPT Value Accrual: One of the most commonly referenced positives of the presentation was related to idea of the buy-back and burn mechanism in the BME, which are seen as essential for linking LPT value to real network usage and addressing long-standing utility issues.

• Validator Set in judgement of non-performing nodes: Many people who have long observed LPT rewards flowing to non-contributing nodes expressed positivity about the idea of the validator concept and its role in subjectively applying judgement in terms of node rewards eligibility. Though see below on the challenges section, where its clear more specific details are needed before gaining confidence that the mechanism will work.

• Tangible use cases and GTM: People appreciated the fact that the go to market for the network itself addresses tangible use cases in large markets that are here today, like media creation and editing.

While the above are great signals and certainly key motivators for the 2.0 bundle of concepts, there were also many points of question, concern, clarification raised across the feedback. These largely fell into three buckets:

1. Are we building the right thing?

2. Are the protocol mechanics and incentives sound?

3. Can we actually execute this?

Strategy: Are we building the right thing?

There were a couple of common themes that came up in this category. Some centered on whether this was just another Livepeer Inc driven bet on a niche market that doesn’t expose what the network can actually do? Other people proposed different directions such as exposing a raw GPU rental marketplace, rather than an agentic-first media capability marketplace.

All concerns on this front are valid to raise - until we have product market fit and exit velocity in terms of constantly rising network usage, everything is just a hypothesis to be tested as fast as possible. Still, the hypothesis around Livepeer Agent isn’t rooted in a whimsical guess - it’s rooted in a year+ of engaging directly in the AI media market, including hundreds of conversations with different user personas in industry, direct product GTMs for products like Scope, Daydream v1, Daydream Music, and events in collaboration with leading AI media communities including Touch Designer, StreamDiffusion, ComfyUI, and more. It’s evident that:

1. Media creators are using Agents to assist them in their process

2. These agents need access not just to a few specialized models or workflows, but multi-modal set of capabilities that get composed into final outputs.

3. An open, configurable, and controllable version of these media platforms needs to exist and brings unique advantages as alternatives to the big, proprietary players.

However, despite the above reasons why it is compelling to work on this problem, I do think there are two misconceptions around Livepeer Inc ownership and the raw network capabilities that are worth clearing up and addressing head on.

1. Livepeer Agent is an open source, project-owned, piece of software. It is not the business or product of any specific company, including Livepeer, Inc. You can think of it as analogous to what has previously been referred to as The Livepeer Gateway node. It’s an open source set of logic that knows how to discover and use capabilities on the LIvepeer network. It can connect direct in a self-sovereign way (work to do on productizing this to make it really easy), and it can submit payments direct to the nodes on the network. Anyone can build on top of Livepeer Agent to create what they want in a permissionless way.

2. The raw capabilities of the network exposed by node operators are directly accessible and open access. At its core, the Livepeer protocol is an onchain registry of discoverable nodes who are marketing their compute capabilities. Gateway nodes know how to discovery, request work, and pay these nodes. And that is directly accessible via Livepeer Agent, or any additional custom node built on the protocol. This remains available for anyone to build any vertical specific project they’d like on the network.

While there are lots of strategy questions around marketing messaging, which wedges to try to validate with first, etc, hopefully it’s helpful to clear up that Livepeer 2.0 enables a direct GTM for the network and project itself, rather than for any specific company’s product. And that the 2.0 vision doesn’t preclude anyone from openly building on raw capabilities exposed by network nodes - Livepeer Agent only increases in the discoverability and usability of these capabilities by other agents, rather than all needing to be marketed to developers through APIs.

Lastly, there were strategic questions raised around nodes calling third party services, and whether that can work out economically or presents any terms of service risks. The legal analysis track is real, and nuanced, and is future work that needs attention. While it’s clearly within the TOS of various media services to make inference calls where the results get combined and composed into products such as Livepeer Agent, it is against some companies’ ToS to merely mark up and pass through their service responses directly as a business without a reseller agreement. Ultimately node operators will want to be comfortable with their own use of third party services, the uses they are powering, and how they are pricing/marking up their various exposed capabilities.

As far as the economics of API passthrough, it’s probably helpful to look at the bootstrapping phase, and the scale phase separately.

While bootstrapping, inflationary LPT rewards earned by node operators in proportion to fees likely outpace the fee value itself. Pricing API passthrough at cost, or even a discount to earn the work becomes attractive to compete to earn the LPT rewards.

At scale however, as the majority of the compensation is derived from fees themselves, the opportunity for node operators are in more efficiently serving high quality open source model alternatives on local hardware when demand is there, or on efficiently acquiring 3rd party services relative to the cost that they’d be accessible to a single agent end user - potentially through reseller agreements, bulk purchases, or more. As our node operators have felt, it is painful to allocate a GPU to warm-loading and running a single high-memory-requirement model prior to its scaled usage. By using API passthrough initially, node operators can gauge when there is enough demand and earning potential to instead try to serve the model locally, (or an open source alternative), and set their own price. At the end of the day, even if some of the API passthrough is done at or close to cost, it’s still a valuable capability for the network (and hence LPT), that justifies the node operators earning their share of LPT emissions for providing the service.

Design: Are the protocol mechanics sound?

Most of the feedback from our dedicated orchestrator community focused on the protocol design mechanics, the incentives, and impacts to current orchestrator earning. This is naturally the area of greatest concern for them, and the overview proposal didn’t hone in on the details needed to glean concrete answers to open questions. These details matter, but it was by design that they were not committed to, because they are the exact thing that require community input and a community oriented process, rather than being dictated by one small group of people putting together the initial conceptual proposal. Highlighting a couple key areas of feedback:

BME params. Is burning 70% of the fees sustainable? 70% was only an example number and by no means meant to be the initial parameter. The BME params are governance determined, and should derive from the learnings and observations of other similar DePIN protocols, as well as community input during dedicated tokeneconomic threads and feedback calls.

Validator trust. Who is validating the validators? Will they just piggyback off one another’s subjective scores, and should they be running test harnesses instead? Will they redirect rewards away from long tail service providers and only to a subset of providers of the most in demand services?

Introducing a new role is a major change for the protocol, and comes with all sorts of economic honesty assumptions. If it’s the job of LPT holders to elect majority honest validators, and those validators are aligned with long term LPT value growth, then are those strong enough trust assumptions that we are willing to live with? If so, then many of the details around the best validation techniques can emerge from the market itself - stake will move towards validators that are helping the network with honest and accepted techniques.

Though through the community feedback process one thing that we should do is arrive at a set of guiding principles that we ratify that dictates what desired validator behavior is - much like we’ve ratified treasury funding principals through LIP-90, or governance process through LIP-1. For example, we could ratify which types of behaviors warrant decreasing a reward ratio below 1.0 - maliciously serving back incorrect responses, self-dealing fake work while not serving public traffic, etc. We could ratify validator transparency expectations. A list of socially approved expectations and commitments would give validators a pattern to behave against, delegators a pattern to point to in their decision making, and builders of the validator tooling an pattern to design around. Let’s address this in a dedicated thread and feedback session as well.

Orchestrator earning potential. The protocol changes obviously need to move from broad themes to hard specification and initial parameters. A starting point spec will be produced (following community feedback on key inputs as mentioned above), and then two tools that we’ll use to go from abstract to concrete include prototyping/simulation and modeling.

We’ll plan to build out an initial prototype of the protocol so that agents can play the roles of validators/delegators/node operators/users and simulate what can happen over the course of rounds in an observable way. But we can also take the candidate spec and map out models in sheets that show earnings over time given different assumptions about rewards, fees, stake, node counts, and more.

While the above will help all actors get a sense of how things will play out over time, I have a strong perspective that the following is true for the initial 2.0 protocol launch as conceptualized: If you’re running a node that is doing real honest work on the network in service of real demand, you have a very clear path to earning more than you do today. Why is that the case?

First of all, recognize that you are already essentially playing the role of both validator and node operator. You participate in governance, run a process that makes daily reward calls on chain, and vote on treasury proposals. You’re doing the subjective validation type of work and automated participation that keeps the protocol running. While you’re also bringing compute capacity to meet the demand on the network in a valuable way - essentially the node operation and capability marketplace participation.

Currently LPT inflation is the majority of compensation, and it is distributed largely according to stake. In the world where current node operators compete in both roles, they are retaining their stake-allocated inflation portion from validator rewards. And if they’re honest actors doing real work currently, then they are likely dramatically increasing their LPT inflation rewards on the fee-based portion earned by node operators. This comes at the expense of the nodes that are not competing to perform any useful work. To be modeled - but we may actually be able to decrease the inflation rate initially, while rewards for the honest, high performing node operators actually increase.

Delivery: Can we execute this?

The last main feedback theme was around concern the scope of this enormous bundle of updates, and whether we can actually execute it? This is fair, as the community has seen many smaller ambitions fail upon execution over the past few years. Livepeer 2.0 bundles major updates across project narrative and marketing, product, network capabilities, protocol, and more - it represents a large scope! Here’s why I’m optimistic about getting started down this path.

The most important recognition here is that the validation of Livepeer Agent as a product in market is unblocked to proceed today. The Livepeer Network already has a runtime that can offer many diverse media compute capabilities. The Livepeer Agent prototype software already exists and can be used with Claude/GPT/Codex today to create real media assets that solve real problems for users. The media market is exploding today in their demand for AI-assisted content tools. There is lots of iteration necessary to get the product right, scalable, reliable - but there is nothing stopping us from validating that users love and need this product. And a team is already working on that, working with users, conducting interviews, and sharing back success stories.

All else follows from this - the product can iterate. The network software can get upgraded to make it easy to onboard more node operators. The protocol spec can be designed, built, tested, and rolled out over time to supercharge these capabilities backed by the best incentives we can deliver. It will be orienting for everyone across the community to contribute, but it all follows from demand, usage, and growth - and that does not require a tremendous build in advance.

Each player in this ecosystem has their own expertise and clear areas they can contribute. LPT value capture follows demand, and that helps boost the treasury and public goods funding (as well as private funding) available to reinvest into the mission.

In many ways this is closer to the launch of Livepeer initially, under an exciting updated mission, then it is to one of the many incremental updates we’ve made along the way. And when we launched Livepeer initially, a community of global people came together to undertake a far more ambitious scope than the above, in less than a year’s time.

I know that the community would love to see an execution plan. We’re putting that together across product and GTM validation, network engineering, protocol, and the token ecosystem. More to come shortly on the plan across those tracks.

In the meantime, now that feedback has been thematically addressed, it’s time to dive into the details. Within the next 7 days, look for topic specific threads to emerge, as well as the first events on the schedule to be posted for community-centric feedback and design sessions. I’ll also start answering specific questions more directly in these topic threads, as we move from the high level, down to the real problem solving.

Thanks everyone who took the time to share responses already. I’m looking forward to getting going on building this out!

[Authority_Null]

Thanks for putting all of this together. It’s motivating to see there’s still drive and excitement from key teams to move Livepeer forward. The bulk of my feedback was left on the survey but my main point of concern from a very high level is around the continued focus on very niche use-cases where the network wants to be positioned for the path of most resistance, continuing to make bets on markets that don’t really exist yet (decentralized transcoding, real-time AI, AI media gen). I’m cautiously waiting to see the plan for GTM and demand gen, and how orchs and protocol participants like myself can move fast to accommodate and take on new roles to help Livepeer win.

[Wiser]

Thanks Doug, and to the whole team, for putting this together and pushing this forward. It’s genuinely encouraging to see this level of drive and long-term thinking going into securing the future of the network. I want to voice my support for the overall direction, even if, as someone who’s been running as an orchestrator under the current system, a lot of the finer mechanics here are still not fully clear to me yet.

One thing I’d like to flag, and I know others have touched on this too, is the validator scoring mechanism. If judgment ends up being the deciding factor in who earns rewards, it’s critical that this judgment stays fair and actually reflects a balanced view across the validator set, not just a handful of dominant voices whose scores get echoed by everyone else. A median score only means something if the inputs feeding into it are independent and honestly arrived at rather than copied from one another.

But beyond that, what I’d really want to see is safeguards built in from day one, not bolted on after the fact once problems start showing up. I’m thinking specifically about concentration of validator power, where a small number of validators (or the delegators backing them) end up with outsized influence over scoring, effectively deciding who gets zeroed out and who doesn’t. And on the other side, concentration of GPU and compute capacity, where one or two large orchestrators, potentially institutional players with far deeper pockets than the average community operator, end up cornering most of the capacity and demand, and by extension most of the rewards under the new fee based model.

These two risks feel connected to me. Whoever ends up controlling both large stake and large compute capacity could end up in a position to do the work and judge the work at the same time, which kind of defeats the purpose of separating those roles to begin with. I’d like to see this addressed head on in whatever guiding principles get ratified for validators, and ideally some real anti concentration mechanisms thought through in the initial spec rather than something we try to patch in later once the incentives are already locked in and hard to unwind.

Looking forward to the topic specific threads on this, happy to keep contributing as things get more concrete.

[kilout]

Strongly agree with Franck ! And honestly, imagine Vultr, just pointing some of its idle GPU at the network. That hardware is already sitting there depreciating, so the cost to them is basically zero, and they’d have deep enough pockets to bond as many node slots as they want.

For them this isn’t a livelihood, it’s an infra utilization play. So there’s nothing stopping them from farming LPT rewards at scale and dumping them whenever it suits their balance sheet. We’ve seen this pattern before in other networks: an actor with no long-term stake in the token’s health extracts value fast and leaves the community holding the bag. A community operator would never do that. A hyperscaler has no reason not to.

That’s not a hypothetical edge case, it’s a real incentive to actively farm and dump the network into the ground if the door is left open. And it’s the opposite of what decentralization is supposed to protect against a handful of well capitalized players ending up with disproportionate control over both compute and, indirectly, judgment. This is exactly why anti concentration safeguards need to be part of the initial design, not bolted on after a player like that is already embedded and earning at scale.