Project governance

General
1

We are conditioned by potential investor to resolve the governance of the project in order to receive funding. Specifically the management which is currently done by the Project Leader and the team. Potential investor wants us to design and implement a system which would allow for election of the leader and the team.

During conversation with the investor yesterday I’ve proposed the following:

  1. Define the roles: what does the project leader do, what does the team do, what do stakeholders (coin owners) do, …? Define how are roles elected and how are they removed from power if they stray from their goals.
  • This would be like a constitution.
  1. Design the election process which would elect the leader and his team.

Governance model:

This is more of a managerial role, handling day to day activities of the project and organizing the development. Governance over the protocol and meritocratic process of deciding about protocol updates are not to be meddled with. We stay with the RFC process as it is, the primary role of the project leader and the team is always to find ways to implement proposed RFCs and deploy the
software.

Elections

  1. A project leader is the central figure of the process.
  2. Project leader candidate nominates self to become the new official project leader.
  3. In his candidature he proposes the future team (unlimited number of persons) at arbitrary roles.
  4. In his candidature he proposes a strategy/plan for next time period (6M min, 3Y max) and goals which should be fulfilled during this time period.
  5. In his candidature he proposes the budget required for the proposed time period.
  6. It is the duty of the candidate to find at least 75% of funding for this plan before his term begins.
  7. The leader and the team can ask the community or the Foundation to come up with the remainder of the funding before his term begins.
  8. At any time during the term leader/team can ask for additional funding from 3rd party sources and/or the community and Foundation.

On-chain voting for the elections

Protocol is basically a poll. Stakeholders pick a candidate from a list of candidates. Majority wins. Simple as that.

1 coin should be equal to 1 vote. However, we can make it so that only active minters are eligible to vote as it can argue that they are the active stakeholders while others are inactive and maybe not interested in Peercoin but for speculative reasons.
There are just my thoughts. We’ll do as we all agree, down the road. Just trying to get discussion going here.

To summarize, these are the options:

  1. 1 coin = 1 vote
  2. 1 solved block (in some time period) = 1 vote
  3. Weighted votes, which takes in address balance and the number of solved blocks in some time period
  4. something else
3 Likes
2

Of course, doing on-chain voting is very much against Peercoin’s design. I would suggest more simply message signing with the requirement that you have minted any output from a given address in the last year, 1 coin = 1 vote. This would greatly alleviate technical difficulties of trying to vote on-chain, by keeping managerial stuff off the ledger yet still entirely auditable via signed messages. Chronology is not a necessary thing here, imo, and so the full ledger is overqualified.

1 Like
3

:neutral_face:

4

:neutral_face:

5

This is about Peercoin the project, not Peercoin the cryptocurrency. I don’t believe it is against Peercoin’s design.

6

I mean technically, the low block spacing and so on, compared to something like peershares. I don’t think 1 mint = 1 vote makes sense in this context.

7

Yes, I would favor 1 coin = 1 vote in this case.

8
  1. something else

It’d be neat if we somehow used https://peerassets.github.io/WhitePaper/#shareholder-voting, providing one built-in user for that project :stuck_out_tongue: Is that something Agave could help make easier?

We could issue equal shares of a new “governance deck” to existing team members and then let them vote and trade as they will from there?

Also, small note: it might be good to drop “him” and “his” and go with gender neutral terms if these become the “official rules” at some point :slight_smile:

Overall this is probably a good idea (elections, roads maps, teams, funding, etc.).

1 Like
9

I knew someone will bring this up but I did not have enough time to re-formulate the text in such a way.

I dislike having the notion of “governance tokens” especially if they are tradable. Also, I do not want to create a snapshot of the chain and distribute any kind of tokens based on that snapshot. Everyone who holds Peercoin should be able to vote, simple as that.

3 Likes
10

Focusing purely on technical side of things, I think it’s a horrible idea to combine time limited voting with probabilistic block minting.

Sudden spikes in pos difficulty, recently spent coins, being offline during the period when your utxo is due to mint makes voting highly unreliable and not a true measure of public opinion.

If you want to allow voting weighted by stake, there are definitely better ways of doing it, PeerAssets voting is not a bad option. Also it is possible to produce signed votes using message signing.

2 Likes
11

