Design a governance token

Hi :slight_smile:
I am a designer and frontend dev and it’s a while that I read about blockchain and smart contract development.
I messed around with some tutorials about solidity, hardhat and ethersjs/web3js libs together with some openzeppelin blog posts (thanks a lot for curating this forum as well… )

As next step, I’d like to build a more challeging (at least for myself) proof of concept…
I’d like to develop a governance token that mimics coop shares.

This simply means users with tokens (aka shares) can partecipate in the community governance, but their vote will have the same weight no matter of the amount of tokens they own (1 user = 1 vote) - in opposite of the most common governance tokens out there.

The rest of the flow can stay the same, users with shares can create new proposals or vote active ones (I would not bother with adding delegates for a POC).

My intention is then to hook the smart contract with a simple dashboard and interact with metamask.

Some relevant links I found so far includes:

I didnt found tutorials nor guides about how to implement governance tokens so far, any guidance is very much appreciated.

Thanks you all :slight_smile:

A naive implementation of this idea will be vulnerable to sybil attacks: how will you know that it’s not the same person behind 10 different users?

You need a sybil-resistent identity system, which is a hard problem. Proof of Humanity comes to mind.

Thanks!!
I spent some days studying the governor bravo governance architecture and planning to spend more time experimenting with that, I’m pretty trilled about the possibilities on-chain governance offers already at this early stage…
Anyway related to the 1 user = 1 vote issue, I was wondering if this flow overcomes it (based on the governor governance contracts)…

  • When a new proposal is made, it creates a snapshot of the current token holders (as it is already). In this way, only existing holders can express their vote on that proposals.
  • Based on the snapshot, each holder receives 1 ERC-721 token representing their voting power (independently from their token amount).
  • Such token is strictly linked with the proposal just created and it can be transferred/spent only to that specific proposal address (or delegated ?)
  • Users with the ERC-721 token can vote on the proposal (or delegate another user ?)
  • When the proposal is closed the ERC-721 remains to the user who voted - as a collectible badge - to highlight their participation to the project governance (it cannot be used to vote on new proposal).
  • Users will have as many ERC-721 tokens as the amount of proposals they voted.

ps. thanks for taking the time to reply also to noob questions / discussions, it helps a ton newcomers like me to take the time and energy to get into these things :slight_smile:

1 Like

It doesn’t overcome the problem generally, because an attacker can distribute its tokens across many wallets in anticipation of a proposal that they want to bump in support with multiple votes.

I don’t think 1 user = 1 vote is a good idea unless you use a strong sybil-resistent identity mechanism, or unless your system is permissioned and you will trust all participants to behave honestly.

What’s the reason you want to avoid token-weighted voting power? If you want to avoid whales there may be other means to mitigate it like using an airdrop to ensure good distribution of tokens.

I do not think an initial good distribution of tokens can avoid centralisation, as with a little amount of time and economic incentives, tokens tend to become centralised in few hands anyway :expressionless:
But yeah I reckon 1user = 1 vote is way more harder to accomplish than I think (or at least it’s harder if you dont want to loose most of the blockchain inherited advantages)
I see that it’s easier to lower the barrier to publish a proposal (with eg. autonomous proposal ) - I’ll prob focus a little bit more on that side for the next period :))

1 Like