Voting mechanism

I currently see three ways of casting a vote on MIPs:

  1. directly on-chain where every block producer casts their vote, as a representative of every person who decided to delegate to that block producer
  2. developing an official voting snapp (which vould eventually even serve as a real world proof of concept) where every person who owns at least x MINA can cast their vote on proposals
  3. using a 3rd party off-chain tool like Snapshot.org or similar

Allowing users to vote directly via an official Snapp (2.) would allow for more direct and more decentralized governance and voting opposed to letting only block producers cast a vote, while representing their staking pool with their vote.

What does everyone think about the three different approaches I mentioned?

Additionally, if the decision will be made to cast votes on MIPs with the help of a Snapp, would that be an application that MF/O1labs could possibily even develope in direct cooperation with the community (potentially selecting different devs from the community that will be given the task to develop such snapp in cooperation with MF/O1)? Giving the community the possibility to develop the voting mechanism to vote for MIPs would be a very cool first “official” Snapp.

2 Likes

Hi Trivio,
I don’t know from a technical perspective, but Number 2 is definitely something I would support. I think that it makes so much sense to develop a Snapp in order to vote.

It will work on a number of levels… firstly it will help the community to engage and feel connected with the project, plus it will show off the capabilities of snapps in a real world use in a way that will inspire further advancements and ideas.

If the question is representative vs. direct democracy, I think representative is preferred for two reasons: 1) MF / O(1) have stated they will delegate their votes without which they control the outcome of every vote, and 2) delegates are more likely to be involved in the protocol and have a more in-depth understanding of protocol functionality.

While option 2 could include a delegation feature - it would need to re-develop safeguards to monitor and prevent single or a few large delegates being in control. This is already being done for staking delegation, so re-using delegated stake as the voting weight as in option 1 is a simpler solution with fewer moving parts.

Similarly, a snapshot is needed regardless of the method, but if the vote is based on delegated stake, then an epoch provides a natural start and end point and the relevant staking ledger is a natural snapshot.

As for the implementation, a voting Snapp would seem to be a reasonable approach regardless of the decision on who should vote, or what is used for the snapshot to validate voter eligibility and weight.

The weighting algorithms could be more intricate, such as using a quadratic voting mechanism to more evenly distribute weight if certain wallets are too powerful i.e. to smooth out exchange weight. (This could also be a counter-argument to my objection re: option 2 and safeguards.)

3 Likes

My only issue is with option 2 is if we set certain number low people can abuse it with multi wallets if we set high than that’s not inclusive so whatever you do that kind of system actually work. Either you make 1 mina=1 vote weight which is not good either but at least fair and not exploitable or you create a whole system for this voting mechanism which is very early to do atm.

1 Like

I agree, @EmrePiconbello, things could get abused easily if every account would be allowed to vote and 1 Mina = 1 vote would greatly benefit accounts with big balances and could basically decide the outcome of a proposal without any issues. To elaborate on @jrwashburn’s thought on introducing some sort of quadrating voting function, a minimum balance of n Mina could also be required in order to cast a vote.

The blue graph is representative for ‘1 Mina = 1 vote’

The green graph is representative for ‘1 Account = 1 vote’

and the red graph could be representative of a quadrativ voting function, including some possible thresholds t_min, the minimum balance required before an user can cast their vote, or potentially even soft or hard capping voting power of accounts with a balance >= t_max at some point

Obviously such a system would require a lot of thought in order to allow everyone to vote at least “equally fair”, while still allowing everyone to effectively cast their vote and have a say. Those are just some thoughts that came to my mind and I wanted to discuss possible outcomes and benefits

3 Likes

There are some projects working on doing 1 people 1 vote mechanism with various tech. I think we can achieve some kind of system close to that or get data from these projects.

1 Like

Lots of things to think about, really great to get a technical perspective. So the basic consensus is that need a system that is both democratic, but not open to potential abuse?

Setting both a min AND max balance like in the quadtratic voting sounds like a great idea. If there was a big enough pool of participants eligible to vote, do you think would this nullify the potential abuse/motivation say if a large holder(s) split down their balances into smaller wallets just below the threshold?

Such a mechanism would certainly need a lot of thought and game-theory’ing (if thats even a word), but such a function could certainly provide great benefits especially for normal users if the parameters and circumstances are carefully set

1 Like

Personally I think it’s important not to underestimate how new implementations and progress is viewed by the Mina community. Having an intelligent voting system would take the project to a new level.

It would also attract new external interest in the project.

1 Like