Project governance

Still trying to decide about that, communication is going of for some time now.

The way I see it worst that can happen is that we design a good governance system in vain :stuck_out_tongue:

1 Like

Then they don’t get to vote. I don’t think this is a concern, though I understand what you are implying about who constitutes the voter base.

The snapshot date should not be declared in advance. If individuals buy coins in anticipation of a vote without a clear announcement of a snapshot date, then I believe they are better than the traditional momentary pump and dump, and should be treated as having stake in the system for the purposes of the election. Because really we are trying to do a less-formal proof of stake here in the context of elections.

This is the theory anyway. I still think it would be good to give the foundation blackballing power.

This leaves space for corruption in the org which organizes the elections. I still prefer that it’s per solved block in past year, at value of UTXO which has solved the block - cumulatively to the day when the ballots are sent out.

1 Like

What happens if you mint twice with the same utxo? Are there opportunities for gaming the system by using larger outputs? What if you mint once, move the coins, mint again at another address? The assumed solution to that is to use coindays instead. I also fear that this approach devalues continuous minting as opposed to those that mint one large output once a year (preferably just before the vote, if we’re using coindays). Also, it entirely cuts out traders from the process, though the cost/reward of that is definitely a philosophical argument.

I would prefer 1 mint = 1 vote or mint rewards = votes as opposed to this system.

Gets summed up per this proposal.

Yeah, we may be forced to go with this.

Let’s look at the best case scenario too: we put something simple in place quickly that can be improved upon and get to the same place but with money in the bank asap

I just wanted to suggested something. Mind you I am not a coder and don’t know what’s involved or if it’s even possible.

Nu’s Motion Voting (1 vote per minted block)

Many of us here are familiar with NuBits and their voting system. In Nu’s motion voting, every time you mint a block, you add a vote to the chain. The more blocks you mint, the more votes you add. Those with large stakes get a bigger say than those with small stakes. The reason for this is because large stakeholders have more chances to mint blocks. This is completely fine in my opinion, as your voting weight should be proportional to how much stake you own.

In Nu’s model, the stakeholder can only add votes to the blockchain by minting blocks themselves. Unfortunately, this can take a long time, as you need to wait for enough blocks to be minted before you start seeing results. Nu has 1 minute blocks, while Peercoin has 10 minute blocks. If we were to use Nu’s voting system, it would take Peercoin 10 times longer to get results, because of the difference in block spacing. Small stakeholders may also not be able to get their vote counted due to the smaller chance of minting a block within the time window of voting.

Utilize Memory Pool for Quicker Voting

I was wondering if it’s possible to treat votes like we do transactions. Users would pay a transaction fee and cast their vote using the client. Once cast, the vote gets transmitted to Peercoin’s memory pool and immediately gets included in the next block, no waiting required. This prevents voters from needing to rely on the chances of minting their own blocks.

Instead, voters can take advantage of other people in the network who are minting blocks. This allows many people, even those with small stakes, to quickly get their votes included in the blockchain. They just pay the fee to send their vote out into the network, it gets collected by the memory pool while waiting to be included in the next block.

This would speed up voting considerably, compared with Nu’s model. For small stakeholders, instead of waiting possibly weeks or months to mint a block with your included vote, you could do it in about 10 minutes by relying on the next block producer to include it.

Rules & Conditions

Of course, it would require some extra rules to be programmed in for it to work right…

1. Every vote should include a weight by taking into consideration the size of a user’s stake.

2. Multiple votes for the same issue need to be rejected by the network. Only one vote should count.

3. Votes should only be accepted if the address you are voting with has minted a block within a certain time period. This proves you are an active participant of the network, and not simply a speculator.

4. Question to consider: Should your voting weight be dependent on your balance at the time you submit your vote, or what your balance was the last time you minted a block?

5. Question to consider: What happens if a large stakeholder has been sitting on their PPC for years without participating in security? Suddenly they see an election is happening, so they activate minting to produce one block just so they become eligible to vote. In my opinion this kind of stakeholder should not get a say, since they are not an active participant in the network’s security. Is there some rule that can be coded to identify lazy stakeholders like this so the system can reject their vote?


Peerchemist told me the following…

I believe the 3rd rule above should help prevent this. Basically, all votes by an address would be rejected by the network if the voter has not minted a block from that address within a specified time period. It takes 30 days to become eligible to mint blocks. As long as you schedule the start and end of the election before 30 days, people buying PPC off exchanges should not be able to influence the vote, since it will end before they become eligible.

Again, I’m not a blockchain coder, so there is probably a lot of stuff I’m not considering. I just wanted to put it out there as an option.

Missed this on my first read. This is good.

1 Like

Started writing some scripts to get understanding on what is to be done here.

One interesting info I got so far is that 1469 unique addresses have minted between block #450000 (2019-08-30) and block #530000 (2020-11-10).

1 Like

That is very interesting info.

Keep the stats coming!

I’m really not sure about blackballing exchanges.

