Livepeer Delta Phase Pre-Proposal
By Doug Petkanics (@dob)
This pre-proposal bundles a bunch of suggested Livepeer project updates together that focus on the decentralization and sustainability of the project. It includes a mix of potential actions ranging from on chain protocol updates, to socially enforced conventions, to recommended experiments that the community can run and learn from. The goal of the proposal is to bring Livepeer to its next phase - Delta - which solves for ongoing sustainability of funding for public goods within the Livepeer ecosystem, as well as further decentralizes the governance and controls over both the protocol and the funding mechanisms. At the core of the proposal is the introduction of a Livepeer treasury for public goods funding, and candidate governance mechanisms to allocate this treasury sustainably. The proposal also addresses the security committee and governing multisig and considers a path forward on that front.
A note on the “Pre-Proposal” status of this draft
In the spirit of transparency, and the build-in-public ethos of the Livepeer project, this pre-proposal is being shared for feedback in the Livepeer Forum. We should also hold open community calls to discuss live. All feedback will shape an actual proposal, which works its way through the LIP governance process towards community vote. Please share your thoughts here, or across the various channels and live discussions to influence the final proposal. This is the beginning of a longer road to get everything in this proposal live.
Background and motivations
Livepeer has been on its Path to Decentralization since the network launched 2018, and while the timelines in this linked post aren’t exact, the spirit behind the journey is still very much alive. The history can be gleaned from all of the public content on Livepeer’s network upgrades, governance, and ecosystem expansion, a quick bulleted summary of the state of decentralization is as follows:
- Decentralization of stake was aggressively taken into account from network genesis, with a vast majority of token being distributed via the MerkleMine algorithm from day one, and over 180% of the initial token supply being distributed openly and permissionlessly towards contributing network participants through inflation funding over the past 5 years that the Network has been live.
- Decentralized protocol governance was introduced in 2020 and enables stake weighted delegated voting for protocol updates, parameter updates, and governance updates.
- A security committee which executes updates and is responsible for fast response to critical protocol bugs remains in place, and has been a key source of debate in the community.
- Livepeer has no treasury from which the community nor core team can allocate token for growth.
- On the decentralization of technology front, the network is fully decentralized run by 100 node operators, many pool members and thousands of token holding delegators around the world. However to make this totally trustless and void of reputation based inputs, research progress on the fast+full verification method still needs to progress.
As mentioned above, without a treasury to pull LPT from to reward community contribution, Livepeer relies on inflation funding. It routes LPT to node operators and their delegators based on stake. Many individuals and teams have used this mechanism to build stakes in the network, grow their ability to win work, and to fund projects. It’s been particularly effective at rewarding orchestrators who run nodes on the Livepeer network for their contribution in powering the infrastructure. But it has its shortcomings and hasn’t proven to be sufficient to ensure sustainability of the project from a public goods funding perspective, nor enough to help catalyze multiple independent parties to become core contributors across all vectors of the project - especially demand side application builders.
In an ideal future state, video technologists and application builders are also stakeholders in the Livepeer network, and are motivated to build projects that help drive demand to the network and increase the video capabilities of Livepeer. Orchestrators also need to feel that they have the incentives and mechanisms to reward contribution to the supply side tooling, technology, and capabilities, and are rewarded accordingly, beyond just their ability to compete for and win ETH fees on the network - which are demand constrained and are correlated with stake moreso than contribution.
To date, the grants program, as powered via inflation funding and the community node, have attempted to fill this gap. They’ve awarded LPT to many recipients, and funded many video innovators, application builders, ecosystem growth initiatives, and more. But the program is run by a small group of community and core team administrators, there aren’t clear mechanisms for broader Livepeer holder governance, and the LPT available via the inflation funding mechanism and reward cut remain limited in their ability to help Livepeer further decentralize stake amongst meaningful demand side contributors.
While inflation funding is a valuable mechanism, it is clear that for the project to be long term self-sustainable, additional mechanisms for public goods funding, that are decentralized and community governed, should be considered.
Pre-proposal - Livepeer Delta
This proposal recommends
- The introduction of a community governed, on chain treasury
- A suggested first set of experiments for allocation of the treasury to accomplish goals around video builder community growth and more equitable orchestrator rewards
- A mechanism which the community can directly control the security committee, including adding/removing members, or eliminating it altogether.
The Livepeer Treasury
I suggest the introduction of a Treasury smart contract into the Livepeer protocol. It will hold LPT and other assets which will be community governed. The purpose of this treasury, and its accompanying governance, will be to enable sustainable funding to help the LIvepeer network achieve its mission. Public goods funding for contributions direct to ecosystem tools and services is one useful target of treasury funds use, but other uses may be appropriate as well such as more effectively routing LPT towards the video builders and applications that are built on top of the network and drive demand. While this proposal does make some suggestions as to the first use of treasury funds, it will ultimately be up to the governance of the Livepeer community to determine the use of treasury funds.
How will the treasury get populated?
LPT (or other assets) can get into the treasury simply by transferring them to the treasury contract address, so there are a number of potential sources of funds including grants, donations, ecosystem partnerships, and more - however this proposal makes the case that the protocol should directly fund the treasury out of inflation.
I suggest the introduction of a parameter
TreasuryContributionPercent. The value of this parameter could be debated by the community, set, and changed using regular governance proposals. During round initialization the protocol would look at how many LPT are available to be minted in the current round, multiply this number by the TreasuryContributionPercent, and then route that amount of token direct into the treasury. Orchestrators reward calls would then split up the remaining available tokens according to the existing protocol logic.
This change would have no effect on the total LPT supply, so would not violate any expectations of existing holders. However it would mean that O’s and D’s daily rewards would be lowered by the
TreasuryContributionPercent. For example, if an O generated 100 LPT in a given round at a 0% TreasuryContributionPercent value, and the parameter were set to 15%, then they would only generate 85 LPT, with the other 15 LPT being routed into the treasury. Each round the treasury would grow, creating a sustainable and ongoing mechanism for ecosystem growth and development. Why would O’s and D’s prefer this?
- It would be up for them to decide whether the project is more likely to succeed, and therefore be more valuable, if there is a sustainable public goods mechanism built into the protocol.
- Do they value governance control over that treasury, accompanied by the ability to propose, vote, and route funds towards causes that may help their participation in the network - such as demand generation or tooling?
It is also up to them to determine the value of the parameter, and to change it over time. A value closer to 0 would maximize short term O and D rewards, and may be appropriate if the treasury is full and project is thriving via non-incentivized contribution. A higher value gives the community more power to bootstrap and incentivize contribution.
(Point in time comment on the above example: with participation rate dropping from 51% to 44% recently, O’s saw their reward generation increase by approximately 15%. While definitely deserved and appreciated amongst the hardworking O’s, it might be a good time to “take the medicine” knowing that rewards will basically return to what the median expectation was just a couple short months ago around a 50% participation rate.)
One additional question is whether the existing community grants node or other sources would want to route any existing funds into the treasury initially. (More below on the grants node).
We’ll leave modeling around different impacts and values of different rates for discussion and threads outside of this proposal, but it should definitely be an input into community decision making.
How will the treasury be governed?
The following section addresses some recommendations for some of the early potential uses and tests the community can run around allocation of treasury funds, but this section presents a simple governance mechanism rooted in the protocol.
Simply put: transactions executed against the treasury smart contract (which will mainly just be transfers of LPT or other assets from the treasury to another address) will be executed via Livepeer’s existing decentralized governance, and automatically executed via the result of governance vote, following the existing proposal and voting rules.
A new type of governance proposal will be added to the governance module - a treasury txn. When making a proposal, a user can create this treasury txn (likely a transfer of LPT or other asset), and initiate a vote. If the vote passes quorum and the majority voting threshold, then it can be executed on chain, not requiring any intervention of the security committee. This has the advantages of being:
- Efficient implementation, leveraging existing governance precedents in Livepeer.
While it has these advantages, it suffers from many of the weaknesses or critiques of stake weighted delegated voting. This is why it’s important to emphasize that the spirit behind this proposal is that this mechanism IS NOT how I would recommend funds actually get allocated to specific recipients from the treasury. Instead, I would propose that the convention be a two-tiered system:
- Proposals would come into the treasury governance mechanism described above to route funding into entities (DAOs, committees, sub-governance modules).
- These tier 2 entities would use more judicious, efficient, or purposeful mechanisms to route funding to individual projects, causes, or recipients.
Tier 2 Treasury Governance Entities
Given the flexibility of the above tier one proposal mechanism, many different tier two entities can emerge over time. I’d recommend that the community start with a simple set of experiments initially, to learn what is effective, what the needs are, and can evolve from there. I would propose two initial tier 2 entities: one focused on proactive funds allocation, and one focused on retroactive funds allocation. To make it even more focused, I would suggest that the proactive funds allocation be the existing grants program. I’ll briefly address grants, but I think the majority of the creativity and community focus can be on the retroactive funding mechanism described immediately after.
For clarity, proactive funding means allocating funds to actually provide working capital to enable various forms of new contribution - essentially funding ahead of doing the work.
Retroactive funding means providing LPT after the fact to individuals or entities that have already demonstrated meaningful contributions to the ecosystem. While this capital can be used to fund new work, it also is used to enable them to participate more meaningfully in the network, to strengthen their stakeholdership, and feel that their work is recognized and valued.
Both forms have their purpose, though the retroactive funding is a far bigger gap in the existing Livepeer ecosystem, and can serve to address some of the issues that the protocol alone hasn’t solved - like more fairly rewarding external contribution on the supply side, and incentivizing demand side contribution and community engagement.
The grants program has learned a lot over 5+ years, and has a defined set of potential proactive grants for various purposes - video disruptor grants, video builder grants, sponsorships to educate and incentivize hackers to build with and on Livepeer.
I would suggest that the grants program:
- Evaluates a budget to operate with continuity during the rollout of the above treasury, say six to twelve months, and retains that portion of its existing treasury.
- Donates its remaining treasury into the Livepeer protocol treasury
- Shuts down the community node, freeing up a spot for another high performing O
- Expands its committee slightly to include representatives of various stakeholder groups
- Considers itself a tier 2 entity and recipient of allocations from the treasury via tier 1 governance on an ongoing basis going forward. It should produce transparency reports, show the impact of the existing program, and make proposals on a yearly or half-yearly basis to receive additional allocations. It will be up to the community to approve the entity as the manager of the proactive allocations based on its objectives and results.
This mechanism would avoid the stake-toward-community-node-with-50%-reward-cut dance that occurs right now to create a pool of proactive public goods funding, and instead would make it more accountable to the community and more efficient in its operations. It also means that the committee would have some time before it has to propose to the treasury. (~6 months) so that the community can focus more on the retroactive funding mechanisms initially as described below.
We can take the specific internal operational suggestions for the grants program outside the scope of this proposal.
Retroactive Funding Rounds
I think it’s far more interesting for the community at large to focus on the retroactive funding mechanisms, as it addresses some of the needs of the ecosystem, and some of the concerns of existing network operators. Namely:
Livepeer should be the center of ideas, conversation, and innovation around the future of onchain video. But it currently lacks any built in incentive mechanism that rewards contributions on this front - whether through community participation, building innovative applications, or composing LIvepeer technology with other innovative web3 technologies to enable new capabilities that couldn’t exist in web2. Livepeer would be more likely to be at the center of this innovation if Video Builders were stakeholders in the network.
Orchestrators have felt that the stake weighted job distribution, and the stake based reward mechanism, isn’t fully sufficient to reward valuable supply-side contribution. It’s a longer discussion as to why it’s hard to address those critiques without solving sybil prevention and avoiding second order effects to the tokenomics, but in the context of this discussion, retroactive rewards via the treasury could certainly route LPT towards the community-determined subjective high performers and contributors.
There are likely many more opportunities, but these just scratch the surface.
As mentioned, in the future, separate entities could certainly run effective programs around these specific goals, but as a start I would propose keeping things simple, and having one entity propose to run multiple Retroactive Public Goods Funding (RetroPGF ala Optimism) rounds, one at a time, focused on the above goals. For example:
- RetroPGF makes a proposal for a treasury grant to use to run two rounds of retroPGF.
- The first could be targeted towards orchestrators. The badgeholders who vote on the round will be O node operators with one node one vote. Total recipients will be 20. Timelines will be X, mechanisms will be Y, the platform used to administer this DAO will be Z.
- The second could be targeted towards demand side video innovators - applications, technology partners, and individual contributors who make valuable contributions to push the future of web3 video forward within the context of Livepeer. The badgeholders who vote in the round could be Video Builders role in Discord, one-user-one-vote. The total amount of target recipients will be 30, with X amount of LPT distributed across the group. Timelines will be X, mechanisms will be Y, the platform used to administer this DAO will be Z.
- RetroPGF entity would report back on use of funds, outcomes, learnings and more, and consider further proposals for more tier 1 funds.
To maximize trustlessness and decentralization, the community could require that these subentities are fully set up on chain and smart-contract enforced prior to approving the initial allocations. Or, to maximize speed of execution they could route tokens to proposers and trust that when approved, they would go through the effort to set everything up according to the proposal (rather than doing that work up front with uncertainty). It’s up the community.
An alternative path is that for each goal, independent entities form and use Governor DAOs or other mechanisms to manage and govern their own treasuries, funded via tier 1 proposals. Again, it might be best to avoid this complexity until the community learns more.
This topic is not related to sustainable public goods funding, but is related to the decentralization of the protocol and comes up often. There’s a long history of debate and arguments around the benefits and risk of the existing security committee who reacts to protocol bugs and executes protocol upgrades on chain, and it’s clear that different community members have different valid opinions. It’s best left up to governance to determine its future, so this proposal makes a suggestion as to how this governance could be more hooked into the enforcement of this future.
Simply put, I would suggest that governance transaction types be added to “add security multisig member” and “remove security multisig member.” This way, via simple proposals and voting, the community would have the ability to initiate a self executing txn that controls who is on the committee, or removes the committee altogether. Accordingly, it could update its own social conventions around expectation, transparency, and accountability of committee members.
The above proposal is a lot to absorb and respond to holistically for any community member. Here are some straightforward questions that opinions can be shared on, even just one at a time, that would be useful input.
What would be a useful but justifiable
Stake weighted voting has a number of drawbacks. But it’s also what Livepeer currently has, is supported by many tools in the ecosystem, and doesn’t require us to justify solutions to unsolveable problems like sybil resistance and introduce complex tooling at the tier 1 level. Is the juice worth the squeeze to consider other mechanisms like quadratic voting, or do we trust the tier 1 / tier 2 paradigm to deliver good outcomes?
Related, if the intent is that tier 1 stake weighted governance only routes funding towards entities that can be more judicious about then routing funding to individual recipients, do we think this will be upheld merely by the social convention, or will it be abused by those who attempt to capture governance voting power to move funds in their direction?
Do O’s feel confident they can vote objectively in a process to allocate funds to other O’s based on demonstrated contribution?
The Video Builder (VB) role is more subjective. How do people feel about the notion that VBs would form a DAO, and make a proposal to run a RetroPGF round, to incentivize and reward application builders and other VBs based on contribution?
On a scale of 1 to 10:
1) Design this perfectly and uniquely for Livepeer, and build all the mechanisms and tooling ad hoc over a long period of time. To 10) Leverage existing tools and frameworks to fit with industry convention and get up and running quickly, but accept the tradeoffs that we have less customization and may need to adopt Livepeer’s existing governance a bit.
Where do you initially react?
Thanks everyone for the long read and feedback. Looking forward to discussing this pre-proposal here and on upcoming community calls and chats.