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

[Authority_Null]

@dob

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

This came up in the water cooler chat. We might be able to get something going with chatGPT but we need to figure out exactly what metrics we should be feeding it. The right prompt could generate a pretty useful model since chatGPT excels at that stuff.

[Titan-Node]

Here is my rough report on some projections for the treasury. If we want to expand on this or make a more formal budget I’d be willing to put time into it. But for now here’s my 2 cents.

Treasury Projections
I think the goal of the treasury would be to continually spend it’s budget and not gather too much of a base as I believe the treasury would not be able to stake or participate in the network itself.

Based on that I created a few charts for 1%, 5% and 15% cut from the current inflation round. No new tokens minted, just taken from the current inflation rounds.

1) 1% cut

Assuming we spend all the treasury funds every quarter (maybe quarterly on-chain votes for distributing funds?) we reach approximate payouts of 4,000 LPT, which gives us (in todays price at $5.5 USD) about $22,000 USD worth of spending budget every quarter to award.

2) 5% cut

Again similar situation but the funds become larger around 20,000 LPT or $110,000 USD every quarter.

3) 15% cut

And lastly a 15% cut (which in my option would be significantly noticeable from a Delegator’s perspective) would give us 60,000 LPT and a quarterly budget of $330,000 USD.

Lump Sum Funding
Another option for funding would be lump sum funding where the treasury could submit a budget or come up with an appropriate amount we could vote on. Here’s an example of an annual 12% lump some given on day one.

However given the decentralized nature of how we want to treasury to work, I am not confident a lump sum would work for a tier 1 treasury as discussed in the thread above. Maybe this is more of a tier 2 concept that a DAO would submit to the treasury in order to get funding.

Treasury Voting
To add to the discussion above, I am in favor of using existing tools for managing the treasury. Somewhere of a 9-10 on the scale that @dob mentioned. I like the idea of using something like IdeaScale for generating feedback and integrating with on-chain voting. I’ve seen/used it with other protocols and it was a great experience.

I do not have much opinion on the current voting vs modified voting (quadratic or otherwise). It seems the current 1:1 vote is effective and already implemented, so for the sake of time and effort just stay with our current voting system.

Final thoughts
I am excited about the prospect of helping build tier 2 DAOs where we can have multiple places to reach out for public goods funding. Very excited for this development.

[dob]

@NicoV

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.

Yes, Livepeer received a grant from Arbitrum into the grants node multisig, as shared on twitter, and as part of the “grants program transition into DAO” this seems like a logical candidate to move into the community governed treasury (see next comment)…

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 ?

That is somewhat the spirit behind this proposal actually. Only a couple volunteer parties funding the (non-transcoding) grants node at 50% reward cut wasn’t setting the whole project up for sustainable long term, or community governed, decentralized funding. So the proposal suggests that the grant node desolves in favor of this DAO treasury. BUT it doesn’t suggest the grants program operation goes away, since it is effective at giving targeted, proactive grants, targeting certain use cases. Instead, it just suggests the grants program be one applicant to the community governed DAO treasury (with no guarantees of funding, if not approved on same terms/process as any other entity applicant). It also suggests that the program keeps 6-12 months budget to keep operating without disruption for the time being, and uses the rest of its treasury (including the ARB as you suggest), to bootstrap the community governed project treasury.

At the time of the pre-proposal it was accruing about 7000 LPT/month, though that’s gone up a bit recently with some increased staking.

[Authority_Null]

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]

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]

I really love this idea @Titan-Node

[yondon]

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]

@yondon

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

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

@yondon

a LIP is created to set the treasury cut to 0.

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

1. Livepeer’s existing stake-weighted voting at tier-1 vs credentialed council (or other alternatives).
2. The initial TreasuryContributionPercent value.
3. 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]

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]

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]

@Wiser

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.

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…

1. Proactive vs Retroactive funding. Retroactively rewarding projects for demonstrated contributions, on an ongoing basis, is a good check against this.

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

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

@Wiser

How will we determine which projects will be supported with this treasurery?

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]

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]

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:

1. The actual unfairness that exists in the ecosystem today.
2. 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.
3. 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

1. Allocate the grants program funds to the DAO, make projections on its annual revenue based on relevant data points today.

2. Sell the treasury $ARB for stables, get an ROI on the stables

3. Pursue grants from other projects, such as Tenderize

4. Collateralise assets to fund grants rather than selling assets, have future cash flow pay back the loans.

5. (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]

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]

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.

@dob

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.

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]

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

• JokeDAO
• Gitcoin Grants Stack
• Optimism RetroPGF

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]

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.

• LIP-91 discussion
• LIP-92 discussion