New Karma System - Proposal

We could perhaps use the algo to award the points prizes each month for the top three cross project stakers and also have a community voted prize for top three contributers for the things that the algo can’t capture like engagement that p suggested. So two monthly points prizes… Just thinking aloud here

1 Like

Which specific ideas are you referring to that you think are good?
Sorry my English is not good.


Sorry, I think what I wrote was a little bit confusing.

I was just commenting on Rob’s argument that not selling is a better and more simple variable to measure a new Karma point system.

Creators that are not selling = Creating a sustainable price environment.
Stakers = positive ecosystem impact, funding more projects.

All Creators that Stake on other projects are not selling. So by using not selling as a variable we would encompass both positive behaviors directly and indirectly from a sustainability point of view.

There are three states in which the author has not sold the DEV token as follows

  1. the author is holding an undrawn reward… x
  2. author is holding DEV … y
  3. author is staking DEV… z

The new karma is going to be calculated by weighting these three variables.

karma = x3 + y2 + z*1

I need your input.
@Pdot @Rob

Good formula. I agree with it.

1 Like

I still need to think about the weight, though.
I think this is the right direction to go.

P-san said

「I’m not on my computer anymore, but I think that a 2x weight for staking and 1x for each other variable is the way to go.」

Do you think we should take into account the percentage of property tokens held in the reward amount before withdrawal?

For example, HiDE’s author does not hold a property token, so

the author is holding an undrawn reward ... x
author is holding DEV ... y
author is staking DEV ... z

x will be zero.

Personally, I don’t think it should be taken into account.
The reason is that it would be simple.

I am confused whether you guys are on board with my idea of using karma ‘points’ as the basis of the amount that can be withdrawn at any one time or not?

This needs to be decided prior to creating a formula in my opinion.

I support the concept of adjusting rewards according to contribution levels. I hope it will work to ensure that the protocol maintains a healthy network. On the other hand, measuring the contribution would be a very challenging topic.

Now we need to think carefully about what is “positive” and what is “negative”. I often think of a “small village in the countryside” when I try to organize these thoughts. What actions should be taken to ensure that the village achieves positive growth? I don’t have an absolute answer, but I do think that tolerance and deliberation are needed. We need to be open to new things and have a large number of villagers participating in government.

Perhaps what is “positive” and what is “negative” will constantly be changing, and the criteria will reflect the diversity of the people. So I like the basic concept of leaving each individual to decide what is positive or negative. The protocol does not control those criteria. Instead, people evaluate the project by voting or by some other dynamics.


I think these are very wise words Aggre

・Display order on
・Reward withdrawal limit
Karma will be used for the following purposes.

First of all, I would like to use Karma only for the display order of, and after running it for a while, I would like to discuss whether to use it for the limit of withdrawing rewards or not.

What do you think?

1 Like

I think the whole revised system pivots on the reward withdrawal limit, so this should be the initial priority.

Another reason to do this first = the sorting of the page may change if we integrate the bronze, silver, gold status (as originally proposed, which is yet to be discussed).

We need to establish how the new points system will accrue…

I think what P-san proposed would work well:
Each creator automatically accrues 5 karma points per day (which equals 1825 points a year, which if one to one with dev would mean that there is a base limit of withdrawing 1825 Dev’s per year - before any community voted additions or subtractions).

The community voted additions and subtractions are what will essentially enable the ‘small village’ approach. These can be integrated later and discussed in further detail in another thread.

1 Like

Perfectly put.

I like the idea. I think that this should be implemented first if the option of increasing the withdrawal limit is too challenging and not optimal right now. But, as Rob mentioned, it would only be efficient if the withdrawal increase or some other sort if incentive is in place, otherwise it will be just a metric.

I tend to think that 5 karma points per day should be the limit. It should be based on the amount of Devs staked, maybe a gaussian distribution or setting the biggest Creator staker at 2.5 (think of the weights on the other variables) and the rest of them are proportionally accrued.

I also like Akira weighted formula, so these weighted to daily points could be all calculated with the idea above.

I wouldn’t call the proposal a withdrawl ‘increase’ as such. Its more changing the mechanism to accruing withdrawal rights per day.

I also think we keep it simple as to how it’s calculated as this needs to be marketed to creators (who will use it to financially plan). A set amount per day imo is the way to go.

Yeah, if it means to completely substitute the current limit, than it is perfectly fine being 5 dev a day.
If it is used to increase the withdrawal limit, then it should be lower than that.

I suppose it’s possible that in the future we could use karma to cap withdrawals.

but, The withdrawal of creator rewards is already limited in DIP55.
I believe that if we add more conditions, it may become too complicated and creators may not understand and leave.

What do you think about that?


p-san said

Haha at this point I think that just implementing the new formula, even if just as a metric, knowing that it probably won't change Creators and Stakers behavior by itself, is the way. Then we could have another discussion on how to improve DIP55, introducing this new Karma + new features like the 'small village' voting.

i think so, too.

@Pdot @Rob

What’s complicated about using points as ‘tickets’ to withdraw Dev? I think it’s more transparent to only be able to withdraw Dev based on the amount of points creators have? One for one.

That way when they withdraw the community can easily see, as it will deduct points from them and adjust their ranking in (maybe also dropping them down from gold or silver status).

1 Like

If we didn’t adjust as above my comments are as follows:

DIP55 in its current form is far more confusing.
It should be a fixed amount of Devs so that creators can financially plan (I’m not sure I agree with adjusting it based on liquidity). Ask yourself how do we market the limit to creators?

It needs to have a visual interface that shows how close they are to the limit, so there are no surprises.

It also needs a mechanism so that they can increase the limit for good behaviour, based on community feedback (the small village voting). Without this they are disincentivised from using the platform once they have reached their limits = problem and this will roll over into the following years as they don’t stop accruing an APY once they’ve reached their limits.

1 Like

It has become a complicated topic for newcomers as various concepts have been proposed, so I would like to organize my thoughts here.

The decisive factor in many concepts is the abolition of DIP-55.

And the alternative concept is a linearly increasing withdrawal limit of 5 DEV/day. The number “5” can be increased or decreased by community voting.

I think this concept is straightforward and natural.

My questions are:

  • All concepts only adjust the withdrawal limit and do not affect the lifetime reward itself. (Is this the same as DIP-55?)
  • All concepts do not affect the rewards for staking users.

I think voters and beneficiaries should not be the same person and should not affect the rewards for staking users.

1 Like