An Experimental Approach

We must note that it is not enough to install top-down a new set of rules over a group of people. Rather, there must be an emergent culture and social context that works around these new rules. QV and QF may seem complicated and fancy, but we hope participants will find that interacting with these systems is actually quite intuitive. As we have learned from other early experiments, it takes a few funding rounds for people to develop a shared understanding of all the dynamics (e.g., which proposals are appropriate, how much to contribute, how to promote projects and respond to those promotions). 

For this reason, we are taking a narrow but earnest experimental approach — scaling up and course-correcting as we learn about it. We hope to be at the forefront of discovering the new institutional policies and social norms and practices that will make these rules legible and intuitive.  At that point, we expect the mechanisms to produce promising outcomes, ones we could not have predicted ourselves.

Technical Implementation

Note: these tips are not requirements but only initial design suggestions!  Some details may not be relevant at this time.

Quadratic Voting

In general, the tool should have the following steps/characteristics:

• Admin creates a Group of identity-verified users (Members)
• Members have the ability to submit textual Proposals (ideally it would be possible to include links, videos, graphics. as part of the Proposals).
  • Depending on the nature of the body, the Admin(s) may need to be able to veto, approve, or edit the Proposals
  • In some Groups, only Admins should be able to post proposals
• Approved proposals (under admin control) are batched to Members as “Ballots”.
• In general, each Member should start with 100 Voting Credits to allocate on the proposals with a Ballot.
• Admins have control over several additional parameters.  
  • Whether unused Voting Credits may carry over from one Ballot to subsequent Ballots, or at what rate unused Voting Credits are forfeited.  
  • Whether Ballots are sent at fixed intervals or irregularly.
  • Voting deadlines.
  • Whether the Ballot allows both “for” and “against” votes (better in controversial proposals) or only “for” votes (better in a prioritization exercise).
• At the voting stage, voting Group Members need a dynamic visual illustration of: 
  • their dynamic budget of Voting Credits (i.e., the budget changes as they allocate Credits but before they click “submit,” so that they can experiment with different allocations);
  • how they have allocated Credits between proposals;
  • how those allocations translate into counted votes (i.e., 9–>3, 16–>4).
• For some Groups, it will be fine to have a master Admin manage the ballot.  But for others, it will be important to have democratic input into the ballot construction itself.  One way of doing this is to let the Admin set only general rules, such as ballot sizes, ballot frequencies, and voting deadlines.  Then, each ballot construction could itself be done using “pre-ballot / primary” ballots, as follows:
  • Ballots are voted on [quarterly] and each Ballot has [ten] Proposals.
  • Anyone can always submit a new proposal.
  • A certain time before a Ballot is scheduled to go out, all Members take a quadratic vote on all live proposals, voting for or against proposals they wish to see on the next Ballot.
  • The top [ten] Proposals are included (Admin) on the next Ballot and voted upon.
• The quadratic vote tallies should be blind until the vote is closed. 

Quadratic Funding

Visually and in its mechanics, the tool should resemble the QV tool quite strongly.  Likely, much of the same code could be used.  However, it would have several important differences:

• It must be able to accept payments (real money or, likely in this case, artificial tokens).
• Rather than operating only within a fixed, predetermined group of voters, the QF rounds should be open to any eligible, identity-verified person.
• The admin will set: 
  • the amount of the matching fund;
  • the minimum amount of money each Proposal requires to be viable (when a Proposal does not receive the minimum viable amount, whatever contributions it received should simply be returned)
  • Whether to toggle an anti-collusion rule modifying the QF algorithm, such as pairwise coordination subsidies 
• In most circumstances, it will be essential for an admin to “vet” the Proposals and curate the Ballot because the Proposals will correspond to either real budgetary categories or specific real-world projects, all of which must be feasible/acceptable allocations of the matching fund sums of money.
• By default, the matching funds should be allocated pro-rata between all projects that meet their funding viability threshold.  It is not crucial for version 1.0 but eventually, admins should be able to modify that pro-rata rule in various ways and announce the modifications to the algorithm.
• The funding tallies should not be blind until the process is closed–it should be possible to see in real-time how much money has been allocated to each proposal, and what the current implicit match is.  Moreover, it should be possible for would-be donors to see, visually, what marginal match their contribution would receive while they are contemplating making it.  The following graphic suggests a good way of dynamically illustrating QF contributions (see more of the methods used by Gitcoin).

Data Collection

Nearly everything about the QV and QF processes should be tracked in order to later analyze/demonstrate the effectiveness of the tools.  It would be interesting to also query participants about their perceptions of the legitimacy of the processes and outcomes.  And when large numbers of voting processes can be studied, it would be interesting to correlate, for example, proposal support with a priori estimates of the “extremeness” or “polarizingness” of a proposal to test hypotheses about the tools’ effect on polarization.