governance: token volatility (payment buffers)

[mochet]

This issue is a tracking issue, I am working on some areas of governance and exploring topics (which is not on GitHub or any public space yet). I attempt for these to be neutral but they are obviously my own ideas written based on my own interpretations. Nothing is finalized at all--these are just topics and anything that may be introduced would follow the ordinary route that previous governance proposals have taken, including a discussion phase.

The price of the token after launch will fluctuate, there should be at least some ground rules to cover things like:

• Discrepancy in value of a spending proposal comparing the value at creation time versus finalize time (depends on how many tokens a proposal is asking for)
• Lead salary payment adjustments (expensive to change as requires proposals)
• Worker salary payment adjustments (depends how many workers and how much it costs to issue these adjustments)

Origin:

• We already have an approved proposal (https://testnet.joystream.org/#/proposals/94) that has been used on Joystream's incentivized testnet for almost a year. It was introduced as a way to better define if and when adjustments to payments would be necessary and helped to introduce some definition of token volatility for governance and payment purposes.
• The original text stated: When checking the reward of leads or workers, no adjustment needs to be taken unless the rewards are +/- 5% based on the current exchange rate.
• This proposal was later adjusted (https://testnet.joystream.org/#/proposals/248) to When checking the reward of leads or workers, no adjustment needs to be taken unless the rewards are outside of -2% > +5% based on the current exchange rate.

Limitations of original proposal:

• It did not take into account spending proposals
• It did not take into account that some payment adjustments are far more costly to action (WG lead payments require a proposal for each adjustment)
• It did not take into account how expensive transactions to adjust worker payments may be as fees did not exist
• It did not take into account if we would want to limit worker payment adjustments due to transaction spam or the scale of workers on the platform (it was introduced at a time when we had only 6-12 workers in total on the platform)
• It did not take into account the value of cheap vs expensive payments. I think that volatility for lower and higher amounts has different impacts and should be accounted for.
• It did not take into account bounties (they did not exist) -- it is unknown if there is any way to deal with these in the scope of this
• It did not take into account channel payments (they did not exist)