You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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.
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 thecalculateConviction(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).
The text was updated successfully, but these errors were encountered: