Livepeer Delta Phase Pre-Proposal - Sustainability, Public Goods Funding, Treasury, and Decentralization

[dob]

Livepeer Delta Phase Pre-Proposal

By Doug Petkanics (@dob)

Abstract

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

1. The introduction of a community governed, on chain treasury
2. A suggested first set of experiments for allocation of the treasury to accomplish goals around video builder community growth and more equitable orchestrator rewards
3. 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:

• Automated
• Decentralized
• Permissionless
• Simple
• 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:

1. Proposals would come into the treasury governance mechanism described above to route funding into entities (DAOs, committees, sub-governance modules).
2. 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.

Grants (briefly)
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:

1. 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.
2. Donates its remaining treasury into the Livepeer protocol treasury
3. Shuts down the community node, freeing up a spot for another high performing O
4. Expands its committee slightly to include representatives of various stakeholder groups
5. 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:

1. 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.

2. 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:

1. RetroPGF makes a proposal for a treasury grant to use to run two rounds of retroPGF.
2. 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.
3. 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.
4. 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.

Security Committee

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.

Open Questions

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.

1. What would be a useful but justifiable TreasuryContributionPercent value?

2. 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?

3. 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?

4. Do O’s feel confident they can vote objectively in a process to allocate funds to other O’s based on demonstrated contribution?

5. 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?

6. 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.

[Authority_Null]

Wow, what an awesome write-up.

1. What would be a useful but justifiable TreasuryContributionPercent value?

I think Orchestrators will feel some pain in the short to medium term as we’ll all be making a bit less, but with everything you outlined in the proposal, I see this being worth the decrease in earnings in the long term. I think starting with 4% - 5% is fair and should be enough to build up a treasury quite quickly.

I will note that with current market conditions, taking away inflationary rewards from O’s is the least desired factor of this proposal. If there was another way, we’d want to explore it, but it doesn’t seem like there is.

2. 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?

I like the idea of a multi-layer/teir voting system as the current stake-weighted voting is way off balance.

3. 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?

I believe Livepeer’s community of node operators is something special, and the tier 2 entities will make the right calls under the scrutiny of the greater community. As you mentioned, there may be a possibility for the community to vote in and out tier 2 entities, but I’m not sure how that would work with the current stake distribution.

4. Do O’s feel confident they can vote objectively in a process to allocate funds to other O’s based on demonstrated contribution?

I can’t speak for all O’s, but the operators I’ve come to know and build incredibly valuable relationships with care greatly about the future of the protocol and will make the right decisions collectively.

5. 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?

The success of a VB DAO will depend greatly on who volunteers to lead it, but I think having a self-sufficient governance system for video builders and broadcasters - the 2 categories we need the most - would be greatly beneficial and might be what’s required to spark some innovation.

Just some initial thoughts

Also, I think the idea of shutting down the grants node and making them a tier 2 entity is fantastic! The only critique is that I feel the community of Orchestrators has more of an understanding of what the network needs, and what goes on day-to-day, so I’m not sure if their judgment calls will be accurate.

[Pon]

Hi @dob,
Great proposal and write up! I’ve got couple questions about it:

1. If Grants O will be shut down will LPT be unstaked and send to treasury or it will be distribution between O’s ? If the LPT is unstaked that willl reduce participation rate even more. Follow up question is grant’s node the only node run by Livepeer ?
2. Correct me if i’m wrong but isn’t Livepeer deligating to multiple orchestrators on the network ? if so can’t LPT rewards from delegation be moved straight to treasury let’s say on weekly or monthly basis ?

[dob]

1. If Grants O will be shut down will LPT be unstaked and send to treasury or it will be distribution between O’s ? If the LPT is unstaked that willl reduce participation rate even more.

Caveat: This is my suggestion, but the existing grants committee (which I am not on) would ultimately make the call and incorporate on community input.

When you look at the grants node stake, it consists of self-stake, or “principal” which it has built up over many years through the reward cut, as well as delegated stake from other actors. The delegated stake would likely be unstaked by these other actors and restaked towards other nodes.

My suggestion for the principal stake was that the grants committee would keep 6-12 months worth of grants budget and operate as usual during that period, and donate the remainder into the treasury.

Follow up question is grant’s node the only node run by Livepeer ?

The grants node isn’t run by Livepeer, Inc. While some Inc members are on the committee, it’s run by an independent committee which also consists of and has included non-inc members. Livepeer, Inc does run a couple of low stake nodes on the network (last I checked), primarily as redundancies and to be on the frontline of the experience for dev/debugging purposes.

1. Correct me if i’m wrong but isn’t Livepeer deligating to multiple orchestrators on the network ? if so can’t LPT rewards from delegation be moved straight to treasury let’s say on weekly or monthly basis ?

Again, assuming when you say Livepeer you mean the Livepeer, Inc company. Yes, the company delegates to many O’s.

