Inflation rate formula

[TurboUrbo]

Inflation rate formula Team call on Curve Bonding topic @igorline

[TurboUrbo]

User requirements and technical implementation choices we are considering for Hive Commons’ implementation of Liquid Democracy. https://medium.com/hive-commons/liquid-democracy-ethereum-and-the-slow-path-to-revolution-9c1d5916e706

[pasha0x]

Haven't found more related issue so decided to add this overview here. I was looking to digest Kyodo incentivation model and visualized it. Below some sort of model of inflation as motivation engine for organization to thrive and for its participants to be and stay active contributors. Including an attempt to define inflation rate and proposals for ordinary and extreme situations. Would love to discuss and debate on it if you find some time to check it.

[igorline]

Amazing work @pasha0x! I'll digest it tomorrow and suggest we have a short (<1h) during the week together with @TurboUrbo

[igorline]

Great, @pasha0x! I just finished exploring your research!

Couple of questions:

1. Sentiment means how members feel over activity and assets valuation, right?
2. Three long term expectations are related to pairs of cases (1-2, 3-4, 5-6)?
3. In third assumption you write about "external" sources of revenue that are not related to minting of new tokens. What this revenue might be and why we should not issue new tokens on it?

[pasha0x]

Thank you, @igorline for diving into!

1. Yes, projected dominant sentiment of participants ( "--" for non-productive, lost interest, depressed, "++" for productive, enthusiastic, "+-" for normal, medium well)
2. Yes, rough forecast allowed me to group those cases basing on similarities of their main outcomes
3. Under "external source of revenue" I mean all revenue that is not related to positive price dynamic of tokens/assets inside Treasury. Basically all sorts of operational("normal") revenue: -grants/prizes won; -consulting fees; -positive funds management; -dividends from productive assets etc.

Why I think revenue should be allocated to Treasury without minting new tokens? Thought I had ready answer for this one but I hadn't :) I need some time to review my arguments.

[TurboUrbo]

@pasha0x I think this is the smart model - not minting new tokens for a revenue. In this case the token price only depends on members activity. I also agree with that overall activity should't count delegated tipping as active performance (i.e. delegators are not active). The inflation rate motivates the activity! Nash equilibrium!))

[igorline]

@pasha0x can you, please, post the link for your latest research here.

One thing that we forgot to discuss, as I was planning token owners should be available to "cash out" by burning tokens during short period once in a month (there are might be limits, some locking logic, etc). Also we might be able to sell some amount of DF tokens monthly to external community. That might be our friends that might not be taking part in the fund activities, but would like to follow our index and store their value in our token. We might get it implemented using Set protocol https://setprotocol.com/

[igorline]

Keeping this in mind, we should smooth the token price value to avoid speculation on sudden token price increase in particular period. That's pending to be modeled actually

[pasha0x]

Hey! I think we should explore current model defining its flaws and strengths. Then compare to what Bonding Curve model can offer.

Below I've detailed and illustrated majority of cases. Added Entry and Exit options on entering and "cashing out" from Fund. Maybe you know other options for this model?

Also edited the file to be more readable and structured. Please, share your thoughts and ideas.

https://docs.google.com/document/d/1ufGXPggvF9y68o03WfJ4GixUu5GK4ByMR1hFsRYDdG8/edit?usp=sharing

[pasha0x]

@pasha0x @TurboUrbo I suggest to start with something simple. Define activity rate through ratio of spent points in period to total points at the start of period (regardless of revenue value). Activity = Pspent/Ptotal

Insert following dependency to define inflation rate: In case when activity rate = 0, define inflation as 5%. .. In case when activity rate is 0,5 define inflation as 2.5% .. In case when activity rate = 1(all points are spent by all users), define infation as 0%

So the higher the activity the lower the inflation would be. This approach is more clear(than I've previously described in hackmd doc) and won't require complicated calculation from member. Also it would be easier to implement(in current period), analyze the issues and improve it in future.

Notes: -non-staked-as-bounty reserve points shouldn't be count in Ptotal when evaluating activity rate; -in case 0 activity minted tokens could go to reserve (or we can figure out min activity rate when inflation becomes activated); -maybe total number of points should be always round like 1000 for instance? In this case points will be assigned to users pro rata to their share. It would be more convenient when assesing size of tip. Mainly, because it's round and also won't change in future comparing it to current situation where pool of points is growing with DF supply. On the other hand when Fund will grow in size, it becomes inconvinient.

What do you think?

[pasha0x]

Keeping this in mind, we should smooth the token price value to avoid speculation on sudden token price increase in particular period. That's pending to be modeled actually

This is another reason why bonding curve is interesting. You can burn tokens when the price is high for you. And then buy them back and "return to organization". In case of DF it feels more like closed joint-stock company because exiting is easy but entering is somewhat difficult. Issuing new tokens for newcomer leads to decrease of other members' share.

Also bonding curve is far more friendly to early contributors and passive holders than inflation :) This is better illustrated in "Inflation + delegation 3" sheet https://docs.google.com/spreadsheets/d/1TtiqKq7Dk7jH90QVS7hJ702zd_4lqgflaCuWDFzc7RU/edit#gid=313820698 Bob hasn't been delegator or delegate but he has spent all his points being actively rewarding others. Alice did the same as Bob but managed to earn some points. Though both are punished by inflation: their DF balance increased but share and $ decreased. Basically, in non-revenue periods Alice and Bob "pay" with their $ balance to more active members. This feels uncomfortable but somewhat fair.

