Thanks for the feedback. There’re a number of different points brought up, so I’ll try to clarify a few things first…
-
It’s come up in the watercooler and in some of the posts here that reducing the 33% target participation seems potentially A) too drastic, and B) too arbitrary. It has been mentioned that the target rate should be based on something a little more meaningful, which is fair. We’ll take a look at the average participation rates over a period of time as a consideration.
-
Inflation is definitely incentivizing participation and increasing the participation rate, although it may have been counteracted by a few large unbonds. Since the turn of the year the p-rate has gone up from 40% to almost 45% - not exclusively from inflation, but inflation has definitely been a contributor. So even though it takes awhile, and has needed inflation rate to go high, it IS having an effect of increasing the p-rate.
If I am reading the Minter contract correctly, implementing an
inflationCeilingshould be relatively straightforward: add theinflationCeilingvariable + getter/setter/constructor and modify this function to decrease towards the ceiling (iff above it).
Do you happen to have a candidate function that would
- Reduce the inflation rate towards the ceiling gradually rather than with a sudden shock to the system?
- Still take participation rate into account to incentivize the target? (Otherwise the target participation is just a useless vanity target, with no impact in the protocol incentives). Is your idea that the p-rate incentives would still exist ONLY when within the Ceiling and Floor range, otherwise it would use a different curve just to trickle downwards gradually?
It’s long been a call to the grants or research community to suggest a different curve than the linear increase/decrease - so it’s very possible, but no one has proposed one yet.
Could someone speak on what kind of timeframe or major barriers we would be looking at?
The protocol is pretty brittle at the moment, with lots of complex state management, bug fixes, etc over the years. The smaller the scope of the change, the more easy it can be validated via the test suite and simulation, and less need for audits and complex analysis.
I think the scope of change your suggesting is relatively straightforward and tractable, but the heavy lift would be the implementors convincing the community with enough confidence that they’ve tested/simulated the impacts and are convinced there’s no side effects. This is the sort of reason we need the protocol security SPE so that there are actually dedicated resources and experts on this. The Livepeer ecosystem has some of the expertise, but they’re largely prioritized on demand generation at the moment, so let’s use treasury funding to train up more people to focus on this.
Lastly, a quick response to @obodur’s comment about “the project just printing money to keep itself going.”
A) The whole point of this thread is to consider ways to limit inflation to reduce that and shift towards fees as a greater % of rewards. (And of course generating demand is a key priority and key to that whole effort).
B) Remember that the Livepeer tokeneconomics are not just “printing more money.” LPT isn’t money. Think of it as a years-long initial token distribution mechanic where the network ownership gets distributed to those who are showing up to do work and help the project accomplish its mission of being an open video infrastructure - whether that’s through node operation, staking, development through grants or treasury, primary capital contribution, etc. Right now that redistribution is happening faster.
Agree that the participation rate being based on something is a great concept. Fees are trivial to fake. “Real” work is impossible to detect vs gamed fake work. There are different economic models Livepeer can consider, and I welcome that research and discussion in other threads or on other work tracks. But I do want to remind everyone about practicality, and addressing one issue at a time with efficient solutions that help move the project forward - rather than disappearing for years on a brand new Livepeer 3.0 experiment that tries to address everything all at once.