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

Authority_Null · May 13, 2023, 4:20pm

Deleted my last couple of messages due to errors in the model. I’m hoping this one is more accurate.

Prompt:

There is a decentralized transcoding network called livepeer. The network uses a token for governance called LPT. New LPT is generated every round, and each round is about 22 hours. The amount of LPT generated depends on the networks participation rate, which is the amount of LPT staked to node operators on the network, and there are 100 node operators. If the inflation rate is above 50%, less new LPT is generated every round. Conversely, when the participation rate is below 50%, more LPT is generated. For this model, we’re going to assume the inflation rate fluctuates between .2% and -.1% throughout a 12 month period. You will use a base 90 day average of 6,926 for the amount of LPT generated each round and subtract or add inflation/deflation rate as necessary.

In a proposal by Livepeer’s co-founder, each round, 5% of the LPT generated by the 100 node operators will be sent to a protocol treasury that will be used for public goods funding.

Column 1: Month
In the first column, show the months of the year, up to 12 months.

Column 2: LPT Generated
In the second column, show the LPT that is generated each round but compounded for the monthly amount, which is 207,780 and for every 6,926 out of the 207,780 adjust based on a random inflation % between +0.2% and -0.15% for each row.

Column 3: LPT Funding (5%)
Using the LPT generated, create another column that takes 5% of the LPT and displays the amount in each row, for each month.

Column 4: Treasury Balance
In the next column, take the LPT Funding (5%) (5% LPT generated) and compound it for each row, for the 12 months. begin the treasury balance with a balance of 100,000 LPT and add the 5% on top of it for each row.

Column 5: Monthly Spend
In the next column, we will input the monthly spending of the treasury fund. For this model, we will pick a random number between 5,000 and 50,000 for each row for the 12 months, never exceeding the total treasury amount.

In the final column, we will subtract the monthly spending from the Total Treasury amount.

Build me the model.

Titan-Node · May 15, 2023, 9:16pm

Another way we could look at funding a Treasury is based on a LPT cap.

As mentioned by @vires-in-numeris in a recent water cooler chat, if we have issues with properly allocating the funds or can’t spend the budget we will end up with a very large treasury which may not be desirable. (scrutiny, expectations, security etc)

Instead of a fix percentage (say 15%), we would set a treasury limit of X amount (say 100,000 LPT), as the treasury gets closer to the limit the treasury cut reduces until reaching 0% at the cap.

We are familiar with this type of scaling with our participation rate inflation funding already.

So the scale would be something like: 20% cut from 0 LPT in the treasury and scale down from there until it reaches its max.

Two parameters would be needed, max_treasury_cap and max_treasury_cut and can be voted on to change at any time.

Would love any thoughts or criticism on this idea.

Authority_Null · May 15, 2023, 9:25pm

I really love this idea @Titan-Node

yondon · May 16, 2023, 8:10pm

I like the spirit behind this mechanism!

However, a few initial concerns came to mind regarding the outlined mechanism:

Increases the number of parameters that you would have to set via governance from 1 to 2. Given the mental overhead involved with deciding on appropriate parameter values, I would generally advocate for minimizing the number of parameters that have to be set via governance unless there is a very strong reason for including an additional parameter.
A higher treasury cut when the treasury has a lower balance seems like it might create an incentive for the governing body of the treasury to minimize its balance in order to maximize the treasury cut which may not be desirable. While this mechanism might encourage more spending from the treasury which could be desirable under certain circumstances, I’m nervous that it could also encourage perverse behavior in response to the mechanism such as spending for the sake of spending (or in the extreme scenario, transferring LPT to other addresses just to make the balance of the treasury look smaller).