But Bob and Alice were pretty active and maybe reserve tokens should be used to cover their losses? If so, question of determining criteria arises. Which opens door to gaming the system and cut off incentives for active contributors.

Eventually, inactive users and passive holders will see that "cashing out" as best option for them. I can't tell whether this is good or not.

[pasha0x]

@pasha0x I think this is the smart model - not minting new tokens for a revenue. In this case the token price only depends on members activity. I also agree with that overall activity should't count delegated tipping as active performance (i.e. delegators are not active). The inflation rate motivates the activity! Nash equilibrium!))

@TurboUrbo I think delegated tipping should be included in total activity in approach above. Because it's the only leverage of influence for inactive member: spent as much of his points as it possible to lower the inflation. https://github.com/decentfund/kyodo/issues/174 What are your thoughts on this one?

[TurboUrbo]

@pasha0x @TurboUrbo I suggest to start with something simple. Define activity rate through ratio of spent points in period to total points at the start of period (regardless of revenue value). Activity = Pspent/Ptotal

Insert following dependency to define inflation rate: In case when activity rate = 0, define inflation as 5%. .. In case when activity rate is 0,5 define inflation as 2.5% .. In case when activity rate = 1(all points are spent by all users), define infation as 0%

So the higher the activity the lower the inflation would be. This approach is more clear(than I've previously described in hackmd doc) and won't require complicated calculation from member. Also it would be easier to implement(in current period), analyze the issues and improve it in future.

Notes: -non-staked-as-bounty reserve points shouldn't be count in Ptotal when evaluating activity rate; -in case 0 activity minted tokens could go to reserve (or we can figure out min activity rate when inflation becomes activated); -maybe total number of points should be always round like 1000 for instance? In this case points will be assigned to users pro rata to their share. It would be more convenient when assesing size of tip. Mainly, because it's round and also won't change in future comparing it to current situation where pool of points is growing with DF supply. On the other hand when Fund will grow in size, it becomes inconvinient.

What do you think?

I like this model! It's simple and meets the challenges.

"be assigned to users pro rata to their share" - not really clear for me, but i support the fix amount of points for a period. It really would be easier to define a size tip and doesn't complicate the DF supply calculation.

[TurboUrbo]

@pasha0x I think this is the smart model - not minting new tokens for a revenue. In this case the token price only depends on members activity. I also agree with that overall activity should't count delegated tipping as active performance (i.e. delegators are not active). The inflation rate motivates the activity! Nash equilibrium!))

@TurboUrbo I think delegated tipping should be included in total activity in approach above. Because it's the only leverage of influence for inactive member: spent as much of his points as it possible to lower the inflation.

174

What are your thoughts on this one?

Makes sense, totally.

[pasha0x]

@pasha0x @TurboUrbo -maybe total number of points should be always round like 1000 for instance? In this case points will be assigned to users pro rata to their share. It would be more convenient when assesing size of tip. Mainly, because it's round and also won't change in future comparing it to current situation where pool of points is growing with DF supply. On the other hand when Fund will grow in size, it becomes inconvinient. What do you think?

I like this model! It's simple and meets the challenges.

"be assigned to users pro rata to their share" - not really clear for me, but i support the fix amount of points for a period. It really would be easier to define a size tip and doesn't complicate the DF supply calculation.

@TurboUrbo @igorline Igor goes further and suggests the following: Each member gets 1000 points at the start of period regardless of his share, DF tokens balance etc. This eliminates problem of figuring out the tip size. Also this approach excludes "emotional" factor: for instance, in current system I tip you with 5 points, Igor tips you with 50. My tip is small not because I assess your contribution so poorly or because I'm greedy bastard but because I have less points. But it's not always clear for members, I think. In Igor's proposal you clearly see how I assess your contribution.

This proposal requires only one additional calculation before fixing proportion of earned points: point's weight of each member.