I know Peerchemist doesn’t like the idea of taking snapshots of the distribution and using PeerAssets for voting, however I believe this type of governance would be pretty rare. It would be used only when we need to hold an election, maybe also to gain the majority opinion of stakeholders on some big decision.

Is it possible to create a category of PeerAssets that are unmovable? So say a snapshot is taken and they get distributed to people based on current stake amounts. However the stakeholder cannot transact with or move these PeerAssets to another address. The only use for them is for voting this one time on this one issue.

After that, they become useless and can be forgotten about. Then next time a major vote is needed, we just create a new snapshot and do the same. Maybe this snapshot could exclude addresses that have not minted blocks at all, or during a certain period of time, so we only capture active participants.

1 Like
12

Hey, co-dictator of a blockchain (https://blurt.world) here.

Not really of course, all my special capacities and blurt amount to is control of the witness set. My control as “regent” declines in power every month for 24 months so it’s only about another 20 months that I will even be the dictator of a block chain which is a good thing you don’t want to have a dictator on a block chain. There were stakeholders on blurt who did not want it to exist and could have harmed it in early stages so we went with this regent approach. Putting this in code like we did is “muy no bueno” and this proposal above does not do that. That’s good. The regent is not the world’s worst design and seemed perfect on paper.

Instead of coding a regent we should have just nuked the stake of hostile whales since we were starting a new chain anyhow.

I think that you do want to have an executive and that this is the beginnings of an excellent design for executive leadership of a blockchain or DAO.

Interestingly and very rationally, this design even takes into account fundraising and the construction of teams. This design does not assume that the chain is going to fund initiatives desired by the project leader. Instead, this design challenges the project leader to find people who believe that they will realize profits or joy from the PL’s planned set of initiatives.

I think that is a very wise choice.

I think that one coin should be equal to one vote and that staked coins should not carry additional value. Speculators matter too, and the network already compensates people for staking, so there really is no reason to give stakers a disproportionate reward and frankly 1:1 is just much cleaner.

To account for the fact that they’re a good deal of dead or missing coins, you should simply calculate the election based on votes. To account for the fact that they’re a good deal of dead or missing coins, you should simply calculate the election based on votes. Lack of votes means nothing so the threshold that you’re looking for is the winner of the majority of active votes. Don’t look for the majority of total coin.

No there is a remaining challenge. Or maybe I should say, a flaw in the design.

50% Electoral Mandates kill!

Many of today’s democracy is absolutely suck! For example I am from the United States, our government is a joke. But please allow me to clarify: Clinton was a joke, Bush was a joke, Obama was a joke, Donald Trump is a joke, Biden is a joke.

The threshold that you’re looking for is not 50%. 50% isn’t a mandate to do a damn thing. 50% is a joke.

80%, that’s a mandate but I think it’s hard to realize change at that point.

Screen Shot 2020-11-17 at 10.41.04 PM
Screen Shot 2020-11-17 at 10.41.04 PM1892×606 96.6 KB

PS: That bit about “win by a tiny margin and send your friends to die in Iraq”, that actually happened. George W Bush, Operation Iraqi Freedom.

Ya them corpses feeling really free now.

That’s moloch. Folks who is operation Iraqi freedom an example of moloch?

We didn’t even get the damn oil!

Kill Moloch. Every chance you get. It is the highest calling.

So what I am proposing very specifically is that the default state of change is zero, because change is bad. The leader is who the leader is and that’s it.

But suppose that the leader stops acting in a benevolent fashion, and you don’t want to see the chain fork or the community harmed. Well in that case I think that it makes great sense to adopt a 2/3rds threshold.

BDFLs with a usurper policy

  1. A BDFL is responsible for Peercoin. Responsible for what? Everything. There, now clear accountability has been established. If things go well, people know who to thank. If things go poorly, people know it’s time to find a Usurper.
  2. Usurpers self-nominate.
  3. Usurpers are expected to propose:
    a) team composition
    b) Strategic plans that go out for 10 years, with detail front-loaded to the first two years, and milestones.
    c) a budget that supports hiring and execution of the strategic plan for two years.
    d) Proof that he possesses >2/3rds of the capital needed to execute his plans.
  4. Usurpers must plan as though the foundation and community are unable to provide any funding whatsoever. Reality may be different, but this policy will lead to greater resilience.
  5. At any time during the term leader/team can ask for additional funding from 3rd party sources and/or the community and Foundation.
  1. If a BDFL wishes to abdicate, they are expected to identify, train, and assist Usurpers.

