A comprehensive overview of Proposal 29 from the PowerPool Core team
Proposal 29 devoted to re-deploying the Beta/Gamma vesting contract and slashing allocations of 40 inactive testers recently got a lot of attention. After reading comments and discussing the provisions of the proposal with some Beta/Gamma testers we understood that people don’t understand this proposal. So, we decided to release a statement and explain every point comprehensively.
The history of this proposal
As you know, there were 193 Beta/Gamma testers in PowerPool. Each tester should receive 50,000 vested CVP. Initially, the total number of testers was 200, but 7 testers didn’t complete initial tasks and these 7 allocations (350k CVP in total) were transferred to the community pool. The current vesting schedule for 193 allocations as defined in Proposal 6 and the release process started on 1 April.
Proposal 29, Point A
The Management Board (MB) approached us roughly a month ago with an idea to audit the contribution of testers. It was evident that we have 193 testers and we should have a much bigger impact on the project results that we had.
MB backed their idea with statistics of the PowerPool on-chain governance system — a lot of wallets didn’t claim votes and never participated in votings. Remind that 8 months have passed.
So, these statistics revealed that a significant part of testers was almost (or completely) inactive during the whole project journey.
No doubts, that participation in votes isn’t the most objective indicator of testers’ involvement and contribution.
From another side, it is an ideal indirect metric — if the tester even didn’t claim his votes, most probably he wasn’t following the project at all his involvement for very low. Of course, there are testers that contributed significantly off-chain and there is no problem with that. We need input in any form, and if it is an off-chain activity we are grateful for that.
So, the problem of inactive and not-contributing testers is evident. But, how to solve it? Together with the Management Board, we decided to apply a combined approach to this issue, taking into account:
(1) off-chain contributions as a most important (priority) metric
(2) participation in the on-chain governance system and snapshot governance as an additional (second-tier) metric.
So, the process was as follows: MB supplied us with governance statistics, we re-checked it and examined all off-chain testers activity without disclosing identities to MB.
We had four main groups of testers:
- Address never or almost never participated in governance and no off-chain contribution
- Address never or almost never participated in governance, but tester contributed off-chain
- Address “a bit” participated in governance, and “a bit” contributed off-chain
- The address was very active in governance, and actively contributed to off-chain
Description:
(1) are testers that neither follow the project nor contribute off-chain, providing zero value. Red List (slash)
(2) testers for whom we are grateful for their input, but strongly advise being more active on-chain. Green list (all is ok)
(3) testers we cannot define as very active; however, they followed the project all the time, voted, and provided some support off-chain. Yellow list (need to prove their value in the future)
(4) very active testers for whom we are extremely grateful for their support & engagement. Green list (all is ok)
We have 40 testers falling into (1) category that should be slashed. We additionally want to remind you that we excluded from this list all testers that did something valuable for the project off-chain but didn’t vote due to some reasons. There wasn’t a situation when somebody really helped the project and was slashed. Moreover, the majority of these testers barely respond to messengers and even didn’t read/reply to our reminder messages regarding new proposals and updates. Thus, they were not interested in the project.
It is evident that by slashing inactive testers we decrease future selling pressure for CVP making the stakes of other testers and ordinary CVP holders more valuable.
Why do people who did nothing for the project’s success need to dump their tokens on the community? It is not fair.
Proposal 29, Point B
Point B was related to the technical necessity to re-deploy the contract in order to execute Point A. The fact is that in the current vesting contract we cannot slash selected wallets. We can burn all tokens (applying an almost infinite vesting period to them) and deploy the new contract with a new batch of CVP tokens. So, 9.6M CVP will be irreversibly burnt, and not slashed testers will receive new CVP tokens on the new contract.
Proposal 29, Point C
The main point of discussion for this proposal was Point C. Originally it was defined as:
We propose the following rules for management of testers’ allocations. For every tester allocation the following decisions can be made by Management Board:
Vesting period for tokens and votes (voting vesting) can be prolonged for any tester allocation with no limits on number of such extensions or their duration
The remaining tokens (amount that is vested) can be transferred to a zero address what is equal to burning them
Contract management and team capabilities:
The contract will be managed by the team multi-sig
Team will verify every proposal for vesting prolonging/slashing from Management Board based on their own data (including off-chain contribution) before executing such a decision.
First of all, why do we need this function of prolonging vesting/slashing? The answer is simple — a lot of testers didn’t do much yet. They are on the yellow list and we expect input from them. It is evident that statistically there will be a percentage of testers that wouldn’t contribute/vote and will almost disappear not responding on messengers. We need an option to prolong vesting or slash (a very extreme option that we don’t plan to use often, hopefully, we wouldn’t use it ever) for this kind of tester. Our first priority is to protect the CVP value of other testers and the CVP community. Our community doesn’t want to pay huge sums to testers that do nothing.
We got a lot of negative feedback on this proposal and this is why:
1. Testers (mainly from the green list) think that anyone can be slashed if MB or the team will have a bad mood or something like that.
Explaining: first of all, MB cannot slash anyone. The team controls the multisig and can update the contract. As a team, we are in personal contact with all the testers and never will slash anyone who contributes to the project/participates in governance/responds in messengers, and is willing to help.
2. It is a dictatorship/totalitarian approach to have an option to slash somebody or prolong vesting
Explaining: we don’t think that protecting our community from freeriders is a dictatorship. We as the team know all testers’ contributions, and they can be not only public ones. So, only the team has a really clear picture regarding all testers. And besides, that team has trust and reputation and obviously has zero motivation to slash/prolong vesting undeservedly. Why should we do that? On the other hand, we will be happy if we have testers that help the project grow. Slashing such testers it’s like shooting yourself in the foot.
So, finally, we don’t plan to slash/prolong vesting randomly. It is crazy. We can put it on the general community voting, but how will people make decisions? If these testers aren’t following the project, they wouldn’t respond to the forum topic.
How to solve the issue with Point C:
- Grant a final decision for prolonging vesting/slashing to the CVP community. So, the team and MB will be able only to propose it, while the CVP community should decide how to deal with it.
- Set up a “trial period” at the end of which the community will evaluate testers’ activities (on-chain and off-chain — based on the team data) and make a decision if there is the necessity to prolong vesting or slash someone (we would very much like to never use this option). After this period testers’ allocations wouldn’t be revised.
Option 2 was proposed by one of the PowerPool testers. We expect that he will publish his idea on the forum soon. We will update this article with new data from the forum if necessary.
