I am trying to create a governance contract with a token. Every token holder can vote on particular issues, and I want to use Quadratic Voting (meaning 1 vote costs 1 token, 2 votes cost 4 tokers, 3 votes cost 9 tokens… etc).
Say a participant wants to cheat the voting mechanism. If that individual were to have 100 tokens, he/she would have to pay 100^2 tokens to vote on a measure. What if that individual creates 100 random wallets and sends 1 token to each wallet, the smart contract can be fooled into thinking that it is just 100 different accounts voting for the same measure. His cost for 100 votes would be 100 tokens because the smart contract does not have any knowledge about these 100 random accounts created by the same user.
hi, in Vote Coin quadratic voting it works the way that you as a person has constant voting power. it may be represented either by your token balance, or 1 if you are on the trusted list
when person votes, he can distribute his voting power to different choices.
eg if you have options A,B,C , and person votes for only A, his full voting power is distributed to the A choice…
if he decides to spend
10 points on A,
20 points on B,
he has 10/30 (33%) voting power to A, and 67% to B with linear voting results.
with quadratic voting results, his voting power is distributed as
10^2/(10^2+20^2) = 20% for choice A, and 20^(10^2+20^2) to choice B
with quadratic voting with 3 options, lets say 10, 20, 30
10^2/(10^2+20^2+30^2) = 7% A
20^2/(10^2+20^2+30^2) = 28% B
30^2/(10^2+20^2+30^2) = 64% C
You dont have to create new voting system… i think there is enough already… i would be happy to cooperate on vote coin if you find it interesting Contact me on discord please…
I get the implementation quadratic voting from the Vote Coin perspective. However, I don’t think it is clear to me how this solves the issue:
In your example on quadratic voting, the person could create 30 different wallets and have his/her voting power distributed linearly. Essentially, he/she could bypass the “quadratic voting part” and have his votes on Option A, B, and C distributed linearly because he has 30 different accounts, each holding one “point”, or token. Smart contracts on Algorand cannot distinguish between real human beings (unless you go through some KYC process). So the idea is a human being can cheat the smart contract by creating a bunch of dummy accounts and voting from each one individually, effectively making the person’s voting power linear.
@fabrice could this be solved in some other way? We would be getting away from the essence of Quadratic Voting, but I could see a scenario where there are multiple tokens (say 3 different tokens), and each has a given purchasing power.
For instance, there could be 3 tokens: Token A, B, and C.
The smart contract recognizes that token A can only buy 1 vote, token B can buy 2 votes and token C can buy 3 votes. This way, an attacker does not benefit from creating a bunch of dummy wallets to bypass the hierarchy of voting power.
Do you see something like this being a realistic implementation?
either the token can be freely traded/transferred. In that case, you cannot prevent a user with 5 tokens to send 1 token to friend Alice, 1 token to friend Bob, … so I don’t think you can introduce these tokens A,B,C …
or the token cannot be freely traded/transferred. In that case, just freeze completely the token and users cannot split their tokens at all: only the administrator of the token (or some smart contract) can allow transfer of the tokens. So if Alice receives 10 tokens, she won’t be able to split them in 10 accounts. But she also won’t be able to transfer any tokens to friends or to sell the tokens (without approval by the administrator).
So my issue is not really with individuals transferring tokens. My issue is with people cheating Quadratic Voting by creating dummy wallets in order to vote linearly.
The reason people can cheat Quadratic Voting is that there is only 1 Token that the smart contract recognizes.
In this scenario:
The smart contract recognizes only 3 different tokens: A, B, C.
Each Token A can buy 1 vote.
Each Token B can buy 2 votes.
Each Token C can buy 4 votes.
These tokens can be freely traded/transferred.
Even if Bob sends 5 Token A to Alice, Alice will only be able to buy 5 votes.
If Bob sends 5 Token B to Alice, Alice will only be able to buy 10 votes.
If Bob sends 5 Token C to Alice, Alice will only be able to buy 20 votes.
My point is if Bob wants to cheat the hierarchy by sending tokens to different wallets, he will not be able to cheat because the smart contract recognizes these tokens as having a specific amount of value measured in votes (perhaps the value of each token can be stored in the global state).
Maybe my intuition is wrong. I am just throwing out ideas.
Let me know if you find any flaws in my logic (because there probably are).
I suppose token C = 16 token A, and token B = 4 token B.
Let’s suppose that Bob has 1 token C and wants actually to split it to his 4 friends Alice, Charlies, Eve, and Franck.
Do you want to allow Bob to do that?
If yes, Bob needs to have a way to split the token C into 4 tokens B or 16 tokens A.
Then, it’s game over with quadratic voting.
Now, if you don’t want Bob to do that, it means you don’t really allow people to sell/transfer tokens as they wish.
Another issue: what does ensure that Bob has 1 token C in the first place instead of 16 tokens A? Suppose Bob bought 16 tokens A, he really has no interest in converting it into a token C, as it will diminish his voting power.
I understand. I did some research to find out how some of the modern DAOs on Ethereum are doing it. Basically, you can earn the right to vote by staking a certain amount of tokens in a contract for a certain amount of time, earning “proof of staking credits”. It is a system to verify accounts in decentralized networks:
Also an article on the flaws of quadratic voting and how they can be improved:
You can simply split your balance to 3 different accounts if you really want to cheat the quadratic voting and vote with 100% of its voting power to its answer…
The real question is, what is your intention?
Are you trying to create DAO that must have results of voting calculated only in the quadratic form? You also discovered by your self that quadratic voting has some flaws… And yes, you can solve it for example if you forbid transfers of the tokens… But do you really want to do it?
you can incentivize token holders in such a way that they will consider whether it is better to split their tokens into multiple accounts or keep them all in one account. I’m not sure what formula will enforce balance in the best way but for example, an account that holds x amount of tokens will be rewarded by (x/2)^2 so an account that holds 10 tokens will be rewarded (10/2)^2 = 25 tokens for an interval but if the user decides to split his tokens to 5 accounts he will only be rewarded for (2/2)^2 * 5 = 5
Yeah, the only problem is that in quadratic voting, you want to do the exact opposite. You want to even out the playing field by making it expensive for whales to sway the vote. So votes cost n^2, where n is the number of votes you want to purchase. So 1 vote costs 1 token, 2 votes cost 4 tokens, 3 votes cost 9 tokens, and so on. In you example, someone who holds more tokens can buy more “marginal votes” (the cost of the next vote is cheaper) because of the (n/2)^2 reward.
yeah, I understand your point that’s why I suggested (n/2)^2 instead of n^2. the formula is too greedy so it’s not a good example but the concept is to balance between your power in the current vote and reward for future votes. I will try to come up with a better formula my intention is not to prevent users from splitting their account but to add complexity so you ask yourself how important the current vote is to me.
Yes DID is a good solution Hyperledger Aris has an blockchain agnostic framework for this. Yet another solution on Algorand can be, as follows:
The ASA (Voting Power Token) is default frozen.
For unfreezing an account, a Dapp will verify the mobile via OTP, then the mobile is hash & hash is signed and sent back as a smart signature along with the unfreeze transaction and optin txn as a single atomic transaction group. The user then signs the opt-in txn and submits the transaction to the Algorand mainnet.
This avoids creation of proxy voting to game the system.
(n/2)^2 is the same thing as n^2 … the richer guy gets more decision power
(100/2)^2=2500
10*(10/2)^2=250
(100/2)^2 vs (10/2)^2 = 2500 vs 25 … the 10 times richer guy gets 100 times more votes
if you want to prioritize poorer votes, there is really no way to do it because of simple principle that rich guy can split his account to 10 smaller accounts, and he gets 10 times more votes… it does not matter if you calculate with quadratic,exponential, or regular, but there is always math problem there…
thats why the only solution is to do simple 1 coin = 1 vote and in some cases combine it with 1 verified person = 1 vote
Vote Coin has solved this by making the voting power equal for each account… if the results are calculated 1 coin = 1 vote or in 1 person = 1 vote, not matter if dao evaluate its results in quadratic form or regular form
The Algorand Smart Contract of course cannot verify any OTP. I missed to state that a dApp will verify the OTP (say using firebase authentication) and get a JWT, the JWT is the exchanged for a JWS and verified by the dApp. The dApp then hashes the user identifier (mobile number in this case) and signs the hash. The smart contract just verifies that the hash is signed by the trusted dApp private key.