Solve Zero-Sum negative incentives

[AngelaKTE]

Description

While re-weighting allows to increase the voting weight of our stakeholder group Red overall, it can decrease the voting weight of individual achievement tokens in certain cases. Here's why: the target cweight is defined on an accumulated level, thus any individual achievement token receives a share of this voting power.

Let's assume Yellow achievement tokens have a total supply of 100, and Blue achievement tokens of 40. According to Dynamic Network-Weight Scaling, Yellow achievement tokens have a voting weight of 0.01, while Blue achievement tokens weight 0.025.

What if 10 more community members acquire a Blue achievement token? It's great for the community, but in fact it hurts the voting weight of the individual achievement token holders, since their voting weights shrinks down to 0.2 Worst case this could lead token holders to keeping newcomers from gaining acquiring new achievements. Bad for the community! How can we avoid these effects?

[linear[bot]]

TE-53 Solve Zero-Sum negative incentives

[AngelaKTE]

Copy from Discord:

I think I have found a solution to the "negative incentive - zero-sum game problem":

The problem, for reference: https://linear.app/te-academy/issue/TE-53/solve-zero-sum-negative-incentives](https://github.com/TE-Academy/Reputation-based_Weighted_Voting/issues/33)

Let's check: the problem's root cause is that we define a certain targetcweight to scale to, so that the fundamental properties are met our current calculation of the targetcweight is to take the largest stakeholder groups cweight as targetcweight targetcweight_largestgroup = supply x weight as a result, if a "smaller" stakeholder group's number of NFTs grows, the targetcweight doesn't and hence, the weight of these NFTs decline

the solution is in how we calculate the targetcweight for simplicity I assume that all NFTs initial weight = 1 (equal weights for all NFTs) if we calculate targetcweight = supplygroupRed x supplygroupBlue x supplygroupYellow and then scale the cweights accordingly, we solve the problem then, no matter what group grows the number of NFTs, all individual NFT weights either benefit, or remain unchanged we can add initial weights to the calculation, we'd then land at `targetcweight = Redcweight x Bluecweight x Yellowcweight

[AngelaKTE]

Copy @octopus / Discord:

8 think 8 understand the issue better now -- i.e. it's about absolute weight not decreasing, rather than relative voting weight? Like amount of money vs. purchasing power. Perhaps you could give a concrete example of what needs to be avoided, ideally? 🐙 octopus — heute um 15:29 Uhr Is this right: there is one student NFT, worth 1.0 there is one expert NFT, weight to be determined

currently there are 10 student NFTs in existence, so student_cweight = 10 there is one expert NFT, so expert_cweight = 10. That one expert has 50% of the total voting power.

A new expert enters and is awarded an expert NFT, so now there are two voters with the expert NFT. student_cweight stays 10 expert_cweight stays 10, but now the actual weight for the single NFT becomes 5. each expert has 25% of the total voting power now. Is the goal that: goal 1. issuing a new expert NFT doesn't decrease the weight given to each copy of that specific NFT, or goal 2. issuing a new expert NFT doesn't decrease the relative influence of the existing individuals?

or something else that I'm missing? 🙂

[AngelaKTE]

Copy from Discord:

Thanks for checking.

goal1: YES goal2: YES, issuing a new expert NFT doesn't decrease the relative influence of the existing individuals/or NFTs compared to other members in the same stakeholder group However, it does change the relative influence of existing individuals/NFTs to NFTs in other stakeholder groups, since the accumulated weight of the groups are balanced (our fundamental property) But this is OK;

What I want to achieve here is that we don't hurt each other within the group. If we assume that in an actual voting not all members show up, this variant of targetcweight has less bad effects on the individual.

[AngelaKTE]

@octopus /Discord:

Interesting idea! I'll come back to it next week, and we can run some simulations. 🙂

[AngelaKTE]

Copy Discord:

Ah, just understood that if we take the same combination of voters, the two approaches a) targetcweigth = highest cweight b) targetcweight = Redcweight x Bluecweight x Yellowcweight have zero difference.

Now we could simulate certain scenarios and see if there are benefits in certain cases. I'd love to fully understand! But I also don't want to waste our time.

If in terms of voting weight effects both approaches are equal, I'd go for b) still, because it "feels" that we all win, and accumulate reputation in the ecosystem. And I'll accept that we can't overcome the zero-sum problem, sadly 😔

[eightarmsninebrains]

I'd be happy to explore further, though 8 personally think this is less pressing than some other Issues for our current target.

The key step is to get a clear list of the scenario/story we are looking at, and what properties/requirements need to be met in that story.

The concepts of absolute weight and relative weight for voters may be helpful.

e.g. possible requirement. (Is this what is actually wanted?) When a user receives a new NFT, and new weights are calculated, each voter has at least as much absolute weight as they did before the new calculations.

It may be that this requirement is incompatible with the "fundamental property" requirement.

[eightarmsninebrains]

8 request to be unassigned from this Issue.