Livepeer Fiscal Stimulus Package?

Governance
#1

I was having an idle thought last night.

With all these economies / jurisdictions / financial systems planning stimulus measures in the wake of COVID-19, I was wondering what a Livepeer fiscal stimulus package looks like.

Everything is inevitably going to slow down, at least in the very short term, with schools closing hence more childcare, general conveniences becoming inconvenient, but also in the longer term when (if) “the legacy economy” wakes up again.

Something to ease the financial concerns and give some respite from this pandemic madness. For the permissionless community of people involved and passionate about this project. Whether it’s for the diluted hodlers, the delegators, the orchestrators, the core team, the shareholders, the dApp buidlers, the app builders, the researchers, the cryptographers, the developers of “video-enabled applications”, the people demanding scaled Transcoding, the exchanges, the kid from down the street, or whoever once heard of Livepeer and thought it was a good idea…

How do we keep these people stimulated. If you are reading this, you are likely one of these people. How can the protocol keep you stimulated?

I thought about a proposal to reduce the reduce the InflationChange parameter from the current value of 0.0003% to 0.0002% as a way perhaps to delay the end of inflationary rewards. Would this need a LIP @yondon? What do you think, @dob @ericxtang?

Or, is this the time “not to ask what Livepeer can do for you”, instead, to ask “what you can do for Livepeer”? Some ideas came to mind:

  • Consider how /whether to pivot, as a response to this discontinuity, to keep the community alive, to support the technical vision.
  • Get LPT listed onto another major exchange, to allow more fiat to flow into Livepeer Community?
  • Develop a consumer streaming device for sharing our new socially-distanced lifestyles with others

If anyone is with me on any of these ideas, please ping me on Discord.

1 Like
#2

I thought about a proposal to reduce the reduce the XXXXXX from the current value of 0.0003% to 0.0002% as a way perhaps to delay the end of inflationary rewards. Would this need a LIP @yondon? What do you think, @dob @ericxtang?

This is exactly the type of the change that the LIP process is for. This way the community knows how and where to discuss this as “pre-processing”, before getting to a solid proposal that can be voted on in a poll, and then enacted if it passes.

As to the subject of reducing inflation change itself - it’s one approach. Another would be to raise the “floor” of what inflation can drop to from 0% to something higher. I don’t know what that would be, but let’s just say an arbitrary number like 4%. Or perhaps both of these could be combined. The underlying reason why something like this could be considered is because it’s taking longer to bootstrap the demand side of the network than the current curve allows for continued inflation. So therefore those who stick around to continue to run the supply side should continue to accrue stake in the network for doing so, prior to there being significant fees flowing through to compete for.

3 Likes
#3

OK, that’s interesting, thank you @dob :slight_smile:

As for the concept of a “floor”, this is a Protocol Parameter that I was not aware of :face_with_hand_over_mouth:

Perhaps this should be listed in the livepeer_cli? :thinking:

The parameters currently listed in livepeer_cli, when calling 2. View protocol parameters are as below:

*--------------------------------*--------------------------------*
|                Protocol Paused |                          false |
*--------------------------------*--------------------------------*
|     Max # Active Orchestrators |                            100 |
*--------------------------------*--------------------------------*
|           RoundLength (Blocks) |                           5760 |
*--------------------------------*--------------------------------*
|            RoundLockAmount (%) |                             10 |
*--------------------------------*--------------------------------*
|       UnbondingPeriod (Rounds) |                              7 |
*--------------------------------*--------------------------------*
|                  Inflation (%) |                           0.08 |
*--------------------------------*--------------------------------*
|            InflationChange (%) |                         0.0003 |
*--------------------------------*--------------------------------*
|          TargetBondingRate (%) |                             50 |
*--------------------------------*--------------------------------*
|                   Total Bonded |    13469475.399712216278547535 |
|                                |                            LPT |
*--------------------------------*--------------------------------*
|                   Total Supply |    20198666.105257375922566886 |
|                                |                            LPT |
*--------------------------------*--------------------------------*
| Current Participation Rate (%) |                    66.68497479 |
*--------------------------------*--------------------------------*

Of these, I believe the following can be changed manually by the permissioned keyholders:

  • Protocol Paused
  • Max # Active Orchestrators
  • RoundLength
  • RoundLockAmount
  • UnbondingPeriod
  • InflationChange
  • TargetBondingRate
#4

Proposal: It would be useful for the community to be more aware of what “levers” can be “pulled”, so that they can all be considered as part of any proposed changes.

Are there any other “active” parameters which could be exposed to users in the livepeer_cli? Perhaps this is one for @yondon or @NicoV? :slightly_smiling_face:

If we can discuss this here, I can raise a github issue with proposed additions.

#5

The “floor” is actually not a protocol parameter. It’s coded into the protocol as zero. But making it a parameter could be a good idea if a protocol update were approved that described changing it. I guess process wise there could be a single proposal to make it a parameter, and another to move it independently, or the two could be combined into one proposal. Would be good to hear opinions about the better path. It seems like making it a parameter probably wouldn’t be too contentious, but moving it might be more challenging to get to consensus on a value.