Though I’m not sure I understand your suggestion around rewards being moved to the treasury. This proposal would automatically route LPT into the treasury from the total reward pool each round, and would not target only specific contributors to public goods funding such as grants node delegators or individual companies/operators/DAOs.

[dob]

@Authority_Null

there may be a possibility for the community to vote in and out tier 2 entities

Clarifying that I don’t think tier 2 entities are permanently added or removed from funding. Instead I would see them just making proposals that release X amount of LPT for Y purpose - and if they want to come back for another proposal, they’re welcome to do so and justify their impact.

So taking the theoretical VideoBuilderDAO, in a proposal they’d say, “Hey, we’re VideoBuilderDAO made up of 50 badgeholders. We intend to run a RetroPGF round in which we allocated 20K LPT across 10 builders/applications that have demonstrated impact towards purpose XYZ. Here’s how it will work and the results we hope to achieve…”, and the community would just be voting on issuing that 20K to their wallet. Not on adding or removing them from ongoing funding from the treasury.

The only critique is that I feel the community of Orchestrators has more of an understanding of what the network needs, and what goes on day-to-day, so I’m not sure if their judgment calls will be accurate.

In full agreement about the power and knowledge of our O community, but in quick defense of the existing grants program - man…have they spent a lot of time understanding and interacting with the developer profile and funnel: hackathons, ecosystem events, builder support, new apps, top apps, VC backed apps, accelerator programs, and more. They have a lot of evidence and data around what types of proactive grants and sizes of grants deliver impact on the demand side, just like the O community has a great feel for the valuable supply side contributions and tooling. I certainly think it’s a good idea to expand the committee to include O representation, but curious if you really still think the O community alone would be well suited to take on a key piece of proactive demand generation programming?

[Authority_Null]

Thank you for the clarification

@dob

In full agreement about the power and knowledge of our O community, but in quick defense of the existing grants program - man…have they spent a lot of time understanding and interacting with the developer profile and funnel: hackathons, ecosystem events, builder support, new apps, top apps, VC backed apps, accelerator programs, and more. They have a lot of evidence and data around what types of proactive grants and sizes of grants deliver impact on the demand side, just like the O community has a great feel for the valuable supply side contributions and tooling. I certainly think it’s a good idea to expand the committee to include O representation, but curious if you really still think the O community alone would be well suited to take on a key piece of proactive demand generation programming?

I do believe the community of node operators has the knowledge and ability to make important decisions around demand generation, especially if incentivized, but I hear you on the grants committee. My word of caution comes more from not seeing the grants committee be super active within the community, but obviously, things happen behind the scenes that we’re not aware of.

I’m still a bit uncomfortable with the idea of taking rewards away from Orchestrators to fund this. I would be much more on board if O’s can count on the PM system for reliable payments, but that’s a chicken/egg situation and not one that’s easily solved, at least not without something like the proposal you presented. I think this is where the majority of the pushback will come from as it’s hard to let go of any O earnings in the current market.

[hthillman]

Thanks for putting this forward, Doug.

I am wholly aligned with the thrust of the proposal and I believe there’s a clear need to establish perpetual builder-focused incentives through a community-governed treasury. I don’t believe it’s a coincidence that the supply side (which has financial incentives) has become more robust than the demand side (which does not).

I do have some concerns about the implementation proposed.

In particular, I’m hesitant to use stake-weighted governance. As orchestrators have highlighted, using stake as a factor in voting power or work distribution centralizes network power. While Tier 2 entities can allocate funds as they please, what’s to stop the Tier 1 voters from preferring stake-weighted governance mechanisms to retain power in Tier 2 entities?

Similarly, I’m not convinced that we can assume that whales will always act in the best interest of the network at large. I’d point to examples in other governance proceedings where whales fight it out to the detriment of protocol goals - like prominent venture funds fighting over Uniswap deployments because they have invested in competing bridging protocols. In that case the Uni community was able to reach a decision, but it was influenced by large stakeholders trying to advance their own interests. Our stakeholders have been aligned with project interests so far, but I don’t think that will be a permanent state as the network grows.

W/r/t your final 1-10 question, I’d push for “7-8”. Speed is of the essence.

[dob]

Great feedback. I’m also on the 7 or 8 on that scale (or maybe even 9), because I can foresee the impracticalities of developing custom solutions that are secure AND have great UX.

Given that, do you have any suggestions for non-stake weighted voting at tier 1 that are:

• Decentralized
• Trustless and open access
• Allow us to move at the 7 or 8 pace

A council? Credentialed wallets for on chain activity? Both feel like they risk being somewhat arbitrary and disenchanting those who would be boxed out of participation.

[NicoV]

Thanks for putting this proposal together @dob , much appreciated.

I agree Livepeer needs a DAO treasury, but I disagree it should be funded by inflation.

