Today I have a major decision to announce.
TLDR - We have identified an instance of collusion in the health round and are counting contributions we identify as colluding as being from the same account.
Next time we will have a more robust identity system.
Details 👇
TLDR - We have identified an instance of collusion in the health round and are counting contributions we identify as colluding as being from the same account.
Next time we will have a more robust identity system.
Details 👇
2/ In the context of our new more experimental public health round, we found that 47% of contributions to a particular grant were funded by the same account.
We are taking action to change the mechanism that calculates the amounts for the health round & only the health round.
We are taking action to change the mechanism that calculates the amounts for the health round & only the health round.
3/ Because the on-chain data provides strong evidence that these contributions are ‘collusion’ according to definition in the CLR paper, we must, for the sake of other grantees err on the side of caution and count these contributions as if they were from a single account.
4/ Note that while these contributions meet the technical definition of collusion according to the CLR Paper (see below), we dont believe these contributors acted in bad faith. We think it’s more likely that the definition of collusion was not widely known to these participants. 
5/ Here is a spreadsheet identifying the before/after data for the health round (media/tech rounds are unaffected):
docs.google.com/spreadsheets/d…
docs.google.com/spreadsheets/d…
6/ This was not a decision we took lightly. While I made the final decision, and take ultimate responsibility for it, I solicited input from a number of Gitcoin community members.
7/ A core reason we felt this decision was necessary was the scale of accounts funded by a single address. While the mechanism is naturally resistant to the Pairwise Bonding Mechanism (see below) ...
ethresear.ch/t/pairwise-coo…
ethresear.ch/t/pairwise-coo…
8/ ... the mechanism is still vulnerable in extreme cases (like 47% of contributions coming from a single origin funder).
9/ In the future, until better identity mechanisms are in place, we may, at our discretion, count many contributions to the same grant w the same funding source as one donation from one donor.
These contributions *still count towards matching*, just not as being from new ICs.
These contributions *still count towards matching*, just not as being from new ICs.
10/ We realize this approach isn't perfect, & our improvements to identity in the future should make it easier for users to prove this kind of behavior is not the result of collusion.
There's some great debate about this identity mechanisms here 👇
There's some great debate about this identity mechanisms here 👇
11/ I realize that the shift in mechanism will mean different payouts for health round participants (media/tech rounds unaffected). In the case of this decision, only 1 grant received significantly reduced matching funds and all the rest will in fact receive an increase in match.
12/ I am personally a little uncomfortable with our role as the arbiter of disputes, so let me take this opportunity to remind you that Gitcoin Grants is a highly iterative experiment:
13/ It is important to note that without these interventions, until further mechanism improvements are made, sufficient collusion could result in entire rounds being taken by an arbitrary project, which is clearly against the spirit of the mechanism.
14/ Ultimately, we hope Gitcoin Grants will evolve to be a place where actors following the spirit/intent of the mechanism will prevail over rational economic actors exploiting holes in design.
15/ Going forward, you can expect we will eschew laissez faire governance, and instead choose to apply the rules (documented below) with discretion & heavy community input, to enforce the rules of the mechanism.
gitcoin.co/wiki/grants
gitcoin.co/wiki/grants
16/ Specifically, the precedent set here is that we may consider large pools of contributions from the same address as coming from one contributor, but in the case of one-off contributions (like below) we don’t see ourselves triggering this rule.
17/ We understand, we recognize, and respect that in a decentralized ecosystem, not everyone will agree with this decision, but we consider this to be a critical step to evolve our implementation towards how the mechanism was intended to work.
18/ In good faith, we are doing our best to optimize for the endgame of Quadratic Funding, which is to create “the mathematically optimal way to fund public goods that people broadly support”. We are not and cannot be perfect, but we can iterate towards perfection.
19/ From the beginning, Gitcoin was envisioned as a bridge fr web2 to web3.
One of our values is to make pragmatic decisions over dogmatic ones (gitcoin.co/mission)
BC of this, we will fail the decentralization purity tests that will be inevitably applied to us.
One of our values is to make pragmatic decisions over dogmatic ones (gitcoin.co/mission)
BC of this, we will fail the decentralization purity tests that will be inevitably applied to us.
20/ One interesting precedent I think this sets: Gitcoin Grants will evolve to be a place where actors following the spirit/intent of the mechanism will prevail over rational economic actors exploiting holes in the implementation.
/fin I’m on calls for most of the day, but will try to answer questions on a rolling basis.
Below is a list of what i think are major takeaways from this thread.
Below is a list of what i think are major takeaways from this thread.
(one final addition) for the code sleuths among us; here is the commit that allows us to add origination addresses as the identity layer, in the health round, a neutral algorithmic way => github.com/gitcoinco/web/…
