Proposal: Try out Condorcet Voting for GG24 Domains

(Thanks to @thedevanshmehta @clesaege @sejalrekhan for helping me think about this!)

TL;DR – in this post, I propose Condorcet voting as an option for deciding how to allocate money to GG24 domains. We can run Condorcet voting and the typical weighted vote in parallel and on the same data, and then decide which outcome we prefer.

As public goods funding matures, Gitcoin is exploring diverse funding mechanisms and round themes. But as the number of mechanisms and domains grows, a new challenge arises:

How do we decide how much funding should be allocated to each mechanism/ round?

The current status quo is a naked GTC vote: everyone inputs their preferred way of distributing the money, and we just take the average (or “mean”), weighted by how much GTC each person has.

This type of “mean” weighted voting has two drawbacks. First, it encourages strategic behavior, since there’s an incentive to overstate or understate your preferences in order to make the average go up or down. Second, it results in peanut-butter spread distributions where many proposals get just a small amount of money. In the context of GG24 domain funding, this is an especially bad issue, since we’re voting on the funding to entire rounds: it’s really not desirable for an entire round to just get a tiny sliver of the funding pot. If we instead use mean voting to simply decide on the top X domains to fund, we’re still left with the question of how to allocate between those top X domains, and in particular, we’re left without a clear way to make sure the allocation we choose corresponds to everyone’s preferences.

Instead, we propose Condorcet Voting as an alternate way of calculating a funding distribution. Condorcet Voting avoids peanut-butter spreads and it’s “strategy proof”, meaning there’s no incentive to misreport your preferences. It can also be configured to give users with more GTC more voice in the process, maintaining GTC utility.

How does Condorcet voting work?

Similar to the weighted vote strategy on snapshot, users simply input their desired funding distribution (i.e. 10% to domain X, 50% to domain Y, etc) and have their importance weighted by their token holdings (e.g. GTC). The results from condorcet are calculated quickly in Python and compared with the results from a simple weighted vote. Since the input to the mechanism looks just like it does in the weighted vote scenario, we can run the vote on Snapshot and compare the two results afterwards, similar to how we compared results from regular QF with cluster QF.

The output from the weighted votes is what’s called a “Condorcet winner”: a funding spread that the community would prefer over any other funding spread, in a head-to-head vote.

In other words, imagine that the community could vote on either adopting the Condorcet winner or some other option. No matter what other option you choose, Condorcet will always beat it out, by definition! This is why Condorcet voting avoids peanut butter spreads: if some domain gets a very small amount of funding it needs to be because the majority of voters actually want that funding to be there, compared to another distribution with that funding removed.

Benefits of Trying Condorcet Voting for GG24

  • User’s voices can be weighted by the amount of GTC they have, achieving GTC utility. So nothing changes for the user interface for voting.
  • Condorcet voting is Strategy-Proof: there’s no way to game the system. This isn’t true with the mean weighted voting tool employed on Snapshot.
  • Condorcet voting avoids peanut-butter spread style distributions, which is very important when we’re funding entire domains. So we could use Condorcet to not just select top domains but also decide on funding between them, which isn’t possible with Snapshot mean weighted votes where we have to disregard domains below a certain threshold.
  • Condorcet voting is easy to use: users just input their preferred funding spread.
  • One can run Condorcet voting and a more typical “mean vote” in tandem and compare the results, since they both take the same input. In other words, adding on a Condorcet voting calculation costs nothing in terms of UI overhead.
  • Because of the way Condorcet winners work, Condorcet voting always returns a non-polarizing output that everyone in the community can agree on.

Appendix:

  1. Results of FIL RPGF program if we took condorcet winners instead of mean - https://docs.google.com/spreadsheets/d/1JdXsEK96he6QliRVeJkggdvylnjQJfm4jKNbMz7Qt38/edit
  2. Wikipedia page on Condorcet voting: Condorcet method - Wikipedia

If anyone has questions, please reach out in the comments. I’m very excited about the possibility of trying this out for GG24!

thanks for the proposal joel…

i asked chatgpt5 what condorcet voting is and this is what it said

Condorcet voting — TL;DR

  • Voters rank candidates.
  • Compare every pair head-to-head; if one candidate beats all others, that’s the Condorcet winner.
  • Sometimes no such winner exists because of cycles (A > B, B > C, C > A).
  • When cycles happen, Condorcet methods (e.g., Schulze, Ranked Pairs) choose a winner from the strongest pairwise set.
  • Pros: honors majority preferences in matchups. Cons: can be complex and somewhat strategy-sensitive.

heres what claude ous 4.1 says:

Condorcet voting is a voting method where the winner is the candidate who would beat every other candidate in a head-to-head matchup.

Key points:

  • Compare each candidate against every other candidate one-on-one
  • The “Condorcet winner” beats all others in pairwise comparisons
  • Problem: Sometimes no Condorcet winner exists (creating a cycle like rock-paper-scissors)
  • When there’s no clear winner, different Condorcet methods use different tiebreakers

Think of it as finding the candidate who would win a tournament of all possible two-way races.

is this roughly correct? it seems to differ from your example in “How does Condorcet voting work?” so maybe they are variants of each other.


any chance you all have a google sheet where i can play with various gtc scenarios of gtc steward voting pattern and see the results in condorcet vs trad voting weights.

does a Condorcet snapshot strategy exist? thats what we use for voting usually

I’ll let Joel respond separately but here are some of my thoughts on this proposal;

The main way they are different is in the wikipedia example, we’d only compare candidates with each other. Whereas here, we compare allocations like 20% to A and 30% to B vs 20.5% to A and 29.5% to B vs 21% to A and 29% to B ad infinitum

So in addition to the benefits pointed out about removing peanut butter spreads and strategic voting, GTC stewards should also get some more input on level of funding that each domain should receive which is a tricky question to figure out.

So the cool part is we can use the same Snapshot weighted vote interface but then feed those outputs into Joels python script, and then run a simple vote asking stewards whether they prefer option A (mean results from the weighted vote) or option B (condorcet results from the weighted vote)

When i spoke to the snapshot team about this, they said adding condorcet as a voting strategy isn’t something they’ve received as a request but they would be happy to do if Gitcoin paid for premium ($20k per year). I think we should see run this and poll high context people like you, carl, mathilda etc on which of the 2 matches their prefernces better (weighted vote computed with condorcet or mean).

I personally see this as a zero cost experiment, similar to how we could compare regular QF and cluster QF results from the same voter input and see which one matches our intuition better.