IMO the most important/interesting idea highlighted by this mechanism is to introduce limitations to the balance of the treasury to avoid perpetually contributing LPT to an ever growing treasury that is not actually productively used for the ecosystem. Another approach motivated by this idea: after X days of the treasury being funded OR after Y LPT is contributed to the treasury, a LIP is created to set the treasury cut to 0. If the community accepts the LIP, treasury contributions end. If the community rejects the LIP, treasury contributions continue. The treasury cut for this LIP could be non-zero as well if there is proper rationale for its value. As a part of the consensus building process for Delta, the community could decide on whether to take such an approach and to couple it with setting expectations for what the community would want to see in order to justify treasury contributions continuing (and for an entity to vote to reject the LIP that would end treasury contributions).

Titan-Node · May 16, 2023, 10:23pm

Maybe just keep it simple then, remove the scaling cut idea and just go with a static cut with a max Treasury size.

I think this is basically achieved by having a max_treasury variable in the protocol.

But yeah I think this is an interesting way to go, keeps bloat down and the treasury accountable.

dob · May 17, 2023, 3:34pm

May 17, 2023 Update

All the feedback and discussion so far here, in the Discord, and on calls has been great. Here’s an update as to where things stand.

Tools evaluation is in progress. The practicality of using existing tools to aid in proposals, review, voting, and treasury funds release is a big input into what we CAN do. We hope to have an initial design for how we could leverage existing tools with minimal Livepeer protocol changes by the end of next week.
Moving from feedback and discussion, to writing out some small, concise, and concrete proposals. If you have specific ideas, don’t wait…share them now. Because to keep the process moving we will ultimately have to write down proposals and move them through the LIP process for votes. I’d like to get to proposal drafts before the end of the month.
The 3 big themes of open questions can be summarized as:

Livepeer’s existing stake-weighted voting at tier-1 vs credentialed council (or other alternatives).
The initial TreasuryContributionPercent value.
Caps on Maximum Treasury Size and methods for auto-adjusting the TreasuryContributionPercent accordingly, versus just relying on governance to move the parameter value as needed.

Join tomorrow’s Community Topic Call at 12pm ET if you’d like to discuss any of these open questions live. Or share more detailed proposals here, or ping me if you want to hop into the office hours channel to discuss ideas live at another time.

Wiser · May 17, 2023, 5:16pm

Outside of the defined cut and amount of this treasury, another question comes to my mind.
How will we determine which projects will be supported with this treasurery? All orchestrators and there delegators will contribute to this reserve, but what if the funded project decides to use only its own Orchestrator, or perhaps select one or two others? In the end, the entire community will have contributed to funding a project that will only benefit its creator and one or two orchestrators that they may have chosen as backups.

Maybe it should be established as a condition that a project funded by the treasury cannot select specific orchestrators and must use the basic selection system, similar to that of livepeer.inc

I believe I understood that we will vote for the projects that will benefit from the treasurery, but what will prevent an orchestrator with significant voting power from negotiating with a project, trading the exclusivity of their transcoding node in exchange for their vote?

I understand that the idea is that even if just one supported project manages to take off and provide returns to everyone, it would be as to boarding a major web2 broadcaster like Kick.com.

I am convinced of the value of this treasurery and the support it can provide for the adoption of the Livepeer network, i’m just concerned about making sure that the projects funded through this treasury ultimately benefit all those who have contributed to it. and I would be interested to know your perspectives on these matters.

yondon · May 17, 2023, 6:08pm

I think this is basically achieved by having a max_treasury variable in the protocol.

Yeah you’re right! A maximum treasury balance could be enforced programatically within the protocol or it could be enforced socially by someone proposing a LIP to adjust the treasury contribution when the treasury balance reaches a pre-determined balance. The benefit of the former is that it reduces reliance on social coordination and the benefit of the latter is that it minimizes changes to the protocol.

