Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quadratic Conviction Voting #37

Open
sembrestels opened this issue Jan 30, 2020 · 2 comments
Open

Quadratic Conviction Voting #37

sembrestels opened this issue Jan 30, 2020 · 2 comments
Milestone

Comments

@sembrestels
Copy link
Member

Quadratic voting is cutting edge nowadays. It has no previous relation with conviction voting but they can be combined very easily.

In some way, quadratic voting distributes voting power over people and conviction voting over time, or as @mzargham puts it, conviction voting address smoothing the way information is collected in time where as quadratic voting is reorganizing "in space" where the dimension of space is people.

Combined we get an algorithm which addresses distribution in both space and time. We have to take into account that we need a strong id in order to use quadratic voting (one account per user).

Applied to our current system, we only have to square root the staked tokens and multiply it by a scaling factor before we pass them as oldAmount param in the calculateConviction(uint64 timePassed, uint256 lastConv, uint256 oldAmount) function. A very simple and optional change that can have a lot of implications for communities that decide to go this way, giving more conviction power to small token holders.

It has a lot of sense to combine this with splitting the vote into various proposals (see #36).

@0xBRM
Copy link

0xBRM commented Sep 23, 2020

Quadratic voting of any kind can only be justified in a Sybil resistant environment (eg all participants were KYCd). Otherwise it will have the opposite effect.

@sembrestels
Copy link
Member Author

Yes, quadratic voting can only be applied to a group of authenticated people. We can use different methods to authenticate addresses in different DAOs:

  • In a small cooperative DAO we could use a membership token and a funds token, and use the membership one to match to users.
  • We can also use non-transferable tokens such as CommonsStack's CSTK token holders (who have been authenticated by the core team) to match to users.
  • We can also have DAOs in which people can only vote if they are authenticated in BrightId, and match their addresses as users.
  • Finally, we can have mixed setups, in which the voting power comes a certain percentage from registered token holders and the rest from registered+unregistered ones, so being registered would increase user's voting power but it would not be a requirement to vote. I think @lkngtn was suggesting something like that the other day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants