NOTE
see below in “Edits” section for updated system
Abstract
One of the core criticisms for DAO’s in regards to voting is that not everyone’s vote is counted equally. Technically this has not been possible to accommodate due to the exploitation of sybil attacks. The end result has been more or less to alleviate the advantage of sybil attacks by implementing token weighted voting. Whilst weighted voting has been ‘good enough’ as a greater problem is resolved in place of a lesser problem, I propose a hybrid approach that I believe can achieve not only greater consensus, but also maintaining the merits of “skin in the game/shareholder theory” with weighted voting. This system I designed for another project I previously worked for as governance coordinator, where my core focus was on improving consensus and integrity with regards to DAO voting.
Related Info:
Article - Moving Beyond Coin Voting - Vitalik Buterin
Book - More Equal Animals - Daniel Larimer
My previous work - 2-Factor Majority (MahaDAO)
Considerations
Initially I deisgned this concept for another project (MahaDAO), which utilized PFP NFT’s that are minted via locking a minimum amount of tokens over time. These programmable NFT’s are then utilized for both Voting and Staking purposes. Some considerations need to be made here for the purposes of JUP DAO, as it is categorized as ‘Limited Governance’ whereby LFG candidates are up for voting, yet core operations, fiscal/moentary policy, and strategic partnerships remain centralized. In addition, the use of Delegation can be plugged into this without impacting the overall integrity of result.
Given that the LFG votes are multiple choice, and not binary ‘yes/no’ - the thresholds for a majority pass by ‘headcount’ should be adjusted to reflect voter dilution to each candidate. That is, out of 4 (four) possible selections, a majority threshold here would be >26% as opposed to >51%
Proposal Concept
In short, 2-factor majority refers herein to a candidate recieving both the majority of token weighted vote, and the majority of quantitative voters. This is to diminish the pitfalls of ‘pay-to-play’ potentially undermining the community consensus, yet preserving the aligned incentives in regards to ‘skin-in-the-game’ or ‘shareholder theory’. Here we can strike a balance between those who have more to gain/lose with vote outcomes, as well as promoting greater relevance and consensus to all voters irrespective of their purchasing power.
The following is an example for adapting "2FM’ to multiple selection voting rounds, with adjusted thresholds for both a ‘majority pass’ and ‘sybil protection’.
100 / a = % pass threshold
(where “a” is the total number of LFG candidates participating in the voting round)
e.g.
Total JUP voted: 100,000,000
Total Voters: 250,000
Threshold: >25% (62,500 Votes & 25,000,000 JUP)
Project 1 – 29,000,000 JUP (pass) w/ 15,000 Votes (fail)
Project 2 – 26,000,000 JUP (pass) w/ 70,000 Votes (pass)
Project 3 – 14,000,000 JUP (fail) w/ 100,000 Votes (pass)
Project 4 – 31,000,000 JUP (pass) w/ 65,000 Votes (pass)
In the above example, Projects 2 & 4 would clear the Two Factor Majority thresholds, whereas Projects 1 & 3 would fail the Two Factor Majority.
We can see here the balance at play between consensus and ‘whales’ where even though Project 1 received more JUP allocated than Project 2, it lacked overall community consensus. Comparatively, we can also see where Project 3 gained the most votes (consensus), but lacked the support of larger holders to meet the JUP threshold.
In this way we accommodate both the greater consensus of the broader community; irrespective of their JUP holdings – yet this does not hinder the power of large stakeholders that have greater investment and risk/reward incentives.
Sybil Control
With a standalone weighted model (1 JUP = 1 Vote), there is no advantage to dispersing over multiple accounts/wallets in order to game the system. The cost of this approach however, is a diminished representation of true consensus. This has long been a difficult problem in the space, and likely will not be completely resolved without robust “DID” implementation perhaps with zkproofs or other means like iris scanning with Worldcoin.
In the interim of better and more secure Sybil controls, we can consider a minimum JUP amount required to count as 1 vote. This can be calculated by the lowest denominator of the top 90% to 95% percentile of holders. In this way, we invalidate micro balances from being counted as a vote, while maintaining the weighted allocation of these micro-accounts within the overall JUP vote totals.
Conclusion
One of the greatest challenges for DAO’s is to provide a sense of meaning to each participants vote in the landscape of economic inequality. Furthermore, to represent an accurate community consensus that can often be overshadowed by large stake holders. We must maintain good alignments with incentives for both larger stake holders, but also the little guy. I think JUP has done an amazing job so far at achieving widespread participation, however I would attribute this more to the reward incentive rather than a greater interest in the candidates themselves.
What we don’t want – is a widespread sentiment where people care less about who wins because they feel their vote won’t have any significant bearing on the outcome, and that they will get rewards regardless of who wins anyway. Instead, we want to make people feel like their vote really does matter, even if they don’t have much JUP – this in-turn boosts engagement and enthusiasm towards participation and really getting to know the candidates involved.
Thank you for your time, if you have any questions or feedback, feel free to share.
Edits
- Reworked System with Multiple Choice and Fractional Tally
UPDATED SYSTEM
System Overview
- Set Minimum % Threshold of Total Participating Wallets as a ‘Pass’ check for voting results.
E.g.
Pass Threshold: 30%
Participants: 1,000,000
Project A: Received 90m JUP and 356,230 Votes (35.6% - Pass)
Project B: Received 90M JUP and 23,554 Votes (2.3% - Fail)
Qualification/Criteria for “1 Vote”
- Staked JUP amount within the top 95% of all wallets. This makes sybil attacks exponentially costly to attempt, whilst also heavily restricting the potential impact.
E.g.
Lowest 95th Percentile Wallet: 35 JUP
Wallet 1: Votes with 30 JUP for Project A (Only JUP amount is counted)
Wallet 2: Votes with 40 JUP for Project A (Qualifies as ‘1 vote’ & JUP amount)
Result: Project A will have 70 JUP, with a tally of 1 Voter.
Multiple Choice
- Allow partial use of voting power to be allocated to multiple selections. Doing this will also split your participation vote.
E.g.
Wallet 1 has 300 JUP and votes for:
P1: 0.35 which is (105 JUP)
P2: 0.50 which is (150 JUP)
P3: 0.10 which is (30 JUP)
P4: 0.05 which is (15 JUP)
Wallet 2 has 3000 JUP and votes for:
P1: 0.4 which is (1200 JUP)
P2: 0.1 which is (300 JUP)
P3: 0.5 which is (1500 JUP)
P4: 0
Wallet 3 has 5 JUP and votes for:
P1: 5 JUP
P2: 0
P3: 0
P4: 0
(example of consensus stuffing, since the JUP balance falls within the lowest 5% of holders, only the JUP amount is counted with no voter count.
Combined Result
P1: 1310 JUP w/ 0.95 Votes
P2: 450 JUP w/ 0.6 Votes
P3: 1530 JUP w/ 0.6 Votes
P4: 15 JUP w/ 0.05 Votes
I will say however that “Simple” or “Complex” are subjective terms, and that whatever is deemed simple, is not always ‘better’. Take the design of your computer for example – the first one was rather big and complex. Many did not see the value because they lacked the experience to see or comprehend it.