Upon further thinking, I have a slight preference for programmatic enforcement of a maximum treasury balance although without automatic scaling of the treasury contribution as you suggested. If the maximum treasury balance is met or exceeded, then treasury contribution is set to 0. As a result, if the community wishes to continue treasury contributions an LIP needs to be proposed to increase the maximum treasury balance. I prefer automating setting the treasury contribution to 0 when the max balance is reached and requiring governance intervention to continue contributions vs. my previous suggestion of defaulting to continuing treasury contributions unless there is governance intervention because I think defaulting to putting the evaluation of treasury fund usage front and center as an important issue for the community at this early stage is preferable to defaulting to going on auto-pilot with treasury contributions.

dob · May 17, 2023, 7:30pm

This would be a good thing to talk about on a call or office hours. A couple quick points as to how the community can think about solving for this…

Proactive vs Retroactive funding. Retroactively rewarding projects for demonstrated contributions, on an ongoing basis, is a good check against this.
The proposal says that end funding recipients - or apps - wouldn’t apply to the treasury directly, and instead would apply to what I called tier-2 entities, and those entities are unlikely to use stake weighted governance. So negotiating direct with a high staked O wouldn’t be a way to capture this funding.
Social policy expectations. Just like @iameli suggested above, there could be expectations around open source, use of full network, demonstrated output in X timeline, etc as to what would be eligible for funding within certain tier2 entities (like the VideoBuilderDAO suggested).

At the end of the day I think the bigger risk you’re highlighting is capture of a large block (or majority…or all???) of the treasury via collusion around stake weighted voting - and this is a bigger problem than a successful app only using limited O’s.

Titan-Node · May 19, 2023, 1:07pm

I believe this is achieved by only letting tier two treasuries vet each project.

The tier one treasury will only give funds to tier two treasuries that will likely have mandates around funding projects that are fair. (and which don’t need onchain voting so whales can’t override this)

NicoV · May 20, 2023, 5:50pm

I don’t understand why we’re already discussing how to spend a potential treasury and how to implement it while we haven’t found consensus on how it should actually be funded. Not a single orchestrator should accept taking it from inflation if there are no alternatives that have been properly investigated for feasibility. Especially not because some orchestrators have been receiving exceptional protocol subsidies in the past for absolutely no contributions to the ecosystem at all such as Coinbase Cloud.

NicoV · May 20, 2023, 5:57pm

The self-sustainable DAO

Introduction

The Livepeer community is looking to form a DAO to fund grants and other ecosystem initiatives. The initial idea is that the DAO receives protocol subsidies through inflation. This means inflation is taken from orchestrators and redistributed through several proxy initiatives. The hope is that the implied odds of these initiatives adds value to the token by the same amount as is being taken from orchestrators.

This is not only an incredibly hard sell to existing entities keeping the network afloat, it’s also not a sustainabale way of funding a DAO. There are three main reasons here:

The actual unfairness that exists in the ecosystem today.
The cut being paid from the existing orchestrators does not weigh up to how much some entities such as Coinbase Cloud have been bleeding the network dry in the past.
Inflation is not endless

I want to provide alternative ideas for funding the DAO, that can restore the power balances on the network as well as create a self-sustainable future. A DAO funding mechanism that does not take direct subsidies, and does not demand the good actors of the protocol to make disproportionate sacrifices.

Key Principles

1. DAOs are for-profit

A DAO should be treated as an actual business and not a charity.

This means that the DAO should not blindly give out grants, if the grant recipient is creating a revenue generating project. Instead, the DAO should be seen as an early-stage angel investor and given a ownership share in the project receiving the grant.

Rather than a pure grants program, you now have the Livepeer Community Accelerator

2. DAOs can raise external capital

Admittedly (1) and (2) go hand in hand. But once you establish the DAO as a for-profit venture it can perfectly sell ownership shares. With a good plan and good cost projection rather than just spending tokens, the DAO could actually pull off a (Founding) Token Sale.

Meaning rather than taking in LPT from inflation or minting a lump-sum, community members can purchase founding shares in the DAO in exchange for LPT.

3. DAOs should actively manage capital

The grants program has already succesfully operated a Livepeer Orchestrator for multiple years, inflation was used to fund the grants program.

