Community Delegates for DAO Governance

ShuffleDAO will follow a delegate system similar to ENS for DAO governance.

This means:

  1. Anyone is still able to discuss and create proposals that can end up for a vote.
  2. Only elected delegates can vote on the proposals.
  3. Each delegate has one vote, it is not influenced by the amount of MINT or NFTs they are delegated.

As a service DAO, this benefits everyone as delegates can be better informed of the DAOs workload and aligned with its goals compared to the general public.

Initially delegates will be comprised of core DAO contributors and members of the community. During the bootstrap phase we will have more contributor delegates.

We propose growing the number of community delegates based on treasury size to slowly increase their numbers till they meet or exceed that of the contributors.

I would like to open discussion about:

What is a reasonable number of initial community delegates?

Any requirements for becoming a delegate? Holding Hoot, MINT etc.

How often should the number increase?

Any concerns or questions on this system of governance?

Thank you,


I’m on board with it. As long as it can be undone if it goes horrifically wrong, which it can be.
Also, I’m not super attached to this, but, I wouldn’t mind if we required the first few delegates to be Hoot holders and possibly always require some number of delegates as Hoot holders. It most likely would be anyway, really.

1 Like

As far as I understand ENS’s governance is set up so anyone can become delegates, people just assign their ENS so that delegates have more or less voting power in their 1 vote: Tally | ENS

The problem with this governance system is that it has the potential for a cult of personality project owner or an individual group to have excess power. Imagine a project x which has 10 times the voting power of y and z due to the larger community. They would certainly overshadow smaller projects, possibly even ShuffleDAO itself.

I propose open quadratic voting based on ShuffleDAO project NFTs, specifically adding time held to prevent the common sybil attack vector for QV. We’d use Hoots as the base ratio 1 point per NFT for the 2500 set. If a project has 5000 in its collection, 0.5 points per NFT. All of this related to a function of held time, with a logarithmic increase curve topping at 1 over years.

I’m not a math whiz but I’m imagining something like this: Vote power = (total points * NFT hold-time function). This needs to be simulated across multiple examples, but it takes care of a bunch of concerns I think.

1 Like