Final word

Even in its current form without adjustment to threshold, this is a pretty good strategy for executive leader ship in a Blockchain community context. I am in support of the unchain voting concept and would like to suggest that it be done in a very simple fashion, either with OP_RETURN That themselves reference another OP_RETURN which contains an IPFS CID, which in turn contains documentation of the usurper’s strategy and funding.

Dictators are empowered to make decisions and I believe that this will move the project forward. The introduction of the usurper concept ensures that a lazy or incompetent dictator will easily be tossed aside.

Also it was a deliberate choice to use the word dictator. This is for clarity and to ensure that the burden of responsibility for outcomes / accountability is properly placed on the dictator.

13

It’s been a while since I worked on it, but there are different “issuance modes” that might help achieve a deck with the properties you want “out-of-the-box” https://github.com/PeerAssets/pypeerassets/blob/master/pypeerassets/protocol.py#L19. Perhaps a combination of the ONCE and UNFLUSHABLE modes would do the trick.

I like the idea of using a separate deck for each election and then forgetting about it after the results are in. Using a Peerassets deck also gives us a lot of flexibility in how we decide who gets how many votes and why (maybe some people get votes for holding coins, others for minting or mining, others because they are trusted people, etc.).

1 Like
14

Peerassets and this proposal

Avoid features and software development whenever possible

2 Likes
15

I could also be down for just signing a message from an address and us counting the number of coins there at some time :slight_smile: Perhaps Peerassets is too much overhead.

1 Like
16

The good thing about requiring that the address minted at least once in the last year is that it can give us a sense of quorum. That way we can require ‘at least 10% of minting coins participate in the vote’ or whatever to avoid the argument that the vote wasn’t properly announced.

Snapshots also don’t have to be on-chain through PA or what have you. You can compare the signed messages to a snapshot using an offline copy of the chain and a python program, or whatever.

17

I had a meeting with @backpacker69 about this, and we came to the following conclusions:

  • It is fairest if we give the right to vote to any pubkey (address) which has solved a PoS block in last time period. For simplicity, let’s say this time period = 1 year.

  • To avoid forcing active minters to spend coindays by moving their coins around in any way or forming any unwanted transactions, it is proposed that a central authority which organizes the elections sends the “ballots” out. Foundation can do this. Ballots are near-min value UTXOs.

  • Unresolved question is how to count the votes. Does 1 solved block mean 1 vote? If so, that would give big advantage to small minters, especially if they have found a block more than once in the past year. 1 coin = 1 vote is hard to do right because there are many variables involved. 1 coin = 1 vote but at which moment? At the time of voting? At the moment when the block was found? Average balance of the address during past year? Cummulative balance of each UTXO which has found a block on this address?

  • Voting process is simple, voters spend their ballots (outputs) to address which represents some poll option. For example, Candidate 1 has address: PRSWjUaqdQV3UzPSkuiGRY8YmXc4grMwpM and Candidate 2 has address: PRf8GqAUNPKqLZyfqzpPJGatghngxwsR46. Goal is to make vote counting as transparent as possible and easy as possible, even if someone wants to do it manually or in Microsoft Office Excel.

  • About voting UX itself, it should be a webapp which can connect to a local node (or remote) via RPC. So the user is not forced to manually export WIF keys from the wallet and copy/pasting them to the app. App should be handling that automatically and should be able to understand which UTXOs are a ballot.

1 Like
18

Excellent. I suggest 1 coin = 1 vote with snapshot taken when ballots are sent out. This will avoid pump and dumping during voting processes and seems the most intuitive to me. It also avoids making it all about minters, though it does nothing for people that keep their wallets on-exchange. Speaking of which, the foundation should be able to blackball users, e.g. known exchange addresses, to avoid undue influence.

19

How committed is this investor? Usually, investors are fickle, which means we should find the path of least resistance here. This means definitely not trying to implement any “cool” software solution.

I think @peerchemist system is good enough, but we should add a clause on how/when to remove a leader.

And also how to make changes to the constitution.

20

What if minter has fully cashed out of the system since his solved block and before the moment when the ballots are sent out?

The goal should indeed be to remove the option of influencing the vote by buying a lot of coins just before the vote starts or something.

Exchanges do not mint, so by definition no exchange should be able to influence the elections.