I think Livepeer Inc should make this allocation retroactively to fund this (or at least partially), because there should have been a DAO treasury since genesis (I know it’s easy to say in hindsight). The fact that this was not done should not be paid for by community members who didn’t have a say in the genesis of the protocol nor out of pocket from those running the network for years now, especially not if the issues mentioned in the recent forum thread about current protocol issues aren’t resolved first. What the impact is on investors who invested in Livepeer Inc through equity and saw it as an indirect token investment at discount is not the community’s problem honestly.

How the DAO + treasury should be governed is less of a concern to me, however if it is expected that the community funds this from their inflation then this should be fully community owned with Livepeer Inc being able to make recommendations from the experience with the grants program.

[hthillman]

What about (1) a council, elected by voters who are (2) credentialed using something like Gitcoin passport, where “livepeer delegator or orchestrator” is a required stamp?

This would strike a balance between speed (the council can move fast) and access (current best practices for sybil resistance). If we choose this route, I would suggest that the original LIP specify that changes to the credentialing process be in the purview of the voters NOT the council

https://passport.gitcoin.co/

[vires-in-numeris]

Thanks for the proposal, Doug!
A lot of great and much needed ideas/suggestions.

Some initial thoughts on it:
While I’m not generally against it, I do see some issues with the inflation funding:

• Active participants (stakers and Orchestrators) are paying for it, while passive LPT holders (Investors, traders etc.) will just profit from it. This would be solved by minting a lump sum of LPT instead - so everyone will be diluted. But minting additional LPT also has problems like e.g. the possibility of losing trust among LPT holders.

• It’s difficult to find the right percentage since it depends on many factors like e.g.:

  • LPT price: I suppose most of the funding will be calculated in $
  • How much LPT is already in the treasury? Are there many/larger funding requests waiting so that we need to fill it up quickly?

• Do we have any idea how much in terms of $ the treasury actually needs? What is the current grants budget and was it exhausted? With a 5% contribution rate, the treasury would get ~$60k/month in funding at current LPT prices ($5.30). And I honestly don’t know if that is too much or not enough

For most of those points, a periodic lump sum funding by minting LPT might be better since we could react faster to the actual needs and market situations. But maybe there are some major issues that I didn’t consider?

Regarding Governance:
I do like the idea of an elected council. Because I see some issues if every <$5k funding request needs to go through on-chain voting and meet quorum. Maybe the council is free to allocate sub $15k grants freely and everything above that needs to go through on-chain voting (but is still proposed by the council)?

[Authority_Null]

Hey Vires, are you concerned that if the inflationary funding is taken from delegators as well, it could cause a significant shift in stake towards O’s with a very low reward cut and make staking with O’s who are somewhere in the middle (~20%) very unattractive?

The question that has been brought up in some messages is whether or not this could be a double blow to some orchestrators in terms of a loss in earnings.

[dob]

@NicoV

if it is expected that the community funds this from their inflation then this should be fully community owned

This is certainly the whole intention behind the proposal - that it’s protocol funded and fully community owned. Let’s make sure Inc is just one independent actor in the ecosystem on the same level playing field as everyone else.

Regarding the comments about Inc being responsible for funding it, while I don’t think that donations are off the table, and even suggest this from grants (not Inc), two quick responses.

1. The notion of “What the impact is on investors who invested in Livepeer Inc through equity and saw it as an indirect token investment at discount” is an incorrect assumption. Any equity investors in Inc have been on the complete opposite end of “token at a discount”, and instead have invested at quite a premium to the token value they got indirect access to due to the additional equity in the company. See, for example, the amount raised and fed back into Livepeer development and demand generation dwarfing the value of the token held within Inc.

2. The suggestion of Inc just funding it is in many ways just voting for the status quo. Inc funds quite a bit of core development. Stakes quite a bit towards grants node, routing funding towards grants recipients. Stakes quite a bit toward ecosystem contributors enabling inflation funding. Etc. The whole point of this proposal is to create sustainable mechanisms beyond Inc, to enable decentralization and independent actors to take agency. On the water cooler chat yesterday, the O community for example was seeking a call to action to coordinate and take leadership on some core video development and capabilities. That group should have a direct path to funding from the protocol without needing Inc’s permission.

[dob]

@vires-in-numeris

by minting a lump sum of LPT instead - so everyone will be diluted. But minting additional LPT also has problems like e.g. the possibility of losing trust among LPT holders.

Many people have hand waved the suggestion of “just mint it” over the years. While the community could certainly do that via governance, my anecdotal experience is that people react very poorly to sudden changes in token supply mechanics. I see this all the time on small things like people seeing a “max supply” number on CMC, and then months later asking how it increased? (They didn’t understand Livepeer’s inflationary nature, and felt they were duped.) That example is their own fault for not doing their research, but I feel like if the community just takes arbitrary action to mint an arbitrary amount of token on a whim every so often, no one can reason about the supply mechanics or value of LPT as reflected by its ability to route/attract work on the network - and that wouldn’t be a good thing.

