The Livepeer Delta Pre Proposal is now moving to a distinct set of formal LIPs. As such, each LIP bundle deserves its own discussion thread, rather than lumping everything together into one big thread which can muddle specific issues. This is the thread for the LIP-92: Livepeer Treasury Contribution Percentage.
LIP-92 is now live in Draft status, and open for feedback and discussion here. You can read the full LIP, including the rationale, in the LIP repo. The brief summary is:
If LIP-91 passes, which creates an onchain treasury governed by the LPT holders, then this proposal dictates two main initial parameters for how the treasury gets populated.
- 12.5% of inflationary LPT would be routed into the treasury each round. This parameter is called the
treasuryRewardCutRate. - If the treasury exceeds 750000 LPT, this
treasuryRewardCutRatewould be set to zero, halting further automatic contributions, until governance is used to change this value and re-enable contributions. This parameter is called thetreasuryBalanceCeiling.
Both parameters are moveable via Livepeer’s governance.
One thing I have noticed is that, even though Orchestrators are putting themselves out there looking out for the long term growth of the network, a lot of Delegators are only here with the same intentions as the vampire O’s; just take as much value as possible while they can without caring about the long term growth of the network
Delegators take the biggest piece of the LPT inflation pie by far, but most of them only lock in their capital and their contribution ends there. They check on their ‘investment’ every now and then, but aren’t putting in any effort to actually help make Livepeer a success
The way I see it this proposal kinda forces them to participate in some sense by giving them less inflation and redirecting it to fund good ideas and the people driving those
One thing I worry about is that smaller Orchestrators would rightfully raise their reward cut to compensate for the loss in rewards, but whale Orchestrators can comfortably keep their reward commission low since they’re already making way more than their cost basis. IMHO certain bigger Orchestrators right now have become complacent, comfortably raking in the rewards based on the efforts/costs they made years ago while barely making any more contributions since then
I wonder though, is it possible (and not to expensive in terms of calculations being done on the smart contracts) by not charging a flat %, but taking a % from the Orchestrator directly depending on how much total stake they have?
It would incentivize Delegators to distribute their stake more
2 Likes
Thanks for putting this together.
My feedback is 12.5% seems very high. What was the decision basis around this? Same as 750,000 for the cap. Why that number?
I do see this:
The discussion for this proposal in the forum and community calls yielded quite a bit discourse and modeling on this topic, and there’s clearly no value which will satisfy everyone. If you look at the average tax-to-GDP ratio of productive nation states, you’ll see that it often falls at around the 10-25% range. Decentralized, blockchain based, digital communities should be more efficient than many beurocraticly-heavy nation states, however it could also be argued that Livepeer is more “pre-product-market-fit” than many nation states, hasn’t achieved sustainability in terms of its fee market yet, and requires significant public goods funding to decentralize and enable many forms of contribution as the bootstrapping phase continues.
I’m not sure I quite follow the comparison between Livepeer and nation-states.
To me, a tiered system makes a lot more sense. Why take 12.5% from an O that makes pennies from LPT rewards?
Also, what happens if the money just sits there without being allocated? We’ll just keep giving up rewards until 750k cap is eventually reached. This seems painful for delegators and O’s.
1 Like
I would like to see a progressive tax rate (tax because thats what it is…)
Under x LPT Stake they pay 0% to ensure that they can operate profitably against their cost basis and progressively increase. Ranging from 0% through up to 25%.
Implement a lower tax rate on all tiers through a trial period (so max tax would be 12.5% initially) and later after a probationary period (6 months, year?) Re-vote to increase depending on the success of the LIP.
If we take a flat 12.5% it only truly hurts the delegators and most negatively effects those at the bottom of the delegater list. Progressive, if we are similar to a nation state is meant to relieve the burden on the bottom of the group and increase the tax on the top earners.
Example of the scale:
0% - 10,000 LPT
5% - 50,000 LPT
10% - 100,000 LPT
12.5% - 150,000 LPT
15% - 250,000 LPT
20% - 500,000 LPT
25% - 1,000,000 LPT
And apply it marginally. So 25% isnt really 25% it would be lower calulating the effective tax rate of everything in between.
This could also help distribute LPT delegation more evenly as theres now a cost to piling onto the biggest O’s.
Additionally, consider lowering the max LPT threshold during this period and build in a disbersment method in the instance that this ever gets disolved.
2 Likes
Regarding different treasuryRewardCutRates for O’s with different amounts of stake…
Do you think it would encourage O’s to “split their stake” and spin up additional O nodes (likely trivially on the same hardware)? Taking available O slots from lower staked O’s in the process?
After discussing it in the Water Cooler chat, the general consensus is that a tiered system would introduce a lot of complications and loopholes that may not be worth dealing with initially (some may disagree).
What would be great to see is an introductory treasuryRewardCutRates of 4-5% and then re-evaluate in 3-6 months. Personally, I would feel a lot more comfortable giving 12.5-15% if there’s proof of concept that the network actually needs that big of a treasury to fund public goods. If the demand side increases significantly, take all my LPT! If the treasury piles up and funding goes nowhere, I’d rather not give up the LPT earned.
5% is still around $600k a year. From what I understand, the grants program paid out ~$160k in 2022. The jump is more than enough to fund demand-side applications and community projects, in my opinion.
2 Likes
@Authority_Null Did a good job of summarizing the discussion around LIP-92 in today’s water cooler chat.
As mentioned a 5% treasuryRewardCutRate based on current the current inflation rate and token price would fund the treasury with over $600k/yr which is ~3.5x what the grants program spent in 2022. That’s a significant increase. A treasuryRewardCutRate of 12.5% based on the above assumptions would be over $1.5m/yr. Do we think we need nearly a 10x increase in funding to drive demand?
2 Likes
Do we think we need nearly a 10x increase in funding to drive demand?
While this does not answer the question directly, it’s also worth pointing out for reference that Inc spends many millions of dollars/year, largely focused on demand generation. And if Delta is about enabling sustainable funding for the project beyond just Inc, more “shots on goal” at demand generation by providing funding to additional committed entities who demonstrate progress, etc…then it’s also worth considering the Inc spending baseline rather than just the grants spending baseline.
1 Like
It would be pretty hard to split to smaller O’s due to most of Deligators not having direct connection to O, unless you have a mahoosive self stake.
12.5% seems to be on a big side, personally I do not mind contributing 5% for the good of protocol and bringing demand in. Previous conversations has mentioned halting grants node, saying that could the stake from grants node be moved in to treasury to help it to reach 750k LpT faster (personally I do not think we need that amount either) unless treasury will be throwing LpT left, right and centre for any idea.
Other concern I have is for all deligators is them loosing 12.5 % of their return is a big number to loose, could impact them pulling stake out and reducing amount is staked.
2 Likes
Sadly missed the last watercooler where this was discussed due to a short holiday…
I disagree, the chat feature on etherscan (blockscan chat) is well established. It would be quite easy to ask your delegator to move the stake to your secondary (or 3rd, 4th…) Orchs. E.g. better rates could be offered on those until they fill up.
As I pointed out many times, “punishing” larger nodes/token holder won’t work in the long run in a permissionless system.
If that happens, the inflationary reward would distribute to a smaller set of stakers - increasing their individual share. E.g. if we have a 5% contribution percentage and due to that 5% would unstake, we end up at the same LPT rewards as before.
While we of course all appreciate the effort that Inc. puts into demand generation, I don’t think comparing that to Delta is appropriate. Inc. has way higher financial interest in seeing Livepeer succeed than individual Orchs. With many millions in funding, spending a good amount on demand generation has to be part of the plan (and obviously Inc. also expects a decent return in the long run), regardless of other contributions.
On the values itself: I agree with other Orchs that 12.5% and 750k LPT is a too high initial value. The mentioned 5% (and maybe a 250k ceiling) seems more reasonable until we have a better understanding of how much LPT is needed in the treasury and of its benefits to the network.
One issue with a lower initial value is that the treasury fills up slower. To counter that, a treasuryBalanceFloor of ~30k LPT could be introduced and as long as the balance of the treasury is lower, the treasuryRewardCutRate is doubled. Implementing that should be rather simple, it could just be added to the treasuryBalanceCeiling check.
This floor would fill up rather fast (e.g. in ~35 rounds given the current inflation, a 30k floor and a rate of 5% that is doubled to 10%) and it ensures that there’s always a decent funding available for more spontaneous requests/grants/initiatives.
Thanks everyone for the feedback and discussion around this LIP. As the proposer of the LIP here are some of my brief takes on the various subjects discussed.
Mechanisms that adjust the contribution rate based on current treasury size, or amount of stake delegated towards an O
While I appreciate that nuanced and complex mechanisms may make sense here to incentivize certain types of behavior, I value the simplicity of an easy (relatively) to understand protocol. This makes it possible for actors to reason about and adjust future behavior without needing to account for unknown variables like the stake distribution.
I also believe that anything that can be gamed to economic advantage through sybil mechanisms will be gamed, and think there are negative consequences to MORE, rather than LESS non-transcoding nodes emerge if there are incentives to split stake purely to receive higher rewards.
So I am sticking with a flat treasuryRewardCutRate applied at the protocol level.
The proposed 12.5% rate feeling too high
I hear this feedback. I will lower the rate to 10% in my proposal. A couple thoughts…
- This value can be changed via a simple 5-minute-to-write LIP. If anyone wants to propose changing it in the future based upon how we’re seeing it used, the community can vote.
- I am hesitant to reduce it further initially, because the baseline is not to replicate the existing micro-grants based funding of the community node, but to think more ambitiously - the enable a more sustainable and decentralized ecosystem in the future, complete with additional credible core dev contributors/teams and more independent credible demand gen-focused entities. The time to focus on addressing this is not when faced with a crisis at the last minute, but to lay the groundwork - via building up sustainable public goods funding sources and learning over years - so that the pieces can be in place and any future crisis can be avoided. Let’s populate this now, and begin to experiment and learn. If we aren’t learning or reaping any benefits, governance can be used to reduce the contribution rate.
Again, the community can vote on this proposal, and if it doesn’t pass then someone else can propose the same thing with a different parameter value. But as proposer, I’d like to start with this value.
I’ll update the LIP. From a timing perspective, we’re moving towards the end of internal code review and remediations, and then we can hopefully start a public audit competition next week, which can coincide with moving the LIP to Last Call.
3 Likes
LIP-92 has now moved to the Last Call phase. This means that after at least 10 days pass, it can be moved to the Proposed Phase and open for a vote.
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
It also contains the logic for the treasury contribution, which is set to the same 10% as in the current LIP.
For full details on how to setup your account and what to test, check this guide: Testing the Livepeer Treasury
All feedback is welcome! Especially if you believe there might be any issues whatsoever with the contracts themselves. Thanks!