Feature/quadratic #73
Conversation
|
@dankelleher Thanks a lot for the PR. I am also interested in this, do you know if there is any plan in merging this PR? Anyone already using this plugin? |
Not that I know of - merging is down to @SebastianBor . It has been a while since I delved into this tbh but IIRC it needed just a little refactoring and maybe testing and then it's good to go. I'm happy to help and advise where needed! Just to point out, this is a very simple form of QV where there are no "multiple-choice" voting options yet. Supporting multiple choice proposals should probably be a separate PR. |
It's a great example of stacked plugin implementation (and I want to keep it for that reason) but I think the solution is too complex for quadratic voting. A better solution would be to implement it directly in However the most important thing would be to use the |
Note, due to compatibility issues between solana program test 1.17.* and anchor 0.29.0, solana-program-test is currently on a fork.
Note, due to compatibility issues between solana program test 1.17.* and anchor 0.29.0, solana-program-test is currently on a fork.
dankelleher
force-pushed
the
feature/quadratic
branch
from
9a886a2 to
e59572a
Compare
dankelleher
force-pushed
the
feature/quadratic
branch
from
98961a9 to
e19e7b4
Compare
dankelleher
force-pushed
the
feature/quadratic
branch
from
e19e7b4 to
ff5906c
Compare
dankelleher
force-pushed
the
feature/quadratic
branch
from
8840da3 to
99f33c2
Compare
dankelleher
force-pushed
the
feature/quadratic
branch
from
f2ac8c3 to
5931a19
Compare
dankelleher
force-pushed
the
feature/quadratic
branch
2 times, most recently
from
a367030 to
b301bcc
Compare
dankelleher
force-pushed
the
feature/quadratic
branch
4 times, most recently
from
f801dc6 to
0bdd490
Compare
… Labs about how to track maxVoterWeight. A summary of the discussion: This is an issue that also applies to VSR DAOs, but that it is essentially a UX issue, and relates to the decision of "how to set a quorum correctly"? Essentially - in "normal" DAOs, you set the quorum as a percentage of the total vote power, where vote power = token supply. With QV DAOs, the total vote power is a function of total supply and distribution. If the distribution is wide and egalitarian (uniform distribution of tokens), the total power is higher than if the distribution is narrow and centralised in a few whales (long-tail distribution). So this leads to two facts: - calculating max weight is complicated and changes over time - we could do it, but it would require changes in the core program as mentioned. - setting the quorum as a percentage of the max weight is not that useful, since, depending on the distribution, that percentage may be reachable by one or two whales (note, this is even worse in token-voting DAOs. As a result, we decided it is currently not necessary to calculate an accurate max weight, and quorum will be determined based on the token supply, with potentially some UI help to explain how that is affected by QV.
dankelleher
force-pushed
the
feature/quadratic
branch
from
0bdd490 to
f966051
Compare
…d implement it as needed). This ensures client code doesn't assume plugins have max voter weight records just because getMaxVoterWeightRecordPDA returns something.
…at returns the previous voter weight record in a chain of plugins. This is due to the fact that some plugins (such as VSR) derive the VWR in a slightly different way.
dankelleher
force-pushed
the
feature/quadratic
branch
from
d0f09ce to
7a183c8
Compare
A simple quadratic voting plugin, that takes a predecessor vote (and max vote) and applies a quadratic function to them. This has the effect of amplifying smaller votes and dampening larger ones.
Notes:
client.updateVoterWeightRecord(realm, mint, voter), and the client handles wiring up the predecessor accounts.