The fact of the matter is users have put their coin there, giving the exchange very significant responsibility. So another way of looking at this is simply setting the standard that all coins and all addresses are the same and if your coin is on an exchange, they are going to end up being able to vote with your stake.

Using mint rewards for votes satisfies my concerns, including those implied by the blackballing concept. Mint rewards are in my opinion directly proportional to participation in the governance of the chain, to the best estimate we currently have.


i like that idea also, mint rewards become votes

1 Like

Here is a quick python script which finds voters and their vote count.

1 Like

I guess it should be ported to js, so it runs in one of those online REPL consoles and can easily be ported to a web app later on.

@jacob linked this Twitter thread above. I thought it was pretty enlightening, so I just wanted to draw some more attention to it. You don’t have to read the whole thing, as most of the important points are laid out in the first half…

1 Like

Very good post.

I totally agree with the article. I’ve been on a Committee for 20 years (for an organisation of 300 people) and all the decisions and activity are done by a small number of people (five at most).

We used to have Annual General Meetings, when members voted for committee officers, but usually only a tenth of ordinary members would attend, and the votes were really just a formality. The fact is that most members are happy to let officers “get on with it”, and so long as members get updates, they keep rejoining.

We eventually abandoned the AGM, as it did not resolve problems. We found that it is more important to have controls within the committee, such as a required level of transparency, and ensuring a second person has access to passwords, the membership list, etc. in case an executive officer goes awol.

How I imagine the elections to look like / be organized:


Foundation - Stichting Peercoin Foundation, a legal organization established to serve as legal face of the Peercoin project.
Voters - minters who have solved a block at least once in last year.
Leader - leader of the Peercoin project.
Team - cabinet led by the Leader.

Timeline of elections

  1. Foundation proclaims that there will be the elections and explains the rules to community.
    • Rules are the threshold, the duration of the elections and other details like that.
  2. Foundation distributes the ballots to voters.
  3. Voters deposit ballots in the address which matches their favorite candidate.
  4. Upon crossing the threshold of support for the candidate (66%+ per current proposal), Foundation proclaims the winner and starts the transfer of control to the elected Leader and the Team.

Technical details

It is best all of this is made into a webapp and as it’s the norm for all our present webapps hosted on the GitHub so clients load it directly from the github. No servers involved. There is no need to communicate with any external servers as all can be deduced and calculated from the chain directly.

For example:

A sidenote:

I had someone ask me what is a webapp, so I’ll explain. It’s a website. Yep, just a website. Website which can do all the features explained in this post.


Ballots are found by a simple algo:

  1. Find all PoS blocks in the past year
  2. Find out what was the mint reward (block subsidy) of all those blocks
  3. Find the pubkey which found the block (address)
  4. If pubkey has found a block more than once in the past year, reward is summed up.
    • Sum of all the mint rewards is referred to as “weight” later in the text.

You can check the sample code here.

Ballot is a min-value UTXO, think 0.01 PPC or so. It is sent manually from the Foundation to each eligible pubkey. Foundation is sending the ballots out to not disrupt the minting process of active minters. They do not have to burn coinage by moving coins around.


Votes are ballots weighted by stake.
Each candidate is associated to an address. Votes are cast by simply transferring the ballot into the address which matches the voters favorite candidate.

User perspective

How I imagine voting would look like from the perspective of the user.
All info would be present on the, voters, ballots, vote counting and the process of voting itself. Everyone would be able to validate data on their own, as there is no central server it’s all parsed from the blockchain directly.

Active minters would go to and run their local Peercoin node with allowed RPC connection. The webapp would query the node for ballots, and if there are ballots received it would prepare the voting transaction. Such transaction would be loaded into the Peercoin wallet, signed and sent.

That’s it.

Results of voting could be followed in real time on


This is a good description of a basic strategy for voting. I would like to point out one issue I have, which is with reference to the 66% supermajority threshold. If we choose to use anything other than a plurality, we need to think about what happens if no candidate achieves the threshold required. Having to do the vote multiple times is inefficient, as is advanced voting options such as 'ranked choices, which are known solutions to avoid developing a 2 party system which plagues plurality-based voting. I know you expect somewhat unanimous voting, but why have voting at all if we can’t accommodate the possibility of a close race between two candidates? If we have two really good candidates, and one gets 51% while the other gets 49%, what happens? It doesn’t make sense to do nothing and keep the old leader, who may be neither of these candidates. Supermajority voting doesn’t really work for elections where a decision must be made and there is no default ‘do nothing’ option.

One option for a form of ranked choice would be:
3 candidates, 2 of which are similar and one very different. The two that are similar make it clear that when one of them receives less votes than the other, they will give their votes to the other candidate. In this way, the two addresses no longer represent just 2 separate candidates, but rather they represent ranked choice votes with one candidate first and the other second. We could hypothetically do full ranked choice this with any number of candidates, though the number of addresses grows quickly with the number of candidates. 2 candidates, 2 addresses. 3 candidates, 6 addresses. 4 candidates, 24 addresses.