I think your questions asking “how much is needed” are spot on for the analysis the community should do when justifying the % to be contributed to the treasury. One point is that just because grants doesn’t have an endless pool of applicants deserving of more funding, doesn’t mean that more token available retroactively for apps, video builders, Os, and other contributors wouldn’t be warranted or effective. It’s partly a pipeline issue, but also partly an execution issue in terms of creating programs to effectively use the LPT within the right stakeholder groups.

[dob]

@Authority_Null

whether or not this could be a double blow to some orchestrators in terms of a loss in earnings.

I have a quick reaction that this notion that because overall earnings decrease, D’s will immediately look to move, along with @vires-in-numeris notion of “O’s and D’s pay while others profit” to be in the same bucket, as potentially overblown. When P rate goes from 44 to 51 for example, that represents a ~15% decrease in rewards, but we don’t see D’s rushing to move to lower reward cut O’s to make up for it. It’s just the new status quo as rewards decreased across the board. Similarly, non-staking O’s and D’s are still being diluted just as much as before. The protocol (and entire ecosystem) is paying for it…not just O’s/D’s…and the question is just whether the project and network are more likely to be more valuable through more usage and utility in the long run as a result, than the short term reduction in rewards.

[dob]

@hthillman

What about (1) a council, elected by voters who are (2) credentialed using something like Gitcoin passport, where “livepeer delegator or orchestrator” is a required stamp?

Couple people have mentioned the council, and I definitely think it’s something to consider.

One reaction is that I feel like it remains this centralized thing to critique/attack (“The funds are only controlled by 9 people!”, etc), and it would be great to get away from that. But there are a lot of positives as well, especially if the community can add/remove people from the council.

Do people think that centralization is a negative? How would we get around the sybil attack of one person creating many delegation accounts to capture the council?

[iameli]

@dob

• 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?

Still pondering the full proposal, but my approval would probably just depend on porting this bit over from the Grant Program:

Requirements for ALL GRANTS:

• Projects must be open source
• Showcaseable
• Grants must be achievable within a 3 month timeline

[yondon]

A few initial reactions:

1. What would be a useful but justifiable TreasuryContributionPercent value?

I think a simple financial model that projects the amount of LPT the treasury would accrue over 1 month, 6 months, 1 year, etc. given various values for TreasuryContributionPercent and given an assumption of whether the protocol inflation rate is increasing/decreasing during the time period as well as the LPT/USD exchange rate would be helpful for developing an intuition of what a reasonable value could be.

I also think it is worthwhile to consider whether there is a process that could allow TreasuryContributionPercent to start at a lower, more conservative value in the interest of spurring faster community experimentation with the treasury (as long as that value is still high enough to fund some shorter public goods funding experiments) while committing to gradually increasing the value as milestones that demonstrate effective treasury usage that creates more value for the network are hit i.e. establish a credible commitment along the lines of set the value to X%, after the first RetroPGF round is complete if criteria Y is met then push the value to Y%.

1. On a scale of 1 to 10:

9 - generally, if there are existing tools and frameworks that are good enough (even if there are certain shortcomings) for the use case I would advocate strongly considering experimenting with them first vs. rolling custom tools/frameworks as I think the latter can be a major distraction, especially when on-going maintenance cost is factored in, from onboarding more developers to the network which I believe should be the top priority.

[dob]

Does anyone want to volunteer to share out a model that shows treasury growth over time? It could include certain variable assumptions like:

• TreasuryContributionPercent
• Budget for what would be spent from the treasury by month or quarter
• Livepeer network inflation rate
• Etc

I’d imagine it would be helpful for the community visualize this to aid in determining an affective TreasuryContributionPercent value, or expectations for how that could be adjusted over time as the treasury grows or depletes.

[NicoV]

But shouldn’t taking it from inflation at this point be the last resort ? And if it is taken from inflation, are there ways we can prioritise taking it away from e.g. nodes calling reward but not performing transcoding ?

Additionally, Are there alternatives to funding a DAO treasury and does it have to be exclusively LPT ?

What would it look like if the current grants program and its node operation is transformed into a DAO to bootstrap it. How much income does it have ? If people want to give up inflation they can stake to the DAO orchestrator in that case but at least there is optionality.

A lot of teams on Arbitrum received substantial grants lately, but one requirement was to have a DAO with token. Would one alternative funding mechanism be to pursue a retroactive grant from the Arbitrum team.

There’s also other teams like ours at Tenderize planning things in the near future and I believe collaboration between teams and DAOs not only in the form of integrations but also grants, is an important flywheel mechanic in funding these things.