A DAO should actively budget funds it can actively manage and try to get a decent return of investment on these. This can go beyond staking LPT, but also providing for example stablecoin liquidity to the 3CRV pool and earning swap fees and token emissions.

The Plan

Allocate the grants program funds to the DAO, make projections on its annual revenue based on relevant data points today.
Sell the treasury $ARB for stables, get an ROI on the stables
Pursue grants from other projects, such as Tenderize
Collateralise assets to fund grants rather than selling assets, have future cash flow pay back the loans.
(Optional) Create a vote and implementation to route tokens from historically bad faith actors on the network to the DAO. Effective allowing for a redistribution of those tokens.

Karolak · May 21, 2023, 4:24am

I agree with what nico have underlined above and on discord. Orch #2 by total stake has not done any transcoding job since its inception and is getting 1k lpt daily from inflation, that is 5k$. Also ARB airdrop could be used as DAO fund. What If inflation reaches 0? How would that make it sustainable? And what is important, fund should not be a charity, active orchestrators contribute to the network already, inflation was meant to cover their running expenses, there are plenty orchestrators which do not transcode and still using inflation to cover their “infra expenses” which are non existent. The current approach is wrong.

t_norm · May 23, 2023, 4:41pm

Hi @dob and the Livepeer community!

My name is Traver, and I’m a Governance Lead at Messari! Mihai Grigore, the author of the Livepeer Quarterly Reports, passed this proposal along to our team (@raho and I), and we put together some thoughts on the proposal that we hope might be useful to the Livepeer community as it continues its decentralization journey.

From our standpoint, there are a few key tensions here:

1. Examining the Tradeoff Between Orchestrator Revenue and Treasury Funding

If Orchestrators and Delegators support diverting LPT inflation revenue to fund grant programs, they will likely expect those programs to align with their long-term goals. As such, the proposal might benefit from a more aggressive alignment between the objectives and KPIs for grant distribution and increasing protocol revenue.

Projecting the financial impact for orchestrators, transcoders, and delegators is an essential analysis for the Livepeer community. While our Governor team is relatively new to the Livepeer protocol, we used some basic assumptions to complete a simple aggregated analysis of the impact for stakeholders. We found that if inflation revenue drops at “TreasuryContributionPercent” values of 1%, 5%, or 15%, it would necessitate a corresponding year-on-year growth in annual streaming minutes by 229%, 1,145%, and 3,437%, respectively, to generate enough usage fees to replace the diverted LPT tokens. A more detailed analysis to demonstrate the impact across each stakeholder group could deliver a “north star” objective for the community regarding program outcomes and goals.

This exercise is especially prescient since usage fees comprised only 2.4% of rewards in Q1 2023, and usage fees (both “Estimated Usage (7d)” in mins and “Fees Paid (7d)” in USD) are in decline.

2. The Design and Efficacy of an Additional Livepeer Grants Program

Livepeer might also analyze the success and shortcomings of the existing Livepeer grants program. The Livepeer Grants Program has committed $585,207.34, with a significant percentage committed towards tooling and streaming apps. As Livepeer looks to fund more aggressive programs, it could be worth looking backward to inform best practices and standards for new subDAO programs under this structure. The perceived ROI and size of previous funding might indicate how much inflation the DAO wants to divert to new grant programs.

Retroactive funding can be a powerful incentive, but its efficacy in incentivizing new development is largely untested. By creating quantitative, measurable goals for the program, funding might also be distributed to recipients more aligned with stakeholder goals. One way might be to fund creators with stipulations, i.e., funding could be allocated for a broad list of reasons but only claimed for specific use cases (Further Livepeer-related development, LPT incentives for new tools or projects, or explicit compensation for Livepeer projects and work).

Regardless of the structure, our team feels strongly that all good grant programs have a clear objective with actionable reporting on grant distribution, grantee accountability, and grant effectiveness.

