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:
-
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.
-
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:
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!
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:
-
Run open models locally. For popularly in demand capabilities, host and run open models locally on GPUs as nodes do today.
-
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.
-
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.
-
Introduce a Burn Mint Equilibrium model to contribute to LPT supply reduction in proportion to fees.
-
Introduce a stake-elected validator set to determine rewards eligibility for node operators.
-
Remove 100 node operator cap, and replace it with a fixed-bond requirement per node.
-
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:
-
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).
-
Those fees are used to buy LPT from liquidity pools, such as DEX’s, creating buy pressure on the token in proportion to fees.
-
A governance determined percent of that LPT is burned, reducing supply.
-
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.
-
Introduce a stake-elected validator set.
-
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.
-
Each validator can assign a score between 0 and 1.0 to each node.
-
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.
-
Separate out the concept of a node, from the stake elected validators, and drop the 100 node limit.
-
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.
-
LPT rewards are delivered in a liquid and unbonded state in proportion to fees that the node earns in a round.
-
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.