Enjoyed reading all this other than the formulas.
My friend would say “Urbit fixes this”, but I would say “Diversification fixes this”:
Could the holy grail be achieved with diversification?
Example… all in one round together:
20% traditional CLR matching (whales can’t run the show)
20% pairwise-bounded quadratic matching (teams can’t team up)
20% CLR matching with Negative votes (shorts allow a free market)
10% single matching (good ol’days)
10% 3x matching (encourages donations larger than 1 Dai)
10% Randomized matching (Introduces lottery element - play lotto for your cause!)
10% Sample-vote matching (David Chaum knows what he’s talking about)
Benefits:
Hard to game; a gamer might go in circles
With the right optimization may not need identity???
Diversification often makes things better - the game-able characteristics of certain strategies would be highly reduced by the other strategies.
Our resident Data Scientist, Frank Chen, ran Gitcoin Grants Round 7 data in a split test where we looked at what the diff in what results would look like if they were pairwise bonded or not. (The official results, detailed on Vitalik’s blog were pairwise bonded).
differences between pairwise and regular QF tell us that negative changes are more common (meaning normal QF awards generally more), but they’re all in amounts <= $100 range.
the effect above takes place with grants that generally have a less contributions.
large $ differences doesn’t have a definite correlation with the percent difference, but it’s still important to note that if we are in favor of removing pairwise, we want small absolute differences in $ amounts.
the strongest correlation was that the greatest percent differences seem to occur with high average contribution sizes, which might suggest that regular QR vs pairwise would disproportionately affect whale donators, but this leaves average contribution sizes (total/num contributions) < 50-ish generally unchanged.
it seems that the largest differences affect about 15-20% of tech grants in this example, so about 15 out of the 99 that received a CLR match.
The main objective was to figure out the tradeoff between removing pairwise matching (at least on the Gitcoin App itself) vs. gaining calculation speed to show “live” calculations.
Pairwise matching is quite intensive, since every time the mechanism is performed, we have to create permutations from every unique contributor to every other unique contributor by grant. Removing it would provide significant speed gains. However, we lose out on the natural anti-collusion checking capabilities of pairwise.
The saying goes “great minds think alike”, so I think what @Gerstep added is a major problem: we punish random people with similar tastes and therefore similar contributions across various projects, an obvious thing to happen.
This is combined with the problem that it would, I guess, be trivial for me or anyone to ask multiple third-party persons to officially make the contribution for me, if I’d seriously want to game the mechanism, hiding the correlation/pairing (?).
If these problems cannot be solved properly, I am worried whether the mechanism could ever be a big step towards solving the underlying problem with reasonable satisfaction - very happy to be proven wrong
In turn, the improved evidence can algorithmically make the pairwise matching weights way more accurate to gradually increase cooperation across differences and mute established relationships.
in the gitcoin grants system, we use a modified version of the QF mechanism to allocate our matching funds to grants.
what if we used NLP to generate embeddings of the descriptions of the grants each user donates to, then we can use some distance metric like cosine similarity or euclidian distance to determine how close in concept they are to each other’s idealisms?
more formally, we can set the subsidy coefficient (k[i, j]) for the user pairs as the normalized (relative to all other user pairs) cumulative distance between the set of grant descriptions they contributed to.
this ties in closely with the “social distance score” that glen weyl speaks of.
let’s say you have user 0 and user 1, user 0 donated to a set of grants G[0] and user 1 donated to a set of grants G[1]. for each grant in G[0], use an NLP model to embed (turn the text into a vector) the grant description do the same for each grant in G[1] then, use a nested loop to compare every embedding (text vector) in G[0] and G[1]. “compare” in this case means to calculate the distance (euclidean/cosine similarity) between them, then sum up those distances (which are scalar values). (edited)
that sum will be unique to every user pair, so you can use this as the “k[i,j]” coefficient for users i and j.
this gets you a social distance measure, albeit in O(N^4) time. there are a few optimizations that can be done.