3. Stake-weighted Voting vs. Alternatives

As mentioned on the community call and above, stakeholders have already provided valuable thoughts on the governing model. Given the diversity of stakeholders in the Livepeer economic system, a council model is intriguing, especially if existing governance participation is low or lacking (a topic that requires further analysis). One model worth exploring is the Graph Council, which aims to represent multiple stakeholder groups and is tasked with many responsibilities, including ecosystem/grant funding.

Given that new governance models require technical development, it would be helpful to have a clear view of the resources each alternative would require (R & D, funding, etc.), so the community can make a more informed decision.

yondon · May 25, 2023, 7:38pm

A few thoughts based on the latest conversation:

A few posts have highlighted that the treasury should not act as a “charity” and the potential of a for-profit DAO. While there may be merit in a for-profit DAO, I would advocate for focusing on public goods for the ecosystem as a higher priority for the treasury first (that does not preclude exploration of for-profit funding entities). The rationale for this is that there is a broad landscape of existing for-profit funding entities that are well structured to fund private goods that are built on Livepeer, however, there is a much more limited landscape of funding entities that can fund public goods (i.e. broadly useful to everyone in the Livepeer ecosystem due to universal access which also makes them difficult to monetize) such as open source dev tooling or even hyperstructures that leverage the network.
A few posts have highlighted that protocol contributed inflationary LPT is not necessarily a sustainable source of funding for a treasury in perpetuity. I agree with this point given that it is possible for the inflation rate to drop to 0 if the staking rate exceeds the target (50%) for a prolonged period of time. Additionally, as the network matures in later stages, it may even be desirable for the inflation rate to gradually decrease towards 0 as fees take over as the primary source of revenue. With all this being said, even if protocol contributed inflationary LPT is not necessarily a sustainable source of funding for a treasury on its own, I do believe that it should at least be considered as a candidate source of funding that complements a “donation” from the existing community grant node and other token grants received by the community (i.e. ARB) if the latter two sources are insufficient.
While the treasury contribution rate from the OP is essentially a tax levied on orchestrators and delegators, I see a few details that are worthwhile considering:
- The same actors will have voting power over how the taxed funds are used.
- If the orchestrator subDAO suggested in the OP is introduced that introduces mechanisms to deploy LPT amongst orchestrators then a portion of those taxed funds could go back to affected actors.
- A automatic forced re-evaluation of the contribution rate as mentioned here can help ensure that if taxed funds are not used in a way that generates more overall value for the affected parties that the affected actors can choose to reduce or eliminate the tax.
I am opposed to the idea of using a LIP to re-distribute stake of a selected number of addresses because a) I have not seen a credibly neutral method of doing this i.e. does not retroactively single out entities based on subjective discretion without clear pre-defined protocol/social rules that were violated b) this practically is unlikely to work because addresses that would be affected would be able unstake and withdraw prior to the LIP being executed. I do believe that addressing the issue of stronger alignment between work performed by orchestrators and LPT rewards received is important though - I just don’t think retroactive actions such as a LIP to re-distribute stake are the right approach.

dob · May 31, 2023, 7:42pm

May 31, 2023 Status Update
Hey all, thanks for weighing in with such thoughtful comments and discussion. I appreciate those of you who took the effort to model some of the economic scenarios of various contribution rates, including @t_norm with the Messari-level analysis!

If it’s seemed quiet in the past week, it’s because I’ve been deep in a “tools + frameworks evaluation” exercise with @victorges, where we’re trying to map some of the core ideas of the pre-proposal and feedback to existing tools. We’re closing in a good potential candidate for how the protocol could keep track of enough state to support the Governor framework and tools like Tally.xyz.

The results of this analysis and prototyping will inform what can actually go into an LIP draft proposal, which is probably the next big output that I’m working on. Stand by, and as always, please weigh in with any proposals, suggestions, or ideas in the meantime.

For those in the O community or Video Builder communities, if you are looking to get ahead of self-organizing into groups to run retroactive funding rounds, then I’d suggest taking a look at some of the following tools and communities:

As these are tools that could be used or easily modified in order to conduct rounds of rewarding contributions within your communities. I’ll certainly work to propose how you could use those tools, but it doesn’t hurt to get familiar now or start organizing.

dob · July 26, 2023, 3:03pm

This pre-proposal has now graduated to actual proposals in the form of Draft LIPs. See:

LIP-91 A bundle which proposes the creation of the onchain Livepeer treasury governed by the community.
LIP-92 An LIP which proposes how the treasury can get populated via the protocol.

Discussion for these two proposals should be broken out and can now move to these two forum threads.

dob · July 26, 2023, 3:22pm

One additional point worth highlighting in the context of the pre-proposal…

The pre-proposal suggested that the existing Livepeer security committee be controlled via this binding on chain governance - with the ability to add keys, remove keys, and change the threshold for number of security committee signatures needed to make a protocol upgrade. This is not included in the above LIPs, because it was outside of the scope of the treasury, but if the treasury LIP passes, then it would be great to follow up with a proposal for making the governor the owner of the security committee permissioning, in which case this decentralized control over the committee (and ability to remove it if deemed appropriate) could pass to the hands of the token holders, rather than being enforced via social contract.

victorges · August 30, 2023, 11:27pm

Reposting here as it seems to be where most of the discussions happened.

FTR there is now a devnet with the upgraded Delta contracts that can be tested on a separate explorer as well! Accessible here: Delta Goerli Explorer

For full details on how to setup your account and what to test, check this guide: Testing the Livepeer Treasury

Thanks for anyone that can give it a try

NicoV · October 4, 2023, 8:10pm

would advocate for focusing on public goods for the ecosystem as a higher priority for the treasury first

Public good funding and for-profit does not have to be mutually exclusive, instead can be complementary.
Much infrastructure is a public good, that does not mean its usage is free. It is subsidized in part by the revenue it generates and taxes levied on it (e.g. public roads, state owned railways/airlines, utilities, …).

I am opposed to the idea of using a LIP to re-distribute stake of a selected number of addresses because a) I have not seen a credibly neutral method of doing this i.e. does not retroactively single out entities based on subjective discretion without clear pre-defined protocol/social rules that were violated b) this practically is unlikely to work because addresses that would be affected would be able unstake and withdraw prior to the LIP being executed. I do believe that addressing the issue of stronger alignment between work performed by orchestrators and LPT rewards received is important though - I just don’t think retroactive actions such as a LIP to re-distribute stake are the right approach.

There have been single entities mentioned, because it’s very clearly empirically visible as to the behaviour of some node operators. While no single entity should indeed be singled out by protocol rules or social contract, there should be rules that prevent rent-seeking behaviour which can be credibly neutral. In fact, I think we can all agree that some orchestrators are breaking the social contract and shared values many of us have (i.e. actually doing work and running a GPU), which is why we are luckily having this discussion.

Alternatively if a group of actors disagrees with the direction of the current ruleset or social contract, there is always the radical fork choice. A group of actors with the same shared values can align and fork the protocol with a redistribution of stake. While radical it is credibly neutral if the fork finds majority support.

Fork Choice Rule and Fair token distribution are two key components that actually make up credible neutrality in blockchain networks.

For example, if the Livepeer foundation and insiders controls the bulk of the votes for these governance proposals, there is no credible neutrality either.

Thanks @t_norm for some number crunching.

With the current proposal at taking 10% of the inflation, the demand generated by this public goods funding would have to be ~2300% higher than what it currently is, which doesn’t add up for me.

The proposal might make more sense if it would start lower, and see if it can actually generate demand growth to warrant increasing the % of inflation going to this funding.

Alternatively, the entities/people in support of the proposal could first prove with skin in the game that public goods funding could indeed drive demand at a rate that might lead to